image source:

How to Interview (when you’re the interviewer)

Interviewing can take up a huge chunk of time at a growing startup. Over a two year period, I administered 150+ interviews at Greenhouse as we grew from a 15 person company to a 200 person company.

[Screenshot from Greenhouse Recruiting showing I submitted 148 scorecards] oops, I didn’t always fill out my scorecard!

As a software developer, doing even 3 interviews a week can feel like a huge disruption when you’re used to lots of continuous focus time. Once you add in prep time, time to fill out scorecards, roundups with other interviewers, and other ancillary activities, you’re losing a day or more each week! As a result, interviewing can often feel like a chore that takes us away from our primary and preferred function.

Is it worth it?

Well, I got to help hire a third of our team, including 3 directors! It’s been super rewarding to watch the nervous strangers we placed our bets on reveal themselves as capable and confident contributors. On a personal level, I feel like interviewing has helped me become a better engineer and collaborator! An hour at a time, I get to try out a different working style and problem solving technique and bring the strengths of each back to my own work. And if I can create a safe, supportive environment when working with a stranger, then doing the same for my co-workers becomes easy!

Many of our onsite Engineering interviews involve some kind of collaborative coding exercise. If we’re not careful, this can easily become a stressful experience for the candidate. Imagine sitting down at a computer with an unfamiliar setup (we try to have as many editors and languages available as possible, but nothing compares to your own machine!) and trying to solve a new problem in a limited time frame with a stranger who is quite literally judging you. Yikes!

Thankfully, Greenhouse cares a lot about the candidate’s experience. We want candidates to walk away feeling like the time they spent with us was worth it! We want them to feel like they had every chance to show off their skills, that their interviewers were supportive and informative, and that they got a sense of our engineering culture, and liked it!

As an interviewer, I want to establish rapport with the candidate. I want to help them focus when they are starting to panic, and to be able to nudge them in the right direction when they are going down the wrong path. And I want to do this without being condescending or aggressive.

Over time, I’ve noticed a few things that help me achieve these goals:

  • Make eye contact!
    For much of the interview, the candidate and myself are staring intently at the computer screen. The candidate is figuring out what code to write and I am trying to catch bugs for them (in an interview, it’s easy for routine bugs to overwhelm and fluster the candidate). When debugging while staring at code, candidates often get caught up in syntax or how to factor their code and forget to take a step back and think through the larger problem we are trying to solve. When this happens, I stop and physically swivel my chair to face them and make eye contact. They usually mirror my body language and use it as a cue to stop and talk through their thought process. Once we have a conversation about what to do, we swivel back and implement it!
  • Respect their personality!
    During an interview, I need to ask questions to make sure I am following the candidate’s reasoning. Asking questions can help guide the interview, but it can also upset some candidates who become worried that they’re doing something wrong. If the candidate seems to be getting stressed out, I might save my questions for the end of the exercise. Or, I might switch to a more indirect line of questioning by simply reading their code out loud and asking if I’ve interpreted it correctly, which can come across as less confrontational.
  • Show them it’s okay!
    At the beginning of each coding interview, we remind the candidate that it’s okay to not know how to do something. They should always ask us for input or look things up on the internet. Understandably, some candidates are a little hesitant to do this. To show candidates it’s really okay to look things up during an interview, I will do it first and usually they’ll follow my lead. For example, if we need to split a string, I might say that the method exists in Ruby (String#split) and by default it will split per character or you can pass in a separator, but I’d like to look up the documentation to confirm. Once I do that a few times, most candidates relax and are more talkative and more likely to look things up and ask questions.

These are just a few of the strategies I’ve learned from interviewing. I’ve also been able to apply these techniques to collaborate better with my co-workers. Of course, each individual is unique and I don’t always get it right. But hopefully, I’m closing the gap between my actions and my intentions, one interview at a time! ♥

Diana Liu is a Software Engineer on the Product Engineering team.

Are you interviewing? We’re hiring!

Thanks to Aaron, Lauren, and Tharsan for reviewing an early version of this post!