Why couldn't a potential hire be given 5 minutes to think about a solution and then be asked what their plan is? What benefit is added by 36x-ing the time allowed that justifies putting the candidate through such pain?
I have seen people who can talk very nicely, but are lost once they actually have to touch the code. I have also seen people who are really bad at articulating their plans, but are OK with coding them.
Also, the actual time limit (the real author of the question showed up in this thread) was 1 hour. I'd say in actuality it's roughly a 30 minute process.
But THEN, I'd let them actually try to DO it. Because there is a huge swatch of people out there who can describe (and sound smooth about it) but can't DO. And there are also some who can do but don't sound very competent when they are asked to describe.
Many interview techniques never assess the ability to DO coding, presumably because it is more difficult and time consuming to evaluate.
This question has the added benefit that they don’t have to write a whole program from scratch, they have to deal with a real–world program instead of a toy program created specifically for interview purposes, and they have to demonstrate that they can read and understand other people’s code. The latter seems really important to me, as apparently it was to the author of the question, because we spend so much of our time improving code that has already been written instead of writing completely new programs. Of course, I am especially good at these software–archaeology skills, so I suppose I could be biased.
I have seen many times where a user can actually explain the solution to a problem, but the translation from algorithm-to-code is extremely slow, or not done correctly at all. There is real skill in being able to output code quickly, even if you already know the English-language description.