Technical interviews have their own particular lore, and their own history. Over the years, there are some interview practices that have sunk into the group subconscious of engineers, to the point where they're used so commonly we don't even question why. Puzzles, for example.
There are a few famous interview puzzles out there. Microsoft has "Why are Manhole Covers Round?" Google has "You are shrunk to the height of a nickel and your mass is proportionally reduced so as to maintain your original density. You are then thrown into an empty glass blender. The blades will start moving in 60 seconds. What do you do?"
The standard answer to the first puzzle is "So they don't fall in." The answer to the second is that assuming you have the same proportionate strength, you can jump out. (There's an inverse square root effect between muscle and body length, so density is not a factor.)
But here's the thing. The first answer is incorrect. Manhole covers are round because they can be round. They could be square or triangular just as easily.
So as an interviewer, if you pick random interview puzzles out of a book and you think you know the "right answer" to the puzzle, you run the chance of not hiring someone because the answer he gave was actually the correct one.
A more common problem is that a clever interview puzzle is usually well-known. As soon as you figure it out, you'll tell all your friends, and they tell their friends. Eventually, you can google for the answer.
Back in the day, Zen Schools had the same problem. They were looking for insight and flashes of realization, initially, and wanted a way to test for this. Some people thought up excellent questions that could test the subtle understanding of self, reality and perception required of Zen students. More and more, the koans were used as the standard by which students' understanding could be measured. Eventually, someone had the bright idea to put together a book of koans – complete with "acceptable responses" – and through years of formalization, the age old question "What is the sound of one hand clapping" turned into a meaningless ritual.
Even if you don't use well known puzzles, interviewing with logic puzzles in the long run optimizes for them. Through discussion, shared experiences and research, people will generally know that they should study for a general class of logic puzzle. And the company will start getting more people that will do well at those puzzles… but that doesn't mean they know programming any better.
Fermi questions, those "How many elevators are in New York City?" questions that are popular in interviews, have a clearer structural weakness. They have no right answer at all, and can be completely circumvented with the right training. Once you know the rules, you can come up with completely the wrong answer and still be "correct" according to the law of the game.
I also have a philosophical problem with Fermi questions. Yes, they're pointless, but it's not just that they're pointless. Asking a Fermi question says that you don't really care what the answer is. Asking a Fermi question tells your candidate that you want them to guess.
Engineers are trained out of guessing. Engineers are trained to nail down as much as they can before solving any problem, because invalid assumptions and requirements are dangerous and expensive. But that's not why engineers don't like to guess.
Why is because most engineers remember vividly what happened the last time someone came up to them and said "When do you think we can go live? Just make a guess." When it comes to Fermi questions, a cagey and hesitant engineer isn't a bad candidate, but an experienced one.
So what do I recommend? This book is good to get a broader sense of what interviews are supposed to do, and you can ask spot questions about language and system knowledge, then rate them on the Programmer Competency Matrix. But the best way to figure out how someone attacks code is to bring out some buggy code and ask for help debugging it, or bring out a design and talk about how you'd implement it, talk about the engineer's background, print out the engineer's github project and ask about it. They'll appreciate it, and so will you.
Comments