Puzzling

Some time ago, I had an amusing interview experience.

A young fellow interviewing me asked a reasonable set of basic technical questions, had me code a few things on the white board (also reasonable), and so on.  The interview was pretty typical, and going well.

Near the end, he looked at me slightly askance, and said

“Ok, now I’m going to ask you a puzzle question.”

I may not have successfully resisted the temptation to roll my eyes as I responded

“Mmm, Ok.”

I’m not very fond of puzzle questions.

Barometers

He proceeded to ask

“Suppose you spot a building in the distance and want to estimate its height.  How would you do that?”

I chuckled and replied “That really reminds me of The Barometer Question.”  He blanched a bit and asked “What do you mean?” 

He hadn’t ever heard of it.

I proceeded to relate the story of the professor who asks a student how to measure the height of a building “with the aid of a barometer”.  The professor’s expectation is that student will provide an answer involving differential pressure from the base to the top. 

Instead, the student provides a list of unexpected, yet technically correct answers:

• Tie a string to the barometer and lower it from the top of the building until it touches the ground.  The length of string will be the same as the height of the building.
• Toss the barometer off the top of the building, time how long it takes to hit the ground, and solve for height.
• Offer the shiny new barometer to the building superintendent in trade for a peek at the blueprints.  The building height will be on the blueprints.

and so on.

“Wow, sounds like you’ve already heard of that one …”

said my dismayed interviewer.  (Indeed, though we eventually discussed the question and I provided him with a novel answer that satisfied him.)

Wizards and Monkeys

As puzzle questions go, this barometer variety isn’t too bad – at least it is amenable to multiple alternative, creative and valid solutions.

Puzzle questions which primarily involve a “gotcha” moment of perfect truth are in my mind essentially worthless for evaluating candidates.  In this category I have in mind classics such as Wizards and Dwarves, or the one on Monkeys and Switches.

These questions tend to result in a quick response if the candidate has heard them before, or a lot of fruitless struggling if they have not.  They generally don’t lend themselves well to systematic analysis nor extended discussion.

The puzzles are entertaining, for sure, but do you want to hire someone who can solve brain teasers, or do you want someone who can actually get work done?  Unless perhaps you run a company that authors brain teaser books …

In Joel Spolsky’s widely referenced article on Guerilla Interviewing, he too frowns on what he refers to as “Aha!” questions (the “gotcha” questions I refer to above), for similar reasons.

Out of the Box

Joel hedges somewhat more on what he calls “impossible” questions, like “How many piano tuners are there in Seattle?”  I’m a little more sympathetic here – I call those “out of the box” questions since you’re essentially looking for a candidate to approach a non-standard situation in a systematic way.

While I find those questions slightly more useful, they are less relevant for programmers than fundamental questions on algorithms, data structures, coding, design and architecture.  And in a 45-60 minute interview, I find I’m already pressed for time to cover those well.

As a result, if I’m ever interviewing you and ask you a puzzle question, it’s only because you’ve done very well.  It means I’d like to hire you, the interview is ahead of schedule, and I’m simply curious to see how you respond.

I’m secretly hoping you’ll roll your eyes, of course …

And if you ever ask me a puzzle question in an interview, I’m making a mental note to follow up (if hired) and speak to you about your interviewing techniques.