After a lot of trial and error, and some very bad interviews I made, I finally found my favorite frontend job interview question for interviewing a front end developer position. Same question is used for both junior and senior developers, with a slight difference in the followup questions.
In this post I will try to present my favorite job interview question for a front end developer position, and will explain what me (the interviewer) tries to look for in each phase of the question.
A Job interview is no fun
Interviewing someone for a job is something that can be anxious for both sides. Both of them want to leave a good impression and not to look to eager about finding someone for the job, or getting the job. And obviously, people tend to get nervous during an interview.
To lighten up the atmosphere a bit, I like the questions to be about games or other “fun” areas, that still can provide the stage for the interviewee to show their skills, motivation, etc.
My all time favorite frontend job interview question is.. Hangman!
Drum rolls… THE HANGMAN JOB INTERVIEW.
Not sure what is hangman? give it a shot here.
Want to jump to the solution to this question? Right here.
So I decided to write a few 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.
Disclaimer! Although it is my favorite front end interview question, some of my colleagues disagree 🙂 you are welcomed to disagree too 🙂
Part 1: Understanding the spec
One of the most common tasks among developers is getting a requirements document (AKA the “spec”) with a demand to implement it.
It is pretty trivial, but because it is, its worth a small discussion.
It goes like this…
I introduce the specifications to the candidate, and tell that he/she is welcomed to ask any question they want in order to understand what they need to develop.
This simulates the type of interaction I had A LOT between dev and product people.
This is the spec:
To make sure the interviewee understood the game – we play together on a white board, and they are asked to ask what ever they want and need to know how to implement it.
The questions vary and can be pure technical like: Are the measurements described are in pixels or in inches, what is the height of button X. Some ask about the user experience – what happens when a user wins or loses, does a message show? what happens on refresh? how a user logs in/out? what about words with the same letter twice? is the game also in RTL? is there a length limit for the words? and many many more. Personally I try not to answer to directly but to ask their opinion, do THEY think it should be responsive for example?
For me, listening to the questions asked, is also a way to know if they encountered these kind of problems before.
Important! 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”.
What does that mean? This question is aims to see the way the interviewee thinks about web systems, is he/she 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:
- Separation of concerns between the client and the server (perhaps there’s no need for the server?).
- The way the 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).
- Why they communicate (is there a specific task only the server does?).
- When do the talk to each other and who initiates the conversation (when the application loads, on save, for verification?).
Some thing 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.
A pretty schematic way to explain how the game’s works in terms of client-server
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
thanks for reading so far 🙂
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?
- Does he know HTML in a sufficient level?
- What’s the level of understanding concepts like complexity and separation between logic & UI.
- Perhaps he 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:
The part in the screen that shows the word with the already-guessed letters and some blanks.
The 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:
- Define the way the data representing this state should look like.
- 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.
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.
Want to see the implementation and my way to answer this question, here.
That’s it for now. Would appreciate your comments!