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.
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.