Conducting a front end interview 101
About the author 📝
My name is Charles Stover. I have been a front end engineer for nearly 20 years. I used to be terrible at interviewing — completely unhirable. That’s not to say I didn’t have the talent; I didn’t have the salesmanship. I treated interviews the way institutions treated education: pass/fail examinations for demonstrating knowledge and comprehension. That is not what interviewing is, and that is not what you will learn to do in this article. I spent a long time trying to understand why I couldn’t land or pass an interview despite having deep knowledge in the field. I sought resume reviews and practice interviews with real companies, and it eventually worked. I was able to begin my career, simply later than it need to be. The way my misunderstanding of the interview process delayed my career growth triggered an innate passion in me to learn the art of interviewing. I studied how to be an interviewee and published my discoveries on Becoming the junior developer that companies want to hire. Much of what I learned about being an interviewee was by being an interviewer. My innate passion led me to the interviewer side of the table just as much as the interviewee side. I want to see talented developers succeed, and I wanted to learn how to get them there. I’ve have spent just over a year at each Walmart and AWS conducting interviews for front end engineers. I have taken formal training at both companies on how to interview correctly, and I want to pass this knowledge onto others, to ensure the best developers get picked for the job.
What to expect 🎯
Nothing in this article will be unique to front end. It is called Conducting a front end interview 101, because I have only ever conducted front end interviews. While I see no strong reason this introduction cannot apply to other interviews, I do not feel comfortable making that guarantee. I have molded my interview template throughout the years of interviewing based on my experiences conducting front end interviews. Every question has been front end, and every change has been the result of a front end question. My examples will be front end examples, but they can be changed as needed to fit other job descriptions.
This article will not give you quotable questions to ask or brain teasers for candidates to solve. This is not a question bank, and I will advise against using one.
Whether conducting a phone screen on on-site, some parts of an interview won’t change. This article should allow you to outline both cases, and it makes the assumption that your phone screens include live code.
Introduction and outline 🌐
Total time: negligible
It probably goes without saying: the first thing you should do is introduce yourself. Tell the candidate your name and your job. Whether you are a manager or developer may impact the questions they will want to ask you during or at the end of the interview. It can also impact the answers they give, as they can tailor the skills demonstrated accordingly.
My name is Charles Stover. I’m a front end engineer on the Amazon CloudWatch Logs team.
The candidate quickly knows what to call me, how to reference me in the future, to answer questions as if a developer is judging their development skills, what questions to ask in case they need help solving a problem, and what questions to ask at the end of the interview (“What is the CloudWatch organization like?” and “Is your team hiring?”).
If you are performing an in-person interview, offer the candidate a restroom break. They may have traveled far or already been through several other interviews.
Before we get started, do you need a bathroom break, water, or coffee?
Finally, outline the interview so that they know what to expect. This can ease some of their anxieties of the unknown and give them a little more time to prepare their topics of conversation in advance. If you don’t tell the candidate that you have allotted time at the end of the interview for questions, they may ask them randomly throughout the interview. This can derail the conversation and make it difficult to manage time.
I’ll spend the first 10 or so minutes discussing your work history. There are no right or wrong answers. It just gives me an idea about what you’ve already learned in the past and how deeply you know it. This helps me adjust my conceptual questions accordingly when we get there.
I’ll spend about 15 minutes on conceptual or behavioral questions. Then, we’ll move on to live code for 25 minutes. I’ve saved the last 5 minutes for any questions you have for me.
This outline gives you an important ability to cut off long-winded candidates. Managing your time is important. You need to allocate an appropriate amount of time to each category of the interview in order to accurately assess the candidate. If the candidate spends too much time discussing behavioral answers, you have no data points by which to judge their technical ability. I end the outline with the note:
If at any point, I cut you off to move to the next section, don’t worry. I deliberately prepare more questions than can be answered in time. I would rather have too many questions than awkward silence. If I have to end a section abruptly, it does not mean you did anything wrong or answered too slowly.
This is a powerful nerve-calmer. Some candidates answer too fast, and some candidates answer too slow. That’s just a reality. You cannot prepare an appropriate number of questions, because you don’t know which type of candidate you’ll have beforehand. I always prepare too many questions and cut them as needed. If you do not inform the candidate about your outline ahead of time, those who are slower to answer may believe their unfinished interview will result in a mark against them. That should not be the case. Let them know this, and it trims the awkwardness when you inevitably need to cut a candidate off from finishing a long-winded story.
In case of an in-person interview, I also like to note:
If you see me glancing at the wall clock (or my phone clock), it’s not a sign of disrespect. I’m not eagerly awaiting the interview to be over (or checking my texts)! I am making sure I don’t run over on time for each section to ensure you have enough time for each one. You have my full attention.
Past experience 🐱🐉
Total time: ~10 minutes
Past experience questions benefit both parties in the interview process. It helps soothe your candidate’s nerves, because it is their area of expertise. There are no wrong answers per se, and they are quite literally the subject matter expert on describing what they have done in the past. Starting the interview with a topic they know most about and cannot get wrong is one of the most effective ways to calm the candidate’s nerves before grilling them on technical depth later.
Proofread the candidate’s resume before the interview, and take note of questions you would like answered. Remember that discussing the candidate’s past experience is a conversation, not an interrogation. A good starting point is to ask what problems were solved by the use of a specific technology.
An important quality in a mid-level or higher candidate is the ability to make the correct decisions for the job — not needing to be instructed. For example, if the candidate mentions React, I will ask which version of React was used. If they answer a newer version, I ask what problems were solved by the new context API or hooks. This allows me to gauge the candidate’s depth and breadth of knowledge. Given a React project, can they tackle complex problems with simple solutions? If they answer an older version of React, I ask what features in newer versions would be most beneficial to their project. This tells me whether they keep up-to-date with these technologies. Can they make meaningful decisions when starting new projects?
If your workplace has an high rate of lying applicants, discussing work history is the best way to identify it. Ask what problems were solved by technologies and how they were solved. I had a candidate claim to have written accessibility tests; when asked how to write an accessibility test, they defined a unit test. Probing made it clear that despite a resume full of “testing” experience (unit, integration, end-to-end, accessibility), their only experience with testing had been reading a few articles on what unit tests are. Watch out for these impersonal definitions. The candidate should be speaking about their personal experiences, not about definitions they studied beforehand.
Ask about challenges faced and what solutions worked. Ask what they enjoyed and hated about their technologies. This allows the candidate to communicate technical ideas. Can they put complicated topics into spoken language? You may even learn something.
Watch out for vague answers. Don’t ask questions that have simple yes or no answers. For example, “Have you ever worked with React?” You are giving the candidate an easy out to boost their interview without actually doing any work. “Yes, I’ve worked with React extensively.” The candidate may have never touched the framework, but you would be none the wiser. When you receive short answers, ask follow-ups that require context. “What problem did React solve? How quickly did you team adjust to the migration to Angular and why? What did you like least about Vue?”
Behavioral and concept questions 💭
Total time: ~15 minutes
For a phone screen, I focus heavily on technical questions with some behavioral questions sprinkled in. For an in-person interview, I focus on behavioral questions. This is because the phone screen already covered technical concepts, and the following live code will solidify it.
Identify the most important technical comprehensions or Leadership Principles of your team. It may be important to your team that new hires be familiar with multi-threading, inheritance, polymorphism, specific frameworks, thinking big, or bias for action. Use this time to ensure the candidate can accurately deep dive these topics.
Avoid questions from Google search results. If you found the question online, so did your candidate. You aren’t learning anything about the candidate’s comprehension of technologies. You are learning how much they can memorize before an interview, and that won’t help you in the long run. For this very reason, I will not be including example questions.
Live code 👨💻
Total time: ~30 minutes
For the live code section, you are trying to determine the candidate’s coding ability, though processes, and problem-solving skills. Do not throw a massive question onto the candidate and sit back. Remember that the candidate is nervous and under a lot of pressure. Panic is expected, and the candidate should not be faulted for it.
After outlining and describing the problem, ask the candidate to start with the function signature or classes. This simple step leaves keeps the candidate focused on starting the task instead of wondering about optimal long-term solutions.
If the candidate is ever silent to the point where you don’t know exactly what they are thinking, ask or remind them to think out loud. This is very important. The candidate may not be stuck — they may be prematurely optimizing out of nervousness. Many candidates believe that if their answer isn’t of the highest quality that they won’t be hired. It is unreasonable to expect someone nervous to handle even the simplest problem perfectly on the first try. You should want to see a brute forced answer that is cleaned up later. A candidate that stops talking, more times than not, is trying to impress you with a perfect implementation. Coach the candidate to think out loud and encourage them not to trail off from the topic at hand. If they need to create a data structure to store state, they need not worry about how to iterate over it just yet.
Like the previous section, avoid Google search results. You are not learning the candidate’s thought processes or problem-solving skills if they are regurgitating an answer from memory instead of solving the problem.
The candidate will forget many things, and that’s okay. Once a brute force solution is provided, probe them about edge cases, error tolerance, and optimization strategies. If not a lot of time is left in the interview, make sure they do not actually write the solution to these edge cases or optimizations. It simply takes too long. Ask them to describe the solutions out loud instead of writing them. Either they can understand and communicate technical implementations or they can’t, and that’s really what you want to know here.
Watch out for implementations that are overly complicated without reason. A brute forced solution is expected, but unnecessary complexity is likely the result of a lack of technical comprehension.
Total time: ~5 minutes
Save the last five minutes for questions.
That brings us to the end of our interview. Do you have any questions for me?
You may be asked to provide immediate feedback. It is rarely your place as an interviewer to provide this feedback. Be prepared to answer this question evasively but helpfully.
I am unable to share feedback with your directly. However, after the interview, you should be able to reach out to HR or your recruiter for formal feedback.
Before starting each interview, I copy a template (provided below) and fill it in with questions I generate from their resume.
## About me
* My name is Charles.
* I'm a front end engineer at Amazon on the CloudWatch Logs team.
* Work history - 10 minutes
* Behavioral/concept questions - 15 minutes
* Live code - 25 minutes
* Questions - 5 minutes## Work History
Clock: XX:00 - XX:10**Question 1**
**Question 5**## Behavioral/concept questions
Clock: XX:10 - XX:25**Question 1**
**Question 5**## Live code
boilerplate code here
**First step of implementation**
e.g. "Create the data structure."
or "Write the function signature."**Additional step(s) of implementation****Additional task(s) if completed in time**## Questions
Clock: XX:50 - XX:55**Do you have any questions for me?**
I include technical concept questions that I will remove depending on how they answer about their work history. For example, I include questions about Angular and React and remove any with which they are not familiar. I also typically include questions about Redux and remove it if they say they have no experience with the library.
If you have any questions or great interview suggestions, please leave them in the comments below.