Ask HN: What do you look for in an applicant's GitHub?

59 点作者 bmpafa超过 7 年前

I'm a self-taught JavaScript guy / solo-preneur & have been thinking of seeking part-time / contract work.Skill-wise I consider myself (FWIW) between 'mid-level' & 'experienced', but having never worked professionally as a dev, I'm uncertain about hiring expectations, particularly wrt code samples. Most of my code is closed source, so I'm looking to build-out my public stuff.When you review an applicant's publicly available code, what's important for you to see? My assumption is that reviewing a repo is akin to reviewing a portfolio / resume (i.e., very quick), so how have applicants "wow'd" you in the past? (I mean short of obvious rockstar qualifications, like 'React core developer,' etc.)

27 条评论

codingdave超过 7 年前

I don't use github content as a criteria, at all. Not everyone uses github as a portfolio. Not everyone uses github at all. Some people just store stuff there, not worrying about the quality it may communicate to the world. Other people work primarily in private repositories, so their public data doesn't tell you much. Someone could just have a bunch of forks of other people's work, which they dabble with. And newer coders are often learning quickly, so their code from even a few months ago is not representative of the effort they would put in professionally if hired today.

评论 #16225096 未加载

评论 #16230275 未加载

评论 #16225143 未加载

评论 #16243985 未加载

rzimmerman超过 7 年前

Not everyone can post their work on GitHub, so I only look at their profile if they list it on their resume. I figure if you put it there, you want me to see it.For early-career people (with limited work experience in the field) I look to see what tutorials they've done. I don't expect high code quality, but active engagement instead of copy-paste is nice to see.If they've contributed to any OSS projects I look at things like:- How they interact with maintainers and other people- The quality of their PRs if any- How well they communicate issues and file bugs. Attitudematters a lot (offering helpful ways to reproduce it and suggestions rather than attacking the project for faults)If they have any of their own projects I look at code quality. I deal mostly with Python and it's pretty easy to tell from a glance how experienced the person is. Things like following lint/style and style guides but also readability in general. You can smell out a C/JS programmer who just learned Python pretty easily (lots of for loops with indexes, for example).If they collaborate on projects with others that's a huge plus. I look for signs of active collaboration, like PRs with good code review.Basically I want to make sure:- They're not exaggerating their experience (though GitHub profiles can be out of date)- They work well with othersAgain, just because a GitHub profile is sparse or missing some of these things isn't a signal. Not everyone does their work on GitHub. But if you list it in your resume, expect me to read it.

评论 #16225324 未加载

botskonet超过 7 年前

I look for signs of understanding.I want to see an understanding of git - they have repos with appropriate commits, good commit messages, awareness of licensing, decent READMEs or info for collaboratorsI want to feel like they understand how open source works - they've filed or participated in issues/discussions, they've starred/forked repos, they've opened PRs, they've managed issues/PRs on their own repos.I want to see how they manage their projects/repos. Do they use a package manager? Do they have linting or build tools? Do they use CI? Have they kept the repo clean and ready for others? Do they use automated testing?I don't expect to see all of this - but if someone has none of it, it's clear they have a lot to learn and aren't ready for the job.

评论 #16225415 未加载

makecheck超过 7 年前

For me, it would be signs of a sensible structure and use of commits. It is extremely offputting to see some obvious code dump, with like 2 commits in total (one of which is “fixd typo lol”), no real directory structure, etc.A repository is an opportunity to show off how good you are at organizing a project, breaking down your commits, etc. Only after any of that looks promising, will I bother to read any code (after all, it takes time to understand something and the harder it is to grok the less likely I’ll spend the time).

评论 #16224860 未加载

评论 #16227339 未加载

评论 #16225554 未加载

segmondy超过 7 年前

As someone that has interviewed hundreds of people. Nothing unless they really want me to look at it.As someone that still loves to code even tho I'm in management, I've found out that writing beautiful code get's in the way of getting shit done!When I code for myself, it's either to explore or practice. Beautiful code is not the goal. If I'm exploring a new idea, then one thing I like to do is to make it happen as fast as possible by any means necessary. I don't care about comment, duplication, abstraction, tests, optimization.That's what you will find in my github, I don't do resume driven development where I write code hoping to get hired because of it.

