The Hardest Interview Puzzle Question Ever

I am a full-time programmer and I find most people who aren’t programmers have a tough time communicating with programmers. I’m not a sociable person, but I communicate just fine. Programmers actually tend to be highly effective communicators… to the degree that talking is usually the worst medium to communicate in.

Programming isn’t a social practice. It’s not a party where people hang out and get to know eachother. That’s for college kids and sales people. Programming is a technical field and the best programmers want to be taken seriously as engineers, scientists, and craftspeople. This generally requires a lot of mental effort and discipline in maintaining mental focus.

I find that just employing a few rules and systems to manage communications is the best policy. It lets the technical people work without distractions and it lets non-technical people work with them without having to deal with their eccentricities.

For example, in my work place as policy I make sure that all technical issues are handled by our issue tracker. Nobody is allowed to walk up to my desk or anyone elses and discuss technical issues in face-to-face conversation. Firstly, it’s distracting to have someone approach you and force you away from your thought processes on a whim. Second, technical issues are difficult to communicate in person either by misunderstanding or by failure to transcribe every nuanced or implied detail. By using an issue tracker we avoid as many of those problems as possible. The programmers stay happy and the sales/biz people stay happy.

It’s a pain for people to get used to (especially the non-technical people), but things work more like a well-greased machine than a series of fumbles and kitchen fires. It’s a middle-ground solution that keeps things moving.

Don’t expect programmers to be sociable people. Just lay down a good system and a few rules and things will just happen regardless of anyone’s social skills.

I interviewed at (and subsequently got an offer from) Microsoft last year and did not have to answer one puzzle question. YMMV.

Congratulation on your new child!!!

Reading some of the comments here, Iím starting to think these questions may have a use in screening. Anyone who reacts like some here to a problem they donít like is probably not going to have the maturity to handle the problems they are likely to encounter in the company.

About the prisoner/pirate/monkey puzzle; what is the puzzle? there is no actual question in there. Anywhooo… I guess my answer would be between -1 and the size of the collection of (non inclusive)

Solutionman, I think you should start writing articles…
hehhehehehe
But, what jeff says is true and false…
This article isnt going to convince people from not asking the puzzle questions…
becoz some how everyone thinks that those who can solve puzzles can code…

Really? I’m sorry you feel that way. I think presentation is a terrible way to interview programmers. Communication and Lexical skill while both desirable traits are sometimes mutually exclusive. In fact, I get terribly nervous around presentations, but that doesn’t mean I don’t have passion for my work. I always document my code well, and always have an eye out to be sure my programs are efficient and readable. My management reviews are always terrific. I just dislike presentation. shrug
Except if you used that as your pitch in an interview, you’d be very likely to succeed. It’s clear, concise, and tells them what you consider important in your work. It’s great presentation. Maybe you’re bettter than you think?

I’ve never interviewed anyone, but I always thought it would be good to ask the person to play Minesweeper on intermediate mode. Tell them that you only want them to make moves that they are certain about - if they can correctly state that there are no certain moves remaining, that would be considered winning. I think it would work well even if they have never played, to see them absorb a small set of rules.

I have watched many people play minesweeper and you often see people completely guessing, but also people who know a a few tactics, but that would rather guess than work through 5 or 6 squares to get to a square you can be certain about. It shows if a person is comfortable think with all their register variables active.

I’d like to think I’d have the balls to say if you can explain the relevance of that question, sure, I’ll have a go at it.

I’ve never interviewed anyone, but I always thought it would be good to ask the person to play Minesweeper on intermediate mode. Tell them that you only want them to make moves that they are certain about - if they can correctly state that there are no certain moves remaining, that would be considered winning.

I think I could win it before my first move.

This like the stupid printf questions I had to de-construct back in the 1980’s. The questions have no relavence to the job I do (programming) or to any position I would be interested in. I would likily tell them good luck with with their project and leave.

‘I’ve never interviewed anyone, but I always thought it would be good to ask the person to play Minesweeper on intermediate mode. Tell them that you only want them to make moves that they are certain about - if they can correctly state that there are no certain moves remaining, that would be considered winning.’

I think I could win it before my first move. – Steve W

You would be wrong :). Windows’ minesweeper is guaranteed not to give you a bomb on your very first click. You have a fairly good chance of terminating after that first click, though (especially if you click toward the middle).

I have to say to the military guy: that’s kind of a tough difference, because guessing – that is, estimation given imperfect knowledge – is pretty much central to any field of engineering*. You get real data when it is reasonable, and you estimate when it isn’t. And determining whether getting real-data is reasonable is a sort of meta-estimation in and of itself. That’s why I think how many x (are there/can there be) in y type questions actually have real, germane relevance. I guess maybe it’s the opposite for most military scenarios, but there it is.

