The Hardest Interview Puzzle Question Ever

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?


How many of them are blind?


Is the Pope catholic?


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.


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.

I was interviewed for a position at Microsoft and I was asked a puzzle question. Did not answer it, but passed the interview!

Don’t forget, if you are going to ask a candidate to write some code, give them a keyboard and at least Notepad. NOT a pencil and paper. I hate it when I literally have to write out code. That’s not how I do it on the job, and I can type a lot faster than I can write. I can’t tell you how many times I’ve had this happen.

For extra realism the test should replicate the conditions the candidate would be working in. Full development environment. If you’re hiring me for a MS shop, give me Visual Studio with all the trappings (intellisense, etc).

To continue with the juggler analogy, that’s like giving the juggler candidate paper representations of balls to demonstrate with, not the real thing. Yeah, you could juggle them, but it wouldn’t be the same.

congratulations on surviving hospital, having babies is natural, going to hospital can be fatal!

Following your recent bad apple post, I would have thought a way of assessing how the person makes people feel, let’s hope your ‘Would your team enjoy working with this person?’ question answers this.

Microsoft used to have interviews like that… not anymore. get a life.1!!

The problem with presenting with past projects at other employers is those damn company secrecy policies

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

It’s not in the employeers interest what you can do, (by the way is all crap)(because if you get interviewed by the executive, he doesn’t understand it anyway), but how cheaply you are willing to do it.
The programming skills aren’t important at all, it’s your social ability and how you communicate…
If you even can’t concatenate two strings together that’s not so important (beacause I promise you there are a couple of people calling themselves programmers that hardly can do that).

I am non-native English speaker, too…

communicating! communicating! communicating! communicating! …

such like developers! developers! developers! …

I always feel anxiety before using English… Using foreign language is so difficult.

You are recycling these posts. Why do you keep talking about this Mt Fuji stuff? All the comments are the same except for the inane stuff about Minesweeper.