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.
Top comments (14)
I personally hate the homework. I'm a mom & with work, school activities, etc, I don't have spare time outside of my designated work hours - and I can't do my best on homework if I'm distracted with the bajillion other things going on.
My favorite coding interview was one where I was told exactly what I would be building and what the expectations were for the code. I was asked to bring my own dev environment, I was able to look up things on the internet or even ask seniors in the room any questions I had. This was 100% a real world example. Everyone could see where my insecurities or weaknesses were, based on the questions I looked up or asked, but they could also see my strength. I have anxiety, and oddly this was the least stressful event of the whole ordeal. On the other hand - I've walked away from interviews that pounced with the "surprise whiteboard questions". Anxiety overload. :)
Thanks for sharing, great article.
I love your input here and in the other thread. We are ideologically aligned with your point of view, but you gave me a lot to chew on.
Good :D
I've had some bad interviews where the odds were stacked against me (and I didn't even realize it.) :(
I'm hoping by sharing, it helps companies get their *** together for a more inclusive and welcoming interview process. Also - this conference talk was really helpful at attempting to identify where some of my fallouts happened during standard interviews and how I can prevent these fallouts on my own team. :)
vimeo.com/103598190
Yay, Kerri Miller is awesome!
Interesting thoughts. In a perfect world, we could totally do this, but there's another factor: as interviewers, we need to weed out massive egos, unqualified individuals, and whatnot. While many of your points are good, I've learned the hard way NOT to do some of the nice-sounding things you describe, as they've led to me to make some disastrous hiring choices.
1) I do believe in giving someone a chance to do coding before the interview (so I can see them at their best), and I also like asking them how they code. However, I also need to watch them doing it. YES, it's under pressure, and YES we factor in their nerves, but it does tell us a lot about how they handle some scenarios.
The point of whiteboarding isn't actually to see if they know certain algorithms and data structures (although it is useful to see if they are capable of actually coding at all). When the nerves kick in, an individual's deepest habits and assumptions rise to the surface, so I get a VERY good picture of their natural inclinations as a coder. In over three years of hiring, the notes I've compiled from watching people coding in interviews have been spot-on as I see their work at the company.
2) I'm never mean, but I'm also not warm and friendly. Actually, you'll be hard pressed to get any emotion out of me at all. Why? Most humans need emotional feedback to keep a scripted act going, and I want to cut past the script and talk to the real person. I've also learned that if someone displays unwavering confidence (and usually bravado) in that sort of scenario, they invariably have an ego the size of Brazil.
Long story short, interviews are nerve-wracking for a reason. We're not there to make friends, we're there to find out what sort of person you actually are, versus the type of person you're trying to make us believe you are.
There IS an upside to all of this: every person I've ever hired has said that the thrill of getting the job more than made up for the interview experience.
"we're there to find out what sort of person you actually are, versus the type of person you're trying to make us believe you are."
Defensiveness is generally detectable, and it takes different forms. I've never gotten an authentic response from being warm-and-friendly during an interview, but I HAVE had numerous people try to snow me (and a few succeed back then). That's why I switched.
Flat-affect interviews don't necessarily let you get the whole picture of the real person, no, but you at least create an environment where acting is MUCH harder. I've watched people flip between their rehearsed personas like a television in those scenarios, as they try to get some response out of me. But the ones who are just being themselves are constant (and a bit nervous) through the whole thing. They're the ones I hire - and they're also the ONLY ones who have ever done excellent work and stayed on.
All the same, we may have to agree to disagree on this. I'm telling you what I've experienced to be true, without exception (in either direction), in the whole of my experience as an interviewer. I've got a few years of proven mileage behind my points. Maybe you have the same, I don't know.
I'm on the fence between you (Jason) and Tim's arguments about being friendly versus emotionless.
As a recent interviewee, meetings with cold, flat-affect interviewers were a struggle because it felt like I was talking to a wall. I wanted a response to see if they were liking who I was, and vice versa -- after all, we might spend a lot of time together. The silent, lack-of-intent responses made me feel like I was being tested as opposed to being a person who they could work with.
Of course, I can definitely see your argument about people quickly going through rehearsed personas. Being dishonest to get a job is certainly a trait I would not want to work with. Consistency definitely helps, and I agree that it's probably an indicator of authenticity.
To quote you, the interview is there to find out what kind of person a candidate is. That's the same for the candidate, too, though. My perspective is that an interview is a two way street, and both parties are there to learn about each other.
Actually, that's exactly the point of the cold affect. You want to see if I'm liking who you are, but what is the natural response if it's clear I'm not? Typically, one changes how they present themselves at that point until they get a response, but if there's no response in any case, it's easier just to drop the act and be yourself for better or worse. You see? Similarly, if you are acting in any capacity (and maybe we all do a little bit) and you get positive feedback, you'll continue to act. It's just psychology at play.
What I didn't mention (and maybe should have) is that, towards the end of the interview, I have the candidate walk away for a few minutes while I discuss the verdict with my other interviewers. We decide if we need to ask any more questions, and what the answers should be, and then we call the candidate back. Once we decide we want to hire the person, we drop the cold affect and give them a chance to ask us whatever they like before announcing (then) that they're hired.
Thanks for mentioning the end process. I agree that positive feedback for someone who is acting isn't what you want as an interviewer. I'm more of the opinion that people generally go to an interview as themselves, with some extra "I'm meeting my potential boss" friendliness. My experience has been that cold affect makes me tone that friendliness down (my "act"), but also does make me a feel a bit defensive in the interview. There wasn't an environment where I didn't feel comfortable being myself, but it doesn't sound like that's what you're doing.
"The first time I interviewed a candidate for a front end developer role, I was terrified" I thought I was the only one. Great post!
Count me in! I also get nervous when interviewing others
I'm going to conduct part of an interview in about an hour, and this article is a big help even now :)
That's awesome! Good luck!