When I was interviewed for a software engineering job about 7 years ago, during the interview I was asked to play a game of Mastermind. The interviewer described the game briefly, then secretly wrote down a pattern of colors. I then provided a series of guesses of the pattern, explaining my motivation for each guess and the information that was gained from its evaluation. (There is a simple FreeGLUT/OpenGL implementation of the game at the usual location here.)
I wonder how wacky this sounds to someone not in a software-related field. In what other fields does this happen? A couple of weeks ago I saw some online discussion about this sort of thing (here and here), with many people expressing a strong dislike of puzzles, both personally and as part of the interview process. The issues seem to be (1) whether you need to like solving puzzles to be a good programmer, and (2) whether such puzzles are a useful means of evaluating job candidates.
I like solving puzzles. Mathematical puzzles, logic puzzles, computer science puzzles, etc. I like solving them just for fun, and independent of whether they are useful or directly applicable to my work.
But I also think such puzzles are in fact more than just recreation, they are recreational exercise, and exercise certainly seems useful to me. Running on a treadmill seems pretty stupid if all you care about is getting somewhere right now. But it makes more sense if you view it as exercise, as preparation for the times when you do need to get somewhere.
For those who don’t like solving puzzles, that seems too bad. I suppose that might be because their particular job does not involve writing code that requires much mathematics or interesting algorithms or data structures, that are at the heart of most puzzles. (One of the above posts mentions Facebook as an employer that emphasizes puzzle-solving; I admit I don’t see a lot of “meat” in the problems one might encounter on a typical day at Facebook.)
The more interesting question to me is the second one, how useful such “puzzle-type” questions are in a job interview. I tend to think many (most?) of them are not terribly useful in this context, for two reasons. First, many common interview puzzles are just that, common, being so well-known that the ability to provide a solution indicates nothing more than “I’ve heard that one before.”
Also, for the unfortunate job candidate who hasn’t heard that one before, coming up with a solution in the 30-60 minutes of time during an interview may be difficult or impossible. This problem is made worse by the fact that some common interview puzzles are of the “brain teaser” type that require flash of insight more than structured reasoning, where the latter is probably much more important to the job in question.
(Last week’s post involved two puzzles that I think are interesting in that they both straddle the line between these two types. If you were confronted with either of these problems in an interview, it would initially seem that you were missing some information necessary to solve it. But if an answer is expected in a very short time, then a “test-taker’s” approach might be to assume that a unique solution exists, and so it must not depend on that missing information… and so you can simply pick a convenient value for that missing information. This would yield an answer quickly, without actually proving that the answer was in fact unique.)
Coming back to the Mastermind episode, although I was surprised by the approach at the time, looking back, I actually think it was a reasonably effective interview component. Mastermind is a puzzle… but it’s a puzzle that doesn’t have just one solution that you can learn or look up ahead of time. Also, having to describe the thought process involved in each guess, and the information obtained from the scoring of each guess, requires clear verbal communication of logical reasoning, which I think should be a necessary part of any job, software-related or not.