The linked article about the guy walking out of the how would you move mount Fuji interview tells me two things:

  1. The interviewer doesn’t pass because the interviewee asked back a question that is really similar in nature. Why would you move mount Fuji. If you have to be able to answer How, why shouldn’t you be able to answer Why with just as much BS. Maybe an eccentric billionaire has contracted your company because the view from his Fuji-facing mega-tower is blocked. Maybe it’s a scheme to realign the earth’s magnetic field and spin characteristics.
  2. But it all turned out okay in the end because the interviewee was too much of an obstinate asshole and it clearly wasn’t going to work.

I don’t think completely abstract puzzle questions are really the best way to go, and I’ve never been asked in an interview to answer a question that wasn’t either a real problem (even if well-known and previously solved) or just 1 fairly-obvious removed from a real problem, but I guess it does weed out a few people who have their strong opinions strongly held. Still, I wonder how common these people are in the real world, and how many people who even comment about just leaving are really just bluffing and full of anonymous bravado.

As an exercise to the mind, I like puzzle questions. To some extent they really do tell me something about a person, but I don’t know that it correlates very much at all to successful developers.

*Yes, I know, not every programmer is an engineer. Some are, and those are the ones that can justify those questions.

I think I could win it before my first move.

The first square you click on a Windows minesweeper board is certain to be empty. I think the algorithm actually waits for the first square clicked, then distributes the N mines among the remaining squares. This is part your strategy, since you should click a square that gives you the best chance of being able to expand.

Some homebrew freeware versions, like the Palm version, and maybe some linux versions, have the possibility of hitting a mine on the 1st click, but not the original Windows game.

My 1980’s programming course interview questions were:

How many piano tuners are there in London?

then

How many of them are blind?

then

Is the Pope catholic?

then

Do bears shit in the woods?

And… I got the place!

ps I made up two of the above questions.

Thankfully, back when I was applying for jobs potential employers didn’t such questions. They were more interested in what you could do, and how cheaply you were willing to do it.

As for Mount Fuji, it’s already moving in most frames of reference. To get it to move, one must only wait. But in one special frame of reference, Mount Fuji will never move, no matter what forces one applies.

  • Lepto

It would be interesting to here this topic discussed on the SO podcast as Jeff and Joel obviously have polar opposite views.

The more I think about it the more I can see some merit in Joel’s point on impossible questions - Smart candidates will realize that you are not quizzing them on their knowledge, and they will enthusiastically leap into trying to figure out some back-of-the-envelope answer. Not-so-smart candidates will get flustered and upset… But I still think it ought to be possible to achieve the same effect within a more relevant context.

As many of the commentors pointed out, there is no silver bullet. However, there are skills that employers are willing to give employees time to learn and develop during their career.

Communication is one of these, very often, especially for entry level positions.

However, problem solving is (largely) not a learned skill. It is something that is (hopefully) developed within you earlier.

When I interviewed at Microsoft, I answered several puzzle questions but they seemed to be dying out soon thereafter.

One of the more interesting interview techniques I’ve heard was given by John Robbins: he had people bring in a printout of an example of good code with them to the interview. The subject didn’t have to have written the code (could have, didn’t matter), but was to be prepared to discuss why they considered it good. It served as a springboard into discussion as well as a glimpse into the interviewee’s thought process, without the pressure of having to write good code RIGHT NOW as part of the interview.

None.

Interesting. Your recommendation that interviewees give a short presentation on their past work comes right out of Tom DeMarco Timothy Listers’s landmark book Peopleware. In chapter 15 - Hiring a Juggler, they suggest the very same thing. Probably a good idea, but I’ve never been able to directly apply it in any interview situation.

For interviews I’ve given, I’ve never liked the open-ended Fermi questions. They do allow interesting insights into a person’s thinking process, but they are too off the wall. There are other ways to approach this.

Although I haven’t applied the 10-15 minute presentation idea, you can get some sense of the depth of a person’s experience by asking interviewees to talk about some particular aspect of what they’ve worked on – what was the hardest code you’ve written? Tell me about the challenges in the XYZ project? How would you have improved the RST project?

Some interviewees just won’t talk. If they can’t discourse for 3-5 minutes on some interesting aspect of their work – they go to the bottom of the pile. If they can’t remember key details of some problem they worked on intimately – bottom of the pile.

One item we did adopt from Peopleware is that we make interviewees code. Part of the interview process is a 30 minute session in which we introduce a moestly difficult problem, and ask them to write code for a solution. The actual code isn’t as important as the process of watching them solve it. But, at the very least, we don’t hire jugglers without watching them juggle.