I've got one too [1]. Your's looks much nicer than mine. I'm just an occasional dabbler in JavaScript, so it is not surprising that mine is crude.
I wrote that after reading this HN discussion [2] where someone was describing how they interview. They set the candidate up with a good JS development/test environment that the candidate is comfortable with, and ask them to implement as much of Minesweeper as they can in one hour. They also said no one has ever finished in that one hour.
As expected, I did not come anywhere near doing it in an hour. Wall time was about 7 hours, but I was doing other things during that, so it was about 4 hours working on Minesweeper. About an hour of that was testing and stumbling around the Mac character viewer trying to find good characters for bombs, flags, and such.
I'm kind of surprised no one has done it for the interviewer in an hour.
As I said I'm only a JS dabbler. Basically, every couple of years or so I'll have to do a little bit of basic JavaScript to do some simple DOM manipulation or form validation. That's just enough to keep me sufficiently aware of JS that I can at least do some reasonable guessing and googling.
I'd expect an actual JS programmer to be much faster than me.
I just tried a version of this as a test for myself. I was able to create a very serviceable minesweeper clone in pygame, finishing up at almost exactly the 1 hour mark.
I didn't have time to include a game-over animation, an in-game timer, or a way to select different settings, but the core mechanics were all there.
Pygame is a very nice environment for games programming when you want to do something fairly simple.
It sounds like a test of your ability to abstract, componentize, and prioritize. Here's a possible approach to this sort of problem:
Read a brief summary of whatever you are implementing, even if you are already familiar. This will help you understand the breadth of the problem.
Try to list in very broad terms the data structures you will need to store the state of the problem (e.g. for Minesweeper, a grid of tiles, and for each tile some status). Don't worry about whether you are using a list or a vector/array or sparse or dense matrices, just be as generic as possible.
List in very broad terms the logic of the problem. What states exist, what are the beginning/ending conditions (start/playing/win/loss), very roughly how states transition, etc. Again, avoid detail.
Identify the inputs and outputs of the problem, very broadly (e.g. user input, display for game board -- no mention of mouse, keyboard, HTML, or whatever).
Cycle through these phases a few times until they seem to agree.
From there, go wherever your brain takes you, progressively filling in details of your design. You probably still shouldn't start coding.
For a 1hr exercise, let's assume you've used 15 minutes for the design phase. Now you can begin coding. Start with the very core of the problem, writing data structures and logic around those data structures. Then get some way of displaying them and manipulating them so you can debug with feedback.
With a roughly functioning core, start filling in the rest of the design. Focus on what makes the biggest functional difference with the least effort first, if at all possible, but again, follow your brain. Try not to pick fonts before you've got everything running. Go piece by piece, until time is up.
--
As for what to Google, you'll need to know how to interface with your problem's input and output systems (like a browser), and maybe how to run timers or store your particular data structure, but most of the work is design, not research.
--
For a personal story, several years ago I failed a similar test in an interview. They asked, "How would you make an elevator?" I got lost in the details like what type of screw terminal to use for electrical contacts, and only later realized the value of prioritizing layers of abstraction. Breadth-first search, not depth-first, if you think of a problem space as a graph.
Just an interesting tidbit - you can't bomb (bug) on first click. If you hit one, the board is reshuffled so that your first click is good. Apparently this fantastic UX feature was part of the original game. When someone pointed that out first time I posted it here - I just had to add it.
Looking into it I'm guessing you had console open and in mobile mode (pointer is a dot). Right? In that case there is no "right-click" event in the document context. If you want console open and desktop mode, there is a little icon there to "Toggle device toolbar". Digging into Chrome tools, what a way to spend Sunday night!
P.S - it's with bugs instead of mines just because fontawesome didn't have mines. No puns intended.