Question to all those in a hiring position: when looking at a candidates' purported open-source credentials, how closely do you inspect the work? Enough to tell if the improvement was fluff? Or a rehash of other code? If it looks like said candidate has a lot of commits, how do you discern the ratio of quality commits?
While my hiring manager experience predates GitHub, I would be more concerned in verifying that they actually did what they claimed than that I agreed with the specifics of their commits. If they got the the tasks completed, that's a Good Sign.
People lie horribly on resumes. I would not be surprised in the least to see people claiming GitHub accounts that are not their own. I have seen LinkedIn career logs from MSFT with people claiming to have done things that _I_ did back when I worked there. One of the most annoying things about phone screens was the huge number of them where it turned out the person was a complete, total liar. I spent much more time on verification than details.
After all, most decisions in the small only make sense in the context of the whole program, history, backwards compatibility needs, project plans, etc. and it would be pretty arrogant to second-guess somebody's patches to a large system without the greater context.
There are often too many applicants to spend more than 5-10 minutes looking at any one person's resume and open source projects. I usually spend a few minutes on the resume looking for interesting projects or relevant work experience, and then a few minutes looking at an applicant's GitHub page (if it's provided).
Things I look at on a GitHub page:
- # of projects that are not forks. The person might have done a lot of work on the forks, but it's too time-consuming to figure out what code is theirs and what code is pulled from someone else.
- The nature of the projects. Are they mostly trivial ("My .bashrc file") or awesome ("In-memory distributed search engine with replication")?
- Whether the person has good documentation skills. I look at a few sample commit messages, project README files, docs within a few random source files, etc.
- Good coding skills: decent style, no red flags in terms of quality, well-polished code, decent error-handling, etc.
From my perspective, a bad job on open source projects is a red flag, a good job can really help you distinguish yourself, and anything else doesn't significantly help or hurt your application.
The Impact graph on the Stats & Graphs page gives a quick summary of recent major contributors to a repository. However, if you want to gauge the total contribution of a person across all projects, you have to check the impact graphs individually for each repository. Still no search for commits, it seems.
> # of projects that are not forks.
I think forks are important as well. The more number of active forks, the more the person is actually working with other people on a project.
