Couldn't disagree stronger with this. In fact, I love this problem, in that it gets rid of most of the complaints about engineering tech interviews: (1) it's "real world" (for the job in question), (2) can be reasonably done in the time alotted, (3) involves a task that is most common for developers (modifying existing code), (4) shouldn't require extra preparation.

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.

I disagree with that. If you’re hiring a programmer, surely you want to seem them write some code.

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.

There’s many many people, far more than not, who can make a plan, even write the code but can never actually get it to run. They can’t compile things without someone helping, and they sure as hell can’t debug to save their lives. This is a good test to weed them out.