My theory is that people have absolutely no idea how to evaluate job candidates whatsoever. Interviewing trends come and go (e.g. Microsoft puzzle questions of the 90's), but I think people just latch onto whatever they hear as 'the' way to discern good developers. Along with that comes the superstition that if you're not rejecting x percent of applicants, you're not hiring the top y percent of talent.
The puzzle-givers were onto something, though. They were trying to test for intellectual agility and creative problem solving. There is some merit in asking these sorts of questions if you're interviewing younger kids for entry-level jobs. At that stage in the game, you're really just trying to find smart and hard-working people who can be trained. You're not overly concerned with years of experience, or crystallized knowledge base. So puzzles make sense (again, to a degree).
Puzzles can be so easily misused. If the interviewer(s) all know the answer to the puzzle they'll have trouble being objective when it comes to measuring the responses of an interviewee who hasn't seen the puzzle before.
Worse still is that an underinformed interviewer might simply tune out until the candidate returns an answer to the puzzle rather than actively participating in the candidate's problem-solving process. Two engineers and a whiteboard is how all the best work gets done, right?
Maybe a good approach would be to give a puzzle that the interviewer doesn't know the answer to. That way, they work through the problem together and the interviewer can see what it's like to work with them.
I know this will never happen but it sounds kinda nice.
