Have you ever been to an interview for a programming job where they asked you one of those interview puzzle questions? I have. The one I got was:

How much of your favorite brand of soda is consumed in this state?

And no, the correct answer is not who cares, unless the thing you don't care about is getting the job you're interviewing for. I didn't know it at the time, but this is a Fermi Question. (To prevent spoilers, the answer can be found in a previous blog post.)

Puzzle questions were all the rage in programming interviews in the 90s and early aughts. This is documented in the book How Would You Move Mount Fuji? with a specific emphasis on Microsoft's hiring practices.

It is prudent to study common interview puzzle questions if you know you'll be interviewing at a company that asks these sorts of questions. And if you think you're ace at programming puzzle questions, then I challenge you to point your massive brain at this, the hardest interview puzzle question ever:

A hundred prisoners are each locked in a room with three pirates, one of whom will walk the plank in the morning. Each prisoner has 10 bottles of wine, one of which has been poisoned; and each pirate has 12 coins, one of which is counterfeit and weighs either more or less than a genuine coin. In the room is a single switch, which the prisoner may either leave as it is, or flip. Before being led into the rooms, the prisoners are all made to wear either a red hat or a blue hat; they can see all the other prisoners' hats, but not their own. Meanwhile, a six-digit prime number of monkeys multiply until their digits reverse, then all have to get across a river using a canoe that can hold at most two monkeys at a time. But half the monkeys always lie and the other half always tell the truth. Given that the Nth prisoner knows that one of the monkeys doesn't know that a pirate doesn't know the product of two numbers between 1 and 100 without knowing that the N+1th prisoner has flipped the switch in his room or not after having determined which bottle of wine was poisoned and what color his hat is, what is the solution to this puzzle?

In other words, I hate puzzle questions.*

I'm also not a huge fan of those abstract impossible questions, eg, "how many optometrists are there in Seattle?", but I suppose that's a matter of taste. If you absolutely must, at least ask an impossible question that has some relevance to a problem your very real customers might encounter. I just can't muster any enthusiasm for completely random arbitrary puzzles in the face of so many actual, real world problems.

And yes, I totally failed that interview. Which was disappointing, because it was kind of a cool job.

Not that my proposal for interviewing programmers was any more popular, though I do think it's much better.

I have my own theory about the ideal way to interview developers: have the candidate give a 10 minute watercooler presentation to your team on something they've worked on. I think this is a far better indicator of success than a traditional interview. You'll quickly ascertain:

• Is this person passionate about what they are doing?
• Can they communicate effectively to a small group?
• Do they have a good handle on their area of expertise?
• Would your team enjoy working with this person?

You'd certainly want to complement this type of interview with some actual hands on programming, to make sure the applicant isn't full of crap -- although I'm pretty sure that you can't B.S. your way through a technical presentation to a handful of your peers if you truly have no idea what you're talking about. (And if you can, you should be CEO of a startup by now.)

What I'm optimizing for here is the ability to communicate. Most programmers, once they pass the FizzBuzz level of competency, are decent enough. But coding chops aren't enough. To go from good to great, you must be able to communicate effectively: with your teammates, your manager, the users, and ultimately the world.

My wife and I just finished a five day hospital stay for the birth of our first child. During our stay, we were assisted by a parade of different nurses, at least two different nurses every day, sometimes more as we progressed to different areas of the hospital and through daily shift changes. The quality of care at this particular hospital is generally quite high, but we were flummoxed by the disparity in care between the worst nurses and the best nurses. After a few days, I finally figured out the common characteristic -- the worst nurses were invariably the worst communicators! The fact that these nurses couldn't effectively communicate with us:

• why they needed to do something
• what the options were
• offer advice
• troubleshoot our problems

Hiring is difficult under the best of conditions. But an interview process that relies too heavily on puzzle questions is risky. Sure, you may end up with programmers who can solve (or memorize, I guess) the absolute gnarliest puzzle questions you throw at them. But isn't effectively communicating those solutions to the rest of the team important, too? For many programmers, that's the hardest part of the puzzle.

* although I expect aficionados of the style should be able to identify all the classic interview puzzle questions represented here.