However, it is a different question if you are running a company like Google or Facebook. For instance, recently there was a news that Google received > 75,000 applicants and is looking to grow by more than 5000 employees this year. http://goo.gl/9fpkt
If you want to scale at this level, you won't have time to look at Github or similar sites for every candidate in detail. There will also be great candidates who have never published their code (although they might be the minority). To maintain hiring standards in this kind of situation efficiently, asking very difficult algorithmic questions might be the only way to go - at least you will be able to maintain the same hiring standards for 75,000 applicants.
Surprisingly, however, public code rarely tells you anything about a user's CS fundamentals. Can they tell me the time complexity of a method they just wrote? Do they know the difference between a depth first and breadth first search?
I've met individuals with good code who were unable to answer CS 101 level questions like that. It's not a deal breaker, but it needs to be given some weight and consideration in hiring. It's also a matter of seniority -- I would never offer a senior developer position to someone who didn't have CS fundamentals because I expect such a person to solve hard problems that fall outside of "hacking up a webapp".
What I mean is, "Things that a CS major probably should have been exposed to in his or her first year of college."
Look at it like any other subject: you spend a lot of time analysing and understanding existing work before you make new work. Why would it be different for computer science?
The introductory course syllabus is at http://www.cl.cam.ac.uk/teaching/1011/CST/node11.html if you're interested.
1) If they actually wrote all of it, or if it derivative of someone else's work. 2) Whether any particular function took them 10 minutes or 10 hours. 3) What options they considered when choosing how to architect a particular solution. 4) Why they made any particular choice in their solutions. 5) Whether or not they will fit on your team, take constructive criticism, etc.
The questions posed in the article don't give you those answers either, but the applicant's speed at answering, their confidence, they demeanor as you ask further questions and discuss answers... all that communication does answer most of the above questions.
1. Do you look at my github and wonder whether I wrote it or copied it from elsewhere?
2. What do you care if anything I wrote took me ten minutes or ten hours? And with rewrite_rails, the answer is more like ten months. Is that a problem? Are you looking for LOC/hour or for a certain approach to thinking about programming?
3. A trivial coding problem will not answer this question any more than Github will, but you can always just ask: "Reg, I'm looking at Faux, and I wonder, what other approaches did you consider before settling on pushing application logic down into the browser?"
4. See above.
5. "Reg, #andand seriously sucks. This is pervasive nil checking dressed up in metaprogramming clothing with opening core classes as a third deadly sin. Before I consign your soul to the abyss, what do you have to say in your defense?"
Not everyone works at the same speed, but for certain types of problems and industries, knowing that you can put out reasonable quality work in a reasonable amount of time helps people get an idea of how to plan out other parts of the project.
I'd rather know someone can do fizzbuzz in a few minutes vs 8 hours.
I guess that after Benjamin Stein and I discussed the problem and one of us (I can't remember whom) said "I wish there was an and-and-dot operator in Ruby," there was a rough implementation written fairly soon after.
But the thing on my Github now probably has a hundred hours of work refactoring, dealing with edge cases, adding new functionality like .andand { |foo| ... } and so on. I wouldn't be surprised if the LOC/hr. has dropped below one at this point. And that's without considering the rewrite_rails version which uses AST rewriting.
So for that purpose, I agree that a fizzbuzz given on the spot is far superior to looking at someone's Github projects. Thanks for the valuable comment.
> While I'd love to agree, reading someone's code does not
> tell you:
Also, the cost of inspecting carefully enough someone's open-source code is way higher than evaluating their answer to an interview question.
Also, at the risk of stating the obvious, if a significant fraction of employers started looking at the candidates' open-source contributions, all new grads would start producing open-source-spam projects, further decreasing the usefulness of this signal.
I've had success in interviews initially linking to my github repo and letting the interviewer view for themselves what I can accomplish. It has been a good diving board when you start talking in person.