Fizzbizz? Naah. What you want to do is something more like Minesweep. You go, "Mr. or Mrs. Candidate-Person, we're designing a Minesweep game. You've probably played it before. Here are the rules if you need clarifications. I'm handling the front-end, you write something for the backend."
It doesn't matter the programming language they go for or the precise implementation they choose to any one of a number of issues. The question is whether they can build something coherent that actually does what they intend it to. There are basically two main types of candidates: the candidate who approaches the problem and says "I need to loop over every cell in sequence and assign a mine or not based on a random probability! Wait, what do you mean, I need to get a specific number of mines on the board? I'm not sure I can make that happen" ... and the candidate who's worth hiring.
That said, I have seen interviewers use this premise to try and push for one particular algorithm as The Answer (the one where you shuffle the coordinates and take N) under the premise that "pick random coordinates, check, and retry" could be slower on ultra-dense gameboards -- but hey, dude, nobody plays 99%-full minesweeps because they're not fun. Meh.
The interview's pressure makes finding these relatively easy tricks difficult. While in the flow of programming, or discussing the problem with colleagues, you'd probably knock this one out in a few seconds, the power difference in the interview does bad things to the visual reasoning part of your brain.
A good outcome I'd look for is the candidate recognizes that loop and mark will not always produce an exact number of mines.
So the ideal interview question I think gives the candidate is a simple task with lots of pitfalls that arise in the naive implementation. The goal is for the candidate to enumerate the pitfalls, and also develop an abstract representation of the problem. Leave the solution / most efficient algorithm out of it.
The idea of the FizzBuzz is that a lot of candidates are so bad at programming that can't even program FizzBuzz. So you can filter them early and don't lose you time. It's not designed to distinguish between the good and very good candidates.
>Fizzbizz? Naah. What you want to do is something more like Minesweep.
The whole idea is that fizzbuzz weeds out tons of people who don't know how to do it, plus it's simple to do in a very short meeting for someone who knows programming it's like 30 seconds tops.
So Minesweeper doesn't make sense in this context. Even trying to convey the exact set of rules it will have to follow for the gameplay takes time (and, no, not everybody has "played it before").
"There are basically two main types of candidates: the candidate who approaches the problem and says "I need to loop over every cell in sequence and assign a mine or not based on a random probability! Wait, what do you mean, I need to get a specific number of mines on the board? I'm not sure I can make that happen" ... and the candidate who's worth hiring."
Since this interviewer seems to have made up their mind already with pre-conceptions of which candidate is worth hiring, what is the "correct" answer to this question? "Pick random co-ordinates, check, and retry?". I'd like to know, so I can give that as my first answer if I come up before such a person in the interview.
This right here is why everyone tries to game the system and come out with the "worth hiring" answer as if they had thought it out themselves. We are not even given an opportunity to ask questions, maybe come up with an answer, say "That's not optimal", and work towards a good answer -- which is the flow you would use for working at your day-to-day job. And, for the record, I started playing Minesweeper last year, and hadn't even touched it back in the day.
Any answer that gets the job done works. Looping through the mines in one pass with appropriate adjustment of probability (never seen it). Pick random spot and retry. Take all coordinates, shuffle, take N. Something I've never heard of? Sure, if you apply it and it works.
The preconception is that someone who isn't capable of coming up with a way to distributing X values into a data structure representing a M*N playing field isn't worth hiring. It's a stupidly simple task, light on the algorithms (much like the day-to-day programming tasks) and heavier on the "come up with something coherent and quasi-organized to accomplish a very simple goal" in a program.
As for the rules of Minesweeper, if you're rusty, I have a printout. :b
>Since this interviewer seems to have made up their mind already with pre-conceptions of which candidate is worth hiring, what is the "correct" answer to this question? "Pick random co-ordinates, check, and retry?"
The most efficient way (which is arguably unnecessary for Minesweeper) is to treat a 10x10 play field as a 1 dimensional array of size 100, stick your X number of mines in the first X cells in the array, then use something like the Fisher-Yates shuffle* on the array.
* Y = random number 1-100. Swap contents of cell Y and cell 100. Y = random number 1-99, swap contents of cell Y and cell 99. Repeat for entire array.
It doesn't matter the programming language they go for or the precise implementation they choose to any one of a number of issues. The question is whether they can build something coherent that actually does what they intend it to. There are basically two main types of candidates: the candidate who approaches the problem and says "I need to loop over every cell in sequence and assign a mine or not based on a random probability! Wait, what do you mean, I need to get a specific number of mines on the board? I'm not sure I can make that happen" ... and the candidate who's worth hiring.
That said, I have seen interviewers use this premise to try and push for one particular algorithm as The Answer (the one where you shuffle the coordinates and take N) under the premise that "pick random coordinates, check, and retry" could be slower on ultra-dense gameboards -- but hey, dude, nobody plays 99%-full minesweeps because they're not fun. Meh.