Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
5  
A better proxy is the ohloh.net profile. –  Denis de Bernardy Jun 10 '11 at 9:46
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
2  
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
4  
@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

4 Answers 4

up vote 36 down vote accepted

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.

share|improve this answer
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 3 '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 6 at 15:50

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.

share|improve this answer
1  
"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." Just sayin... –  MikeSchinkel Nov 21 '12 at 6:10

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.

share|improve this answer
1  
+1 for the anecdote –  Spoike Aug 1 '11 at 12:10

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.

share|improve this answer
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
    
Food for thought, thanks. –  DeanMc Jun 17 '11 at 22:02

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.