cbzehner超过 7 年前

It depends on the person and my expectations for the role. The best people have everything, including jobs! So I make it a rule not to expect perfection, helps prevent disappointment.When I'm evaluating candidates from a resume, if they have a link to a Github or personal website I'll visit it about a fifth of the time. I'll open up a couple repos and make note of what they look like.Are they school projects? That's fine but not necessarily indicative of anything since most academic code is write-once, run-once for an assignment.Does it look like a personal project? Great! This is what I'm most interested in.Is it easy to understand what the project is before reading the source code? README files and a clear directory structure/file names can go a long way here.If I look at the source code, how is the readability? Do they have good variable names (i.e. not a, b, c,..,z) and use the idioms of their programming language?Bonus points for good comments. Triple word score if I can understand the code without comments.I'll go through a couple repos this way and use whichever one is best to inform my initial bias. I think it's always a good idea to assume best intent when interviewing someone. I've had some people I wasn't that excited about in an interview become my favorite coworkers over time.PS - Here's a project of mine I'd consider a "good" example. Mostly the number of unfinished {- TODO -} comments in src/Lib.hs would hurt me here, were I evaluating myself. <a href="https://github.com/cbzehner/word-frequency" rel="nofollow">https://github.com/cbzehner/word-frequency</a>

victorNicollet超过 7 年前

I want to be able to understand what the project is about, and get a high-level understanding of how it works.Our hiring process starts with a phone interview and there's a quick technical discussion (mostly there to avoid wasting time if the candidate's skills obviously do not match what we need). A live coding exercise is hard to set up and takes a while to perform, if only because the candidate needs some time to understand the question and gather some elementary insights. So, instead, I ask the candidate to explain some code that they have written, and I expect them to be articulate and knowledgeable about it.So I want to be able to find a commit or file that can serve as a basis for an in-depth discussion relevant to the kind of work that the position involves. If I'm hiring for web front-end, then client-side JavaScript will have to be involved. If I'm hiring for Big Data, then high-performance code, low-level code, or distributed/parallel code will be good. If I'm hiring for Compiler Design, then a toy (or non-toy) compiler is nice.I will tell the candidate ahead of time about the commit/file that I find interesting (or even ask them for pointers to help me pick one). That way, if they join me on the phone interview and have no idea what their code is doing, that's the end of the line.I don't really care about code quality. Obviously, if the code is so bad that it's impossible to understand, that's bad news, but most of the time the code is readable, it's just missing comments, or has variables like `item2`, or functions that are too long, or other stuff that you would expect in an open source project. That's fine, because it leads into two very powerful questions in this type of interview: "Are you happy with the quality of this code?" (the correct answer is "no") and "If you had a few weeks just to improve this project, what would you do ?" (I expect insights about refactoring, or improving test coverage or even improving testing/validation strategy, or adding comments).

vorpalhex超过 7 年前

Things that set off alarms:+ Lots of unmodified forks or tutorials. A few is fine but too many is suspicious.+ Tons of empty reposThings I like:+ Lots of messing with different projects even unsuccessful work+ Side projects, even incomplete ones+ A mix of languages/designs/idiomsSuper awesome things:+ OSS contributions+ Working well with others+ Good branching

评论 #16225091 未加载

jrowley超过 7 年前

Different projects have different needs certainly, but its nice to see a readme that gives me some context to what the project is, and how to actually run the code, install needed dependencies if it's not obvious. Also probably worth acknowledging shortcomings or places for improvement in the readme, so your reader is aware that you're aware of any deficiencies.

hnruss超过 7 年前

I occasionally interview candidates for a small software team (less than 10 developers). When evaluating a candidate's GitHub account, I look for any non-forked projects (projects that they created/own), then I look at the structure, code, documentation, and commit history of those projects.At that point, the quality of the project can either help or hurt the candidate:- The most important thing is that whatever project content they have, it is understandable. The ability to write sensible code that follows conventions and is well-documented (in code and commit history) is highly desirable.- Ideally, they'd have an open source project with recent releases, issues, milestones, contributors, PRs, etc. (basically all the signs of a healthy open-source project). If they had this, then they'd be way ahead of most candidates.- It's easier to evaluate docs and commit messages than it is to evaluate code quality, but I do try to pick out a few files and have a look to see if they make sense.

vec超过 7 年前

Honestly, the main thing I'm looking for is that they have a Github account that's more than a couple of weeks old and has some sort of content in it. That shows me that the applicant is interested in programming for its own sake and not just checking a box to make their resume look good. Everything beyond that is just a nice-to-have.

Jach超过 7 年前

I went through a round of resume filtering and interviewing for interns recently, but I'd use a similar process for FTEs (just less lenient probably). I mainly used the Github profiles (for those who had them) as another seed for questions besides the resume itself, and it could give me a feel for how well they'd do on our simple coding challenge. For example one candidate checked some API keys into his projects, those are generally supposed to be non-public. I asked about the dangers of accidentally committing private keys in general and he talked about AWS keys and relayed a story of compromise that happened to a friend, then I asked what a main problem of checking in API keys could be and he mentioned rate limiting denials. So he understood the problems, I asked why he had API keys in some of his repos, turned out to be he thought he had disabled the ones that were checked in (at least one I tried wasn't) and they were for hackday projects anyway. With some context on it, and other discussion, all in all I was happy with him.I try not to let presence or absence of Github matter (and in general I try to differentiate on common information rather than lucking out to see a very negative / very positive trait in 1/10 candidates that I wasn't explicitly looking for), but I have to admit I like to see a link and like to see at least one project on it of any size and not just a sea of forks with no clear individual contributions. Resumes seem to correlate with coding performance terribly, at least if there's public evidence you can code (I'm not too picky on code quality, that's what reviews are for and drive-by open source reviews are non-existent) I don't have to spend as much effort verifying such in an interview.I'm not looking for rockstars. Using the classic trade ranking system, there are apprentices, journeymen, and masters. Journeymen are essentially interchangeable for most normal tasks starting from scratch, that's what I want to hire and work with most of the time. I can live with a sharp apprentice, especially if the apprentice is pretty skilled in the usual domain we already work in. Since I'm not a master myself, and I can think of no more hostile and futile way of attracting them than standard software interview practices I'm forced to somewhat conform to, I don't try to get them.

dmuth超过 7 年前

Something that's important to me is code that is commented. Well-commented code (documentation for each function, explanations behind complex if statements and loops, etc.) earns bonus points. Conversely, when I see screens and screens of code without a single comment that sets off red flags.Due to the nature of my current role, writing documentation is necessary so that other team members can pick up where you left off if something happens to you (or you just go on vacation).

评论 #16225439 未加载

评论 #16225506 未加载

评论 #16225403 未加载

xemdetia超过 7 年前

I generally only look for the 'bigger' projects, and only really bother if it is explicitly mentioned as a thing to look at (e.g. used this open source project/language). Even then my criteria is the same I would approach to a source code review:1. Is the code well formatted? If you haven't been someplace where it is bad, you might not understand how bad can be. I'm not going to give someone on a pass on something even the worst editor can do great.2. Does it look awful to build? I have seen projects presented to me that have no Makefile or appropriate mechanism to build the code successfully but 50+ source files. The exception here is obviously templates or ~1-2 file projects to solve a real problem. I don't want to hire someone who can't build software, or make their software nice to build.If those first two criteria aren't covered I'll skip to my last criteria:3. Lack of input validation/error handling/logging errors.4. Knowing common language constructs. Even in learner projects I want to see that you know how code should feel in that language. Python is one of the ones where this is most obvious, Java is one of the ones where it is least obvious so this is a subjective piece.5. Does it feel like original work or tutorial spam? Where's the artistic flair or the completely engineered and mechanical thing that made this more than a 2 hour project, and worth your time?The main thing is that your resume should strongly reflect that you want to change careers as a dev and you want to demonstrate your skills via GitHub. I would not go fishing unless you ask. I'm going to look at your technical experience and general work history and ask you just as many questions about those kinds of things.

Sir_Cmpwn超过 7 年前

An empty, boring, or bad GitHub account never hurts, but a good one can definitely help. Things I'm looking for are interesting projects, contributions to other projects (perhaps ones I know about), good discipline in git commits, well organized code, attention to detail (as in code style), and good interactions in tickets and code reviews. I'm not interested in whether or not your GitHub projects use any particular languages or technologies that are relevant to the role.There's this idea that no one should be expected to spend their spare time working on open source, which is fair. However, that are many candidates that do, and it helps a lot with the screening process. We might waste more of your time and ours if we have to coax out the kind of insight that I can get from a GitHub profile over the course of several phone screens and IRL interviews.

cyberlync超过 7 年前

I primarily look for signs of the ability and interest in self-teaching. A front-end developer exploring the backend? Great! A backend developer playing with probabilistic systems? Super!. A java developer branching out into Scala/Clojure/Rust/Haskell etc? Even better!For those that won't look at Github because not everyone has an account. That doesn't make sense. Whether or not the candidate has a Github account is not a litmus test, its just additional useful information. If they have an account that may tell you something useful about the candidate. If they don't have an account, then you have to rely on other approaches to get that information.

Raed667超过 7 年前

I have a pretty active Github. When interviewing I talked about it and put a link in my resume. People very rarely check it, but it gave me talking points when the tech of some old project matched the company's stack.

contingencies超过 7 年前

Multiple projects of interest (not just commercial), ideally with significantly different languages and problem domains. The ability to write clear documentation. Definitely not a pile of cloned repos with no contributed changes.

pkamb超过 7 年前

A well-developed README that promotes the project. Screenshots, explanations, an FAQ, release notes, info for collaborators, links to download or test.Basically, the github repo as a homepage for a product rather than just a dump of text files.This shows that your thing is a finished project or under ongoing development rather than just a dump of some source code that you once wrote. It's the equivalent of having an app on the app store vs. having a half-baked Xcode project on a computer.

bamboo_7超过 7 年前

I try my hardest not to do any 'grading' based on someone's github, but instead use it as a reference of what I can expect when the candidate gets to the interview. There's always a feeling out point at the beginning of the interview. I don't want to waste time hashing out things they clearly understand and likewise I don't want to throw them something over their head. Looking at their Github helps give me a starting point.

scardine超过 7 年前

First, I want to see contributions to flagship opensource projects. If you are using opensource stacks and pushing the envelope, you will eventually have to fix bugs or implement new features. Landing patches means the applicant is able to meet the high bar for contributions (code quality, documentation, tests).Then I want to see side projects using the same stack that will be used internally by the applicant. You can tell a lot about someone by his code style.

ellisv超过 7 年前

I look for many things but don't hold it against you if your GitHub/Bitbucket/GitLab/etc doesn't reflect it.Your profile can give me some evidence that you know how to code, use version control, write documentation, etc. -- but just because your projects don't have CI/CD (or whatever) doesn't mean you don't know how to use it just that I don't have evidence that you know how to use it.

drxzcl超过 7 年前

If I'm investing the time to look at her/his github, I have probably already invited the candidate over for an interview, or am seriously considering doing so. I'm looking for anything that gives me an insight into the way the candidate approaches problems, than I can then use to further the interview.Any github that contains more than just course work is fine for that.

marssaxman超过 7 年前

I'm not sure I've ever bothered to look at an applicant's github account. I wouldn't expect to learn much from it. I am amused to imagine just how strange someone's impression of me would likely be, were they to derive it from the random collection of experimental hacks in my personal github account.

andrew_wc_brown超过 7 年前

Here in Toronto I always ask, have you looked at the source code I shared? And the answer is no.I have lots of source code open to private to share, and its just because I'm a workaholic, though I find having source code doesn't matter, at least not here since they don't put much value in it.

iopuy超过 7 年前

Do the people here preaching github being a useful tool for candidate evaluation realize there are private repos? I use github everyday but none of the outsiders looking at it are going to get a sense for my coding style because they can't see the content of the commits.

评论 #16226178 未加载

watwut超过 7 年前

Realistically, pretty much anything sane is a plus, because most applicants don't even have github account. AlSo realistically, have a good readme because that is the thing most hiring managers will read (unlike codebase).