Before you start
This is not our real interview problem, but it is similar. It's here so that you can prep and benchmark for our interview. It's also here as a sort of "public fizzbuzz" for people to test themselves against if they want to know how they stack up on a standardized problem.
Very few people will finish the entire problem, just get as far as you can. Hacky solutions are OK, but try to note places where you're hacking something for time - you'd want to make sure your interviewer knows the hack is a conscious decision.
If you want to simulate real interview conditions, do the following before scrolling down any further.
Have an IDE open
Refresh on how to take console I/O. Make sure you have a working console (e.g. if you're using JavaScript, you'll want to have Node running).
Set a timer for 25 minutes. Start it before you begin reading the prompt.
During the interview, you may Google small questions or use IDE features, but not prompt an LLM or other generative AI (including Copilot, but not including simple syntax autocompletes).
When you're done, scroll to the bottom of this page to see how you did.
There will be a link to (anonymously) submit your results at the bottom for data collection purposes. Please commit to whether or not you're going to submit that data now, before you know how you did, so that it's as unbiased as possible. (This form doesn't collect your email or any other information, it's not a dark-pattern signup form.)
(This space left blank so you can scroll down when you're ready.)
The problem
In this problem, we'll build a simplified version of the game Minesweeper in the command line.
This is a game for one player. It's played on an NxN grid, where K squares in the grid are marked as "mines". Normally these mines are kept secret from the player, but in this exercise, we'll leave them revealed for simplicity.
On each input, the player may select any square on the grid, and one of two things happens:
If the square they selected is a mine, they lose immediately.
If the square they selected is not a mine and at least one of the squares adjacent to it (including diagonally) is a mine, the square reveals the number of adjacent mines. This number remains displayed in that grid square until the end of the game.
The player wins when they have revealed all squares that are NOT mines.
Step 1
Create a data structure to store the state of a game and print it to the console. (You may use a class if your language is object-oriented, but you do not have to do so.)
Create a 4x4 board and place mines in the first two places in the third column.
Print the board to the console, representing an empty square with a dash (-) character and a mine with an asterisk (*) character. Your output should look like the image shown.
Step 2
Create a function to reveal a square on the board.
This function should take two inputs, a row and a column, and reveal the selected square according to the rules of Minesweeper:
If the selection is a mine, print the board followed by the text "you lose".
If the selection is not a mine, change that square to display the number of mines adjacent to it (including diagonally).
Test your function by revealing the first, third, and fourth squares in the second column, then print the board. Your output should look like the image shown.
Step 3
Take user input.
Prompt the user in the command line to enter a (1-indexed) row and column, separated by a comma (e.g. "2,3" for the second row and third column).
If the user's input is invalid, prompt them for a new one.
Otherwise, reveal the square using the function from the previous step, print the board, and either tell the player that they lost or prompt for another input.
Remove the test code from the previous step, then test your new code by inputting the following. Check your result against the image.
1,1
2,4
2,3
Step 4
Add a win check
After a player's move, check whether every square that is not a mine has been revealed. If so, print "you win" after the player's move and do not prompt them for another move.
Test your code by increasing the number of mines on your board to cover all but the (2,3) and (1,1) square, then select those two squares by entering 2,3 and 1,1. Check your result against the image.
Step 5
Add flood-revealing
When a player reveals a square with a 0 (that is, with no adjacent mines), automatically reveal all squares adjacent to the original square. Repeat this process for any of the adjacent squares that also have no adjacent mines, until all 0's in a contiguous region (and all cells adjacent to one of those 0's) are revealed.
(Note that this can never reveal a mine, so it can never cause the player to lose.)
Test your code by returning to the original board (4x4 with mines in the first two squares of the third column), then entering 4, 1. Your output should look like the image shown.
(Scroll past here when time runs out to see how you did.)
How'd you do?
How far did you get by the end of the 25-minute timer?
[Editor's note: these thresholds have been moved slightly upward since the original publication of this problem as we've gathered more data. The thresholds here are about half a step higher than they were in the original version, since this problem turned out to be a little bit easier than our initial tuning had pegged it.]
If you completed zero steps - well, we won't sugar-coat it, that's not good. This probably means you either (a) got stuck modeling the board or (b) need to brush up on the basic data structures of your chosen language. Both suggest you'll want to do a lot of practice before doing technical interviews.
If you completed one step, you're probably not ready for our interview. Some practice on timed coding is strongly advised before you take technical interviews, at least with Silicon Valley companies where speed is highly valued.
If you completed two steps, that's not bad, but it's a little below the line we'd be looking for. It could be made up for by strong performances on other sections of the interview, but it would be a slightly negative result in terms of coding speed taken in isolation.
If you completed three steps, that isn't an exceptional result, but it's solidly above the average person we interview. This is a neutral-to-slightly-positive result in our book, and whether or not we'd recommend you would come down to other parts of our interview.
If you completed four steps, good job! That's a strong showing and could make up for weakness elsewhere on the interview. You'd need to show a little strength in other places, but assuming reasonable breadth, you'd have a high probability of passing.
If you completed five steps, please talk to us. That's really fast, and we'd be very likely to give you a recommendation based almost solely on coding even with weakness in other areas.
These are just guidelines. In reality, we don't only grade on progress, we grade on things like your code quality and your interviewer's subjective impression of your approach. (For example, handling input on this problem is easier in a weakly typed language than it is with proper type safety.) But you can use the numbers above as a reasonable rule of thumb for the first time you do this problem.
If you committed to submitting your results for data collection at the start of this page, you can do so here. If you didn't, please indicate that you didn't, so that we can check for statistical sampling bias.
And if you want to try the real thing, click this button:
