Last year, I interviewed 51 candidates for Lucid’s engineering department. With a few exceptions, most of these candidates had either just graduated or were looking for an internship before their last year of college. Having just graduated 2 years prior, I see a lot of myself in these students and I clearly remember being in their position. In fact, one of the reasons I chose to work here at Lucid is because I had such a positive experience in my interview.
In the interest of replicating my own positive experience, I want to share a few tips for how to be a great interviewer. Whether you are just getting started with interviewing, or you’ve interviewed more people than you can count, you can be a better interviewer by establishing clear and relevant criteria for evaluation, communicating expectations transparently, and “being human”.
A note on why this matters
Everyone you interview is an opportunity, whether they are hired or not.
Interviews open a window into your company–one that carries much more authority than your marketing campaigns. Don’t let what people see through that window be ugly. Talented engineers aren’t an exclusive club; they have friends at every level of talent and you certainly wouldn’t want to scare them away by mistreating their peers. Additionally, someone who doesn’t meet your hiring bar today may very well meet it tomorrow, and when that happens you wouldn’t want them to turn elsewhere because you made them feel unimportant.
The bottom line is that bad interviewers scare away good candidates.
With that in mind, here are a few tips you can start using to become a better technical interviewer.
Develop clear and relevant evaluation criteria
Even before the interview begins, it’s crucial to establish and go over the hiring criteria for the position. This ensures that you can assess applicants consistently and confidently.
At Lucid, we use a set of rubrics for all of our technical interview questions. These rubrics are short, direct, and cover very simple metrics like progress through a given set of problems, or the relative quality of a candidate’s algorithm (e.g. suboptimal vs optimal, or no completed solution at all). Additionally, we track the applicant scores over time, calibrating them to a normal distribution. Any interview questions that prove too easy or too difficult are dropped if the question or rubric can’t be adjusted to achieve the desired distribution.
Benefits to this process include:
- Create a consistent and fair interview experience for all candidates.
- Reduce interview bias. Interviewers must use the established criteria to directly support their evaluations.
- Keep the interview focused on what really matters: the technical abilities of the candidate.
- Easily incorporate more evaluators into the interview.
Let’s walk through what this looks like at Lucid. First, during our introductory interview we provide some template code in the applicant’s language of choice, and give them an hour to complete as much as possible. The primary scoring metric in this interview is a simple measure of progress through the given work. Then, we can adjust the candidates’ scores based on their code quality and cleanliness.
At this stage in the process, we aren’t concerned with complexity analysis, or optimal performance. It also doesn’t matter what language they chose, and of course it doesn’t matter what the candidate is wearing, or where they are from. At Lucid, because we have clearly defined rubrics, interviewers can focus only on the key qualifications for the position.
Having well-defined criteria leads directly into my next principle.
Communicate expectations transparently
Before we dig in, I want to share a personal experience about the time when I unwittingly interviewed for the wrong position.
As a student, I interviewed with a large, well-known software company. I spent plenty of time preparing for the traditional style of challenge, but during the interview I was given a different type of problem, with a different focus. While I was thrown off-balance, I stumbled through as best as I could. By the time I had finished answering the question I was ruffled because I had focused on the wrong things–it just wasn’t what I had prepared for.
Afterwards, during a brief exchange with my interviewer I got the strong impression that I’d been interviewed for the wrong position. The roles were similar enough that it hadn’t been obvious from the get go, but in the end it was clear something was wrong. I spoke with my peers, who had also been interviewed, and realized that the questions they received were much more familiar to me. I also realized that this situation could have easily been avoided if the interviewer had just taken some time to establish expectations, and orient me to the interview.
Now, when I sit across from a potential Lucidite, I want them to succeed. To do this, I start by telling them everything they need to know about the interview and what I’m looking for. Obviously, you can’t give away the actual solutions to the problems, but, you can orient them to focus their attention and effort in the right place.
At the start of every interview, you should make sure the candidate has read any relevant instructions and you’ve talked through them. Don’t let them get started if you’re not confident that they know what they need to do. Tell them frankly about what you’re measuring and what you’re not and highlight areas where the interview may differ from what they might expect. Ask if they have any questions, and encourage them to ask again later in the interview if, at any point, they aren’t sure what they’re trying to accomplish. The applicant should feel confident in the validity of the interview, and confident in themselves.
When the interview is “over,” there are still opportunities for transparency. Sometimes applicants ask me for feedback, and when they do I tell them honestly what I thought they did well and where I think they could improve. Remember, stick to the criteria. I point to specific examples in their code that could be better designed or more modular, and point out decisions they made that saved them time or impeded their progress.
I know some interviewers are worried that if they give negative feedback, the candidate will get defensive and it could become awkward–this is understandable, but it ultimately prioritizes the interviewer’s comfort over the candidate’s success. As the interviewer we should put aside our discomfort and aim to give the candidate tangible feedback they can use to improve for future interviews. Just like when you’re pursuing a long-term relationship, when you’re hiring for your company keep things honest and transparent. Show applicants your company is worth their time.
Take a look around YouTube or Reddit and see what programmers think of interviewers. It’s not flattering. Responses range from, “Sr. Engineers that seem more interested in their own resumes than their applicant’s,” to, “the interviewer seems to take pleasure in watching someone squirm to solve a problem that the interviewer read the solution to 15 minutes earlier.” While these examples may be exaggerated, and the problem may not be as widespread as reported, these perceptions come from somewhere. Don’t let it come from you.
Think back to your first steps into your early career. Remember how nerve wracking it was to put yourself out there for an interview. Some people will go through dozens of interviews before they land a job. It’s a stressful process, and if it’s been years since you experienced it yourself, it’s easy to forget what it feels like.
There is a power dynamic in an interview. The interviewer determines a part of the interviewee’s future. They may think of themselves as just an average person, but to the applicant the interviewer can be seen as fickle, passing judgement on a whim. Part of that power may be imagined but as an interviewer be responsible with the part that’s real, and be gracious with the part that isn’t.
I try my hardest to show the candidates I interview that I’m just a guy with a job, and they’re just a person looking for one. Here are some strategies I’ve found helpful to put candidates at ease:
- Ask them how to pronounce their name. I usually do this at the beginning of the interview.
- Talk about their education experience. If they went to my alma mater, I ask them about their classes or certain professors.
- Share my current projects. I don’t do this to brag, but to give them an idea of what we do at Lucid.
- Don’t be afraid to make jokes. I’m always happy to poke fun at clunky programming language features.
Formality is useful and professional boundaries are appropriate, but it is not an end in itself, and I want candidates to get a feel for how we would interact as peers.
If you’re a little introverted, and “small-talk” isn’t your strong suit, don’t feel like you have to put on a show. There is something distinctly human about just telling someone what you’re trying to do. You have my permission to say “I just read a blog post about being a good interviewer; I’m not great with people but I’m going to try my best to help you feel comfortable during the interview.”
If you’re already following my last principle, I think you’ll find that this one doesn’t take much. Some of the coldness and austerity alluded to at the beginning of this section may just be the combination of nervous applicants and introverted interviewers; luckily, the less evidence there is behind that impression, the easier it is to break.
Ultimately, “being human” means being the same person before, during, and after the interview, and treating the interviewee like you would a coworker
Time to put it into practice
Nobody wants to be a bad interviewer, but approaching interviewing without any introspection or preparation is an easy way to run that risk. Interviewing is a display of your character, and your company’s culture. Every company wants to hire great people, and every employee wants to work with great people.
Great interviewing is achievable, and it doesn’t require special qualifications. It starts behind closed doors, designing an interview to measure skills, and defining clear criteria to measure performance. It’s executed by honestly and diligently preparing the interviewee for success. Finally, it’s guaranteed by remembering to share your humanity with every applicant. If interviewers remember these principles, and put them into practice, it might just put an end to the horror stories. In the beginning you will become the exception, but if we all try a little harder, we can become the rule.