My favorite frontend job interview question - hangman

After a lot of trial and error, I finally found my favorite frontend job interview question: Hangman Game :party:.

This is the first part of a series of posts about it, starting from the way I introduce the challenge to the interviewee, leveling it up to dig around about their interests and experience, talking about basic system design and architecture for a web based system, and finally a hands on task.

In this post I will present it, and explain what I (the interviewer) look for in each phase of the question.

Last level in hangman, guess F or the frog gets it.

Not sure what is hangman? give it a shot here. Want to jump to the solution to this question? Right here.

Part 1: Understanding the spec

One of the most common tasks among developers is getting a requirements document (product spec) with a demand to implement it.

Because this is a part of our day-to-day work, it is something that interests me as the interviewer. It goes like this:

I introduce the specifications to the candidate, and tell them they are welcomed to ask any question they want in order to understand what they need to develop.

The spec

Hangman game basic wireframe, to get the discussion started

To make sure the interviewees understood the game – we play together on a white board, and they ask whatever they want to know.

The questions vary between technical concerns such as design requirements, and performance, and can go to UX, edge cases in the game, persistence and more.

For me, this is another indicator of the way the interviewee thinks.

There are no wrong questions here, neither a specific one that needs to be asked.

The goal here is to see if they can imagine more scenarios than meets the eye, and can they predict issues that needs to be addressed on the planning phase.

Part 2: basic system design / architecture

In this stage the interviewee already knows the game and gets a new task: "Design the architecture that fits this game. You can draw a diagram on board/paper of course".

This question aims to see the way the interviewee thinks about web systems, are they curious about things other than pure front end, did they participate in the design of a bigger part of the system they worked on in the past.

The focus here is about:

1. Separation of concerns between the client and the server (perhaps there's no need for the server?).
2. The way they communicate with each other (at least half the times the term "push notifications" comes up – that's the place I ask some questions about it).
3. Why they communicate (is there a specific task only the server does?).
4. When do they talk to each other and who initiates the conversation (when the application loads, on save, for verification?).

Something like this diagram is drawn a lot, and it is a good start to a deeper talk. I tend to ask about the green lines.

Sometimes, the question is not so clear to the interviewee (I guess it's my fault though) so I try some leading questions to help start the engines.

"Do you need a server?"

"What will be its role?"

"Do you need a data base? if so – what would be in there?"

I was surprised by the number of times people said they need a server – and did not really know why, and ones who didn't need one and also did not know why.

Other than a diagram, the real outcome of this phase should be a TALK regarding system design. About why should I choose REST over SOAP over Sockets over blah blah. About the ability to analyze a system before deciding that it need a DB or doesn't. If time permits, I ask them to describe one of the APIs they have in mind for the client-server communication.

This phase in the question helps understanding the state of mind of the programmer. Have a glance of his experience, and see how if he's a buzz word guy or actually knows what he is talking about.

Part 3: hands on

In this part of the job interview, we already drank coffee, said hi, explained the game of hangman, and discussed a possible system design for it.

This is the focus of this final phase:

• Can they code? Is it readable and explainable?
• Do they know HTML at a sufficient level?
• What's the level of understanding concepts like complexity and separation between logic & UI.
• Perhaps they will surprise with great comments, super clear code, new framework..

In this phase, I bring the interviewee a laptop with internet, some text editing software (or an IDE if I'm lucky and IT are nice to me), and a browser. They are going to do some coding.

Because coding the entire game can take some time I chose to focus in a specific part.

This one:

This is the part of the screen that needs to be implemented (The square with the letters and blanks)

The part in the screen that shows the word with the already-guessed letters and some blanks.

To understand the scope of the task, I usually say something like this:

imagine the application loads in the middle of the game, let's say a user refreshed, or logged in to an existing game.

Data about the game comes to the client, and the client needs to draw the word with blanks.

For example:

the secret word is CAT

the player guessed the letters C, J, Q, T.

so the screen should show: C _ T

The interviewee should:

1. Define the way the data representing this state should look like.
2. Use that data as the input for a function that takes it and returns an HTML snippet with the letters and blanks (C _ T) for example.

This takes time, you can give him a few minutes and leave the room ☺

get him some coffee too!!! its always nice to have someone suggesting you coffee.

Job interview 101: Coffee before the interview, during the interview, and after.

After each step its good to discuss WHY did he chose this way to solve the problem, and what other alternatives are there.

And of course, if given enough time – it should be working on a browser.

That's it for now, next post - implementing the game :cat: