[wavetossed]

Your first sentence is way off the mark. Obviously an interviewer needs to have intimate familiarity with the problem that they give to potential employees, and have hands on experience implementing it in many variations. But that does not mean that it is unfair to ask this question because you do not know the answer.

This is a lot like fizzbuzz because the instructions for writing the code are simple, straightforward, and should be understandable by any programmer. This is not a question with an answer. This is a SPECIFICATION for a program. If you know how to code, it should be easy to write some code that meets this simple specification.

P.S. most interviewers will give you bonus points for explaining your work as you do it, particularly why you chose to use a certain approach, and what you assumed even though it was not explicitly specified. This is true even if you botch the end result and provide code with severe errors.

After all, that's what good coders do most of the time, write incorrect code with severe errors. The rest of the time they fix their mistakes.

[agentultra]

It's not far off the mark. The problem with familiarity is that it's easy to conflate with easy. Once you see the solution to the problem it's hard to believe that it's hard to implement. The solution is so easy, how could anyone worth their salt not see it?

As an example of what I mean: studying math. The majority of the time after reading or listening to an explanation of the problem and walking through an example exercise or two, I the student am left to bash my head against a set of problems. Despite the wishes of the teacher and their best efforts to illuminate the way the solutions to the problems and why they work is not clear. You have to just throw your mind against the wall until you break on through. Then when you do you see that the answer really is simple. And you wonder why it was so hard to see it. Years later you might wonder why anyone cannot recognize how simple it is. You've forgotten what it's like to be a beginner on the other side of the wall.

The other half of the problem I see with using puzzles in interviews is the adversarial nature of the situation. By posing the problem you're triggering a response in the candidate to find an answer. They want the correct answer because they want the job. Explaining to the candidate that they can think aloud and walk through the problem might help to switch them off that track, but I find only a handful of people respond to that encouragement.

I did upvote your comment though because you're right -- most of the time we write incorrect code. Despite our best efforts to write our tests up front and walk through our best laid plans, we still make mistakes. Developing software is a process and becoming a good programmer, to me, means mastering that process and cultivating the wisdom and experience to see the bigger picture.

Trivial problems trigger the trivia response. We learn trivia by rote. Once I got over the initial depression when I had to go through this style of interview process I figured out a way around it. I wrote software to train myself in trivial programs and practiced walking through problems I was unfamiliar with. I started practicing code kata and as a result have been more comfortable with these sorts of problems... but is that really a good indicator of competence? Is it even a useful signal? Of what does it signal at all?