The first time I interviewed a candidate for a front end developer role, I was terrified. Not necessarily because of the public speaking component, but mainly because I had always known interviewing to be a stressful and intimidating experience. I felt that I needed to project confidence and authority, but was worried that any candidate would be able to see right through me.
When the time came to conduct the actual interview, I decided to throw all of my plans away, and have a friendly conversation with the interviewee as the primary means of evaluating their experience and qualifications for the role.
It was the best decision I could have made.
I’m going to share a few interview practices that have worked well for me, in hopes that they might work for you as well.
What not to do:
- Don’t wait to view a candidate’s resume until a few minutes before you’re about to interview them.
We’ve all been busy, and this might seem like a necessary time-saver, but it’s unfair to the interviewee. No one wants to be asked a series of questions whose answers can be found on a document they’ve provided well ahead of time. Additionally, a great deal of time can be saved during an interview by learning about the candidate before you meet with them for the first time. The resume is a great way to do this. - Don’t do most of the talking.
I can’t stress this one enough. Tell the candidate about the role and the company. Ask them a few questions about themselves (likes, dislikes, etc), evaluate them technically (if you need to), and stop there. Letting the interviewee do most of the talking accomplishes a few things. First, it shows that you’re actually interested in them. Second, it puts them at ease, allowing the interview to feel more like a friendly conversation than an interrogation. Third, it allows you to receive more information regarding who the interviewee is, and how they’ll fit into your organization. Simply put: talking more than a candidate during an interview is like hiring a plumber to sit and watch as you try to fix your sink. You’re just going to end up wasting everyone’s time. - Don’t ask the candidate to code in front of you.
Whether it’s on a whiteboard, computer, or napkin, this practice needs to stop. Interviews are stressful, and no one does their best on a technical challenge when they are stressed out. We forget about browser support, helpful language features, and subtle anti-patterns. Most of the time we are too worried about a time limit (obvious or inferred) to focus on the solution we are trying to provide.Furthermore, situations that require a single developer to write working production-ready code on a whiteboard never occur in the real world. We avoid these situations, and actively adjust our tools and processes to prevent them. As a result, these tests offer no insight into how a candidate might approach and solve a problem. Realistically, when you run into a an issue that requires you to stop and think about a sound technical approach, you research. In technical interviews however, StackOverflow and CSS-Tricks are not available. By default, the resources you turn to the most when faced with a challenge (Google and your coworkers) are prohibited from coming into the interview room with you. If you want to see how well a candidate can code, look at their portfolio and open source contributions, or give them a take-home challenge (preferably both!). - Don’t ghost the interviewee.
What you should try to do:
- Be friendly.
While this one should be obvious, many of us have been the victim of an interview that felt more like a heated interrogation with a time limit. An interview should be friendly, as if you were meeting a future coworker. The interviewee (whether they did well or poorly) should leave the interview feeling like they made a new friend. Always walk out of a room with the intention of making that person an offer, or sending them an encouraging email in which you tell them what they can work on to improve their skill set. Treat the interviewee like a human being looking for a fulfilling full-time job. - Ask the interviewee to verbally explain how they write code.
This is how I evaluate candidates technically. I ask them about their technical skills. HTML features, document outlines, responsive designs, how they communicate with designers, rounded corners in CSS, 60 FPS, Array methods in javascript, performance, Node, Gulp, React – I think you get the point. I ask open ended questions that allow a qualified developer to tell me (using words instead of a whiteboard) just how familiar they are with Front End Web Development. I never try to trap them or make them feel like they need to give me a specific answer. Instead, I let them tell me as much as they would like to about HTML, CSS, Javascript, and related tools/practices. It works very well, and if I need more information I’ll ask follow up questions. If I’m still unsure of their skills (after looking at the code they’ve written in the past) I’ll give them a coding challenge. This practice has failed me one time. I’m being honest because no interview technique is foolproof. - Tell the interviewee that they won’t have to do any whiteboarding.
You will watch their faces light up. They will sigh in relief. They will thank you. Most importantly they will open up and talk more, which is what you want. Please, try this just once. It makes a world of difference. - Take your time & ask the interviewee if they have any questions.
If you leave an interview without asking the candidate if they have any questions for you, you’ve failed. Don’t fail.
*Bonus tip: Be honest! If you’re asked about pain points, tell them about the pain points. You don’t want to trick your future coworker into working with you. It’s not cool.