54

Lots of people in the open source community say they strongly consider a candidate's Github profile when hiring.

I'm active on Github, with a few projects of my own and some contributions to others. But looking at my own profile as if I were an employer, I see a lot of noise: projects I cloned but never contributed to, etc. The projects and patches I'm proud of don't stand out.

If you assess people's Github profiles, how do you do it? And as a developer, should I do anything differently - for example, delete cloned repos I'm not actively working on?

Thomas Owens
  • 79,623
  • 18
  • 192
  • 283
Nathan Long
  • 3,667
  • 3
  • 24
  • 28
  • 1
    I would like to see the projects the person has initiated themselves and open sources ones he/she has contributed to. The source code is evidence enough of the design,coding capabilities. The passion to work on a project outside the regular day-job would also indicate their line of preference. A few pointers to atleast get started on the job discussion. – Abi Jun 10 '11 at 10:22
  • 3
    Why forking projects if you're not going to contribute to it? This seems to happen a lot over at GitHub. Is it to make sure the source code doesn't disappear when the original author decides to delete the repository? – Htbaa Jun 10 '11 at 13:06
  • 5
    @Htbaa - sometimes I fork something so I can poke around the source code, thinking I might contribute. Sometimes I do end up contributing; others I don't. – Nathan Long Jun 14 '11 at 17:27

5 Answers5

51

I've used GitHub profiles, twitter streams, and blogs all as indicators of quality in programming interviews/candidate screening. They all generate different signals in their own way.

9 out of 10 applicants have never submitted a single patch to a single open source project. Even updating broken documentation puts you into an upper echelon of developer. It shows that you are familiar enough with some open source package to know what's wrong, you care enough to submit a patch, and the maintainers of that package think your work is good enough to be included. As a generalization, it shows that you take the initiative to leave dirty things better than you found them.

It sounds really simple, but again 9 out of 10 developers never bother to take this all important step.

So a single accepted patch looks great. A long history of 2-3 simple patches per quarter is even better. Even better than that would be to contribute something of note.

  1. Substantial contributions to important Open Source projects(upper 0.1%-1% of candidates)
  2. Extended history of small contributions to any projects (upper 5% of candidates)
  3. A single one-liner patch to a relatively unknown package (upper 10% of candidates)

On the same note, developers that tweet about drinking and going to see movies all the time tend to make mediocre hires. A tweet stream where every 3rd message is about technology points towards the kind of rabid junkyard dog developer that cares about his craft and relentlessly pursues solutions.

Blogging is also a great indicator of quality, but for communication style rather than technical prowess. How many programmers bother to write blog article #1? The same kind of 1%/5%/10% cutoffs apply here.

marshally
  • 626
  • 5
  • 3
  • 5
    "So a single accepted patch looks great. A long history of 2-3 simple patches per quarter is even better." Where do you go from someone's profile to see accepted pull requests on forked projects? – Nathan Long Aug 03 '11 at 14:48
  • Nathan Long, I guess if you go to contributors, you would be able to see his/her name? – MIdhun Krishna Aug 06 '14 at 15:50
  • Came across this question, since they made search more powerful (not sure it was possible before) you can do a search like this: https://github.com/search?o=desc&q=is%3Apr+author%3Agshutler&ref=simplesearch&s=updated&type=Issues&utf8=%E2%9C%93 – Garry Shutler Feb 13 '15 at 14:07
  • 2
    "On the same note, developers that tweet about drinking and going to see movies all the time tend to make mediocre hires.", yeah you definitely don't want people with healthy work-life balance now do you. – whatsisname Feb 15 '15 at 06:04
10

As a developer, I wouldn't do anything differently in Github account. It's not your problem that Github account can't be quickly evaluated. And strictly speaking it's not Github's problem either - it's meant for collaborative software development, not for evaluating developers.

There should be special tools for user evaluation, working with Github data. For now, you can use third-party sites. For example there's http://coderwall.com - one quick look on the profile shows whether developer ever submitted a patch, if someone else forked his project, how many languages he uses...

Another option would be to automatically generate such summary on your homepage using Github API: a custom list of projects with a number of forks and watchers, last time they were updated, etc.

Lukas Stejskal
  • 1,404
  • 1
  • 10
  • 15
  • 6
    _"Git is not meant for evaluating developers."_ Tell that to Andreessen Horowitz one just invested $100 million into GitHub because _"[When I ask everybody what they use for engineer recruiting, and everybody uses GitHub](http://news.cnet.com/8301-10797_3-57495099-235/forget-linkedin-companies-turn-to-github-to-find-tech-talent/)."_ Just sayin... – MikeSchinkel Nov 21 '12 at 06:10
8

Be careful when you assess candidates based on a GitHub profile. GitHub is not a CV. There are many great engineers that don't have flashy profiles, because of many reasons: they might have worked for closed source companies, or they might spend more time on other activities such as family, hobbies, etc.

Even though a contribution to an open source project might be a plus for a candidate (as @marshally mentioned), you should evaluate and hire in the old-fashioned way, talking.

Some references that I've stumbled upon just after reading this thread:

defvol
  • 181
  • 1
  • 3
  • 2
    amen. The guy who's forked a hundred projects and submitted 1000 broken documentation patches is not the guy you want to hire - he'd never get anything useful done. The only real criteria is the old-fashioned taking time to talk and understand someone. No matter how much the pop culture of our industry wants to treat devs like robots, we're still people (well, most of us) – gbjbaanb Feb 13 '15 at 13:51
  • 1
    You don't have to only take account of the statistics of GitHub profile. You can actually look at the code to determine if they are good programmers. – Siyuan Ren Feb 15 '15 at 03:19
5

I think you can, you just need to take some extra time looking if he is actually active on github or not, by looking at his activity stream.

You can see how pushes, issues etc, which is a big indicator that he is actually active and working on something, rather than just fooling around.

If someone is looking to evaluate you, he/she should look at your "true" picture, the crappy code and also the good code. I interviewed recently and the interviewer asked me to open my github account, then he browsed through one of my repos, glanced through some crappy code I wrote an year back on a language I was learning.

So, he asked me, how can you improve this? I answered all his answers correctly, because I knew how to improve that, but I didn't really care to fix that project up, because it was just a go-to project for me, to learn.

Same goes with stackoverflow.com account. It's more obvious on SO since you have reputation etc.

zengr
  • 1,217
  • 11
  • 22
4

I personally don't see the value in looking at their profile per se. As you rightly said there tends to be a noise ratio that is large enough to not be worth sifting through.

I recently applied and was excepted for my first dev job and I thought the process they used was very fair. Rather than asking about profiles and the like they concentrated on the projects I chose to list on my CV.

There are really only a few things you need to glean from a candidate, the main ones are can they develop, are they motivated and how they tick. All this can be got from a pre interview or first round talk, this could be done via phone or 1 hour on site interview.

The idea is to let the candidate do the talking and find out where their passion lies. I found that this more relaxed style had me open up far more than sending on my profile for any of the services I use relating to development.

It was nice not to be launched into a tech interview first. It seemed they had the right attitude of finding a good "team" fit and then assessing skills.

DeanMc
  • 367
  • 2
  • 9
  • 3
    I agree that personality fit and passion are important, but many people have written about how hard it is to determine, as you said, "can they develop." It seems to be conventional wisdom (at least, in the Ruby world, where I work) that reading someone's code is the best way to see what they can do prior to an interview. To go even deeper, you would bring them in and pair program with them, which shows you both their personality and how well they solve problems. So it's not either/or. I think someone's profile can be a useful tool; the question, again, is how to assess it. – Nathan Long Jun 17 '11 at 10:51