Thanks for the great post. The author, even if he were a bad programmer, is a great writer. The text grabs the reader and makes him sweat in the interviewee's shoes.
Live programming interview tests are rubbish, because:
a) They produce a huge rate of false negatives. People who do not "interview well" flounder in a programming task with someone peering over the shoulder.
b) They can only test "algorithmic" tasks (for lack of a better definition). Most programming is not algorithmic, it's higher level: glueing already written libraries, with very light data manipulation or validation.
Live programming interviews should not be the sole quality of judging someone, but if we've first given them a coding exercise to do on their own time and they passed that, then it's useful to have them come in and do some coding to show that they can walk through their code and add additions/fix bugs to it without problem.
Which on that same note, I'm not sure why you would say they can only test "algorithmic" when we can do like I just described and have them for instance code a new feature in an existing code project of theirs.
That said, I agree with everyone else that they shouldn't be rushed, should allow the interviewee any and all resources they care to look up, and should shoot for "real-world" exercises over made-up scenarios.
I was speaking about live programming, during the interview. I much prefer asking candidates to write a task on their own time, and then use that code as basis for conversation during the interview. You get all the insights on how good a programmer he is, without the sweaty palms effect.
B isn't universally true. Most of what I do on a given day does not fall into that category, really at all. Same applies for most people I interview, with few exceptions.
Live programming interview tests are rubbish, because:
a) They produce a huge rate of false negatives. People who do not "interview well" flounder in a programming task with someone peering over the shoulder.
b) They can only test "algorithmic" tasks (for lack of a better definition). Most programming is not algorithmic, it's higher level: glueing already written libraries, with very light data manipulation or validation.