I recently finished How Would You Move Mount Fuji? - a book about the puzzle interviews ("Why are manhole covers round?") that Microsoft has made famous. I very much enjoyed it. If you're one of the folks that hasn't read it, this short book report is for you:
Main points in book (not necessarily in book order):
1. History of the puzzle interview (including the history of the IQ test, which also attempts to use puzzles to determine intelligence.
2. Coverage of the Microsoft interview format
3. Why puzzle interviews? Because traditional interviews are a sham - he goes through several studies that indicate that most interviewers make their decision in the first few seconds of the interview, before the first question is asked. Puzzle interviews dispense with the sham formalities of traditional interviewing (Q:What would you say your worst quality is? A:I work too hard.) and at least bring things to an objective level. Very interesting, but I disagree - more later.
4. Tons of cool puzzles - what I bought the book for. Yeah - I got a lot right, but I blew a lot of them too. Good thing I've got a solid job in sunny San Diego. More later here, too.
5. Some more stuff in conclusion - how he thinks you should interview. He says puzzle questions are okay for certain jobs, but if you're not going to make a hire/no hire decision based on the question, why ask it?
We hired three engineers for a high profile project right as I was finishing up the book, which got me thinking... (rant follows)
I didn't ask a single one of these puzzle questions on the interview - I really didn't feel they'd give me information. I was aware of the fact that subconscious factors were at work in my hunches, and I realized that hunches are okay. We make decisions about people all the time based on hunches: Do I trust what this person is saying about his used car? Do I want to marry this person? Is this person lying to me? I think that's a good thing. I've hired based on questions before (right after I got my MCSD I was full of trivia), and been badly burned by it.
Let's take some of the major qualities that determine an employee's success - raw intelligence, specific knowledge, people skills, common sense, and work ethic, to name a few. Raw intelligence (solve a difficult logic puzzle quickly) and specific knowledge (How would you join a string of comma separated values in SQL? If garbage collection automatically cleans up after you, why would you close a database connection?) are both measurable to a certain extent, but I've found that people who can spout off answers quickly often make poor decisions because they spout off answers too quickly. And a minimum level of specific knowledge is important, but with Intellisense, groups.google.com, codeproject, etc., it's often more valuable to be able to find information than to have it memorized. The only useful thing I learn from specific knowledge questions is a rough idea of experience. Having been burned by hiring trivia experts who couldn't code, I now ask questions that reveal battle scars. I look for rueful grimmaces - “Oh, man, yeah, I got burned by that one. It works fine in development, but has problems when you migrate from server to server.“
Blah, blah, blah... Anyhow, I think it's important that workers have a minimum level of intelligence and experience required for the job, but work ethic isn't something you can determine by Q&A. Work ethic, on the other hand, is one of the most important factors in determining how useful an employee will be. Will they do the job they've been hired to do? For me, that's usually (a) doing what I asked of them, (b) raising concerns about issues they encounter during step a, and (c) making recommendations for improvements - in that order. If you can't perform your job, your feedback on how to improve things is suspect. And the point is, that's not something you can guage with a few simple questions. You pretty much have to try them out and see how they work, or go with a hunch. I feel that, although I couldn't explain it, my intuition has improved markedly (through negative reinforcement, no doubt). In the case where hunches failed, a question about dwarves with colored gems on their foreheads and their demon captor (read the book - p.85) wouldn't have helped.
So I arrived at the same conclusion Poundstone did, although for slightly different reasons. This begs the question - why has it worked for Microsoft, who is obviously successful in what they do? Well, they've got a flood of qualified applicants, and not only can they afford to thin out the ranks of applicants - they have to. I'm sure arbitrary puzzles have cut some otherwise qualified applicants, but who cares? They obviously don't hire on puzzle performance only.
As for the puzzles - some different types:
1) “Fermi questions“ - How many ping pong balls can fit in an airplane. The point of these is to systematically make asumptions and figure out a logical best guess. Having been through the Naval Nuclear Power program, these seemed frighteningly familiar.
2) Trick questions - Your first guess is wrong. Pretty easy to spot - if it seems easy, you're wrong or Richard Feynman. I got impatient on most of these and looked at the answers too early.
3) Reverse trick questions - Much simpler than they appear once you spot the trick (e.g. any finite number multiplied by zero is still zero). For questions that seem ridiculously complicated and aren't Fermi questions, there's probably a trick. Question each assumption one at a time - the author has a really good analysis of these.
4) Design questions - Thought process is key here. Don't assume design is easy, take a logical approach, and look for out of the box innovations.
5) Recursive logic questions (my favorite) - These are so great! These usually involve “Purely Logical Beings“ (PLB's, in the author's parlance) in a complex logic driven puzzle. It's easy to figure out what happens first, but the fun is the domino like logic that causes delayed reactions several steps later. A more indepth explanation is here. This was by far the coolest part of the book - the meta-meta-logic stuff is way cool - but there's no way in hell I'd ever get one of these on an interview unless the interviewer straight up told me the answer.
Anyhow - it's a great book of cool puzzles that the author fluffed up with some interesting stuff about technical interviews.
[Now Playing: matmos - civil war - zock]