That's actually a nifty problem in itself, I don't see anything wrong. Of course I have learned that the actual "proposition" of whatever problem is not what is right/wrong in an interview.
The way I would apply that problem interviewing someone is: We have 1 hour. Here is this problem (to which of course I know the solution to already).
How would you solve it? Let's solve it together so that I can see your decisions, your code, do you use exceptions? do you use specific type of exception for different errors? do you split functionality in a lot of functions? do you know nifty language tricks (maybe a bit of code golfing or functional constructs if JavaScript or Ruby).
The problem comes when the "interview problem" is passed from the creator to the "mid-level" Engineer who now has to do the interview. For them it becomes: "Ok, you gotta implement this in one hour", and they don't know the nuances or reasons for the problem.
I've seen this first hand with an equivalent problem. I had all this nice interview process that I applied, and the first time I shadowed one developer so that he could do the interview, he was just looking at the poor interviewee fail due to nerves, with the aim to evaluate him only on the merits of how far a set of working code did he had.
The way I would apply that problem interviewing someone is: We have 1 hour. Here is this problem (to which of course I know the solution to already).
How would you solve it? Let's solve it together so that I can see your decisions, your code, do you use exceptions? do you use specific type of exception for different errors? do you split functionality in a lot of functions? do you know nifty language tricks (maybe a bit of code golfing or functional constructs if JavaScript or Ruby).
The problem comes when the "interview problem" is passed from the creator to the "mid-level" Engineer who now has to do the interview. For them it becomes: "Ok, you gotta implement this in one hour", and they don't know the nuances or reasons for the problem.
I've seen this first hand with an equivalent problem. I had all this nice interview process that I applied, and the first time I shadowed one developer so that he could do the interview, he was just looking at the poor interviewee fail due to nerves, with the aim to evaluate him only on the merits of how far a set of working code did he had.