[Peroni]

Ashe Dryden's original post has merit, I'm not contesting that. James' post however, is wrong on so many levels.

It's worth noting that James is a UK based developer. Most of his points may be completely valid in the US but they are completely at odds with the UK climate. I've worked with an inordinate amount of tech companies in the UK and consulted with many more and I've yet to come across any that hire based primarily on the merits of a candidates github repo.

In fact, I'd argue his understanding of the request for a candidates github URL is completely wrong. One of my first requests when speaking to a potential candidate is for their github/bitbucket profile so I can see some actual code examples. I know that it's rare to find a true indication of someones ability from just their github contributions but for example, it can help me discern whether a ruby candidate adheres to ruby best practices or not. A small example of a minor indicator that someone might be a good fit for our company.

A man with significantly more experience in the industry than me once put it better than I ever could:

The more information I can get, the easier it becomes for me to make a decision, and to feel comfortable in it. And the best sort of information to give me is to show me what you can make, whether that's code for a backend position, or interesting design/UI for a front end position. It also gives us another thing to talk about during interview; and more opportunity to ask about design decisions and rationale.

Some of the best people I've ever sourced didn't have any publicly accessible code but if they had, I would have found them a hell of a lot quicker.

[chadwickthebold]

'I know that it's rare to find a true indication of someones ability from just their github contributions but for example, it can help me discern whether a ruby candidate adheres to ruby best practices or not.'

The problem with this is that you can't really make a logical decision when the code (on Github/bitbucket) is removed from its context. Maybe none of the code follows best practice, but there is a compelling reason why this is so. If your decision on whether to pursue a candidate or not does not include a discussion with the candidate about their available code, you are missing an integral piece of the puzzle.

[Peroni]

If your decision on whether to pursue a candidate or not does not include a discussion with the candidate about their available code, you are missing an integral piece of the puzzle.

You are absolutely right. I can honestly only ever think of one circumstance where I dismissed someone based exclusively on what I saw in their github repo. I felt guilty so I phoned them a week later to discuss my thoughts and it turns out my suspicions were correct but that was categorically an edge case.

[001sky]

I would have found them a hell of a lot quicker.

There are two ways to read this: (1) as a marker; (2) as a filter. Would be interesting to hear your thoughts on the interplay. My guess is that there is some game theory on signalling at play on both sides here.

[Peroni]

It's genuinely very straightforward. If you don't have much of an online presence (github, twitter, blog, etc) then the only way I'm likely to find you is if a mutual contact tells me about you. Now, referrals are one of the best sources of excellent people and I'm not knocking that.

If you're constantly tweeting/blogging good quality content about an area of technology that is relevant to my business then of course I'm going to take notice. That, however, doesn't necessarily make you a better candidate by default, it just means you were easier to find.