Getting to know the candidate before the interview

When I outlined my breakdown of a typical one-hour interview, I mentioned reading the candidate’s resume prior to interviewing them. Today, I want to dive deeper into what this pre-interview research entails, and why you want to spend time on it in the first place.

In this article, I’ll frame researching the candidate in terms of an interview that’s assigned to you, probably where a recruiter has sourced the candidate, determined which position they’re applying to and assigned interviewers to individual chunks during the day. But, if you’re building a team by sourcing candidates yourself, the concepts below still apply.

Picking the right interview questions

The main reason for getting to know the candidate is to fit them with the right questions that allow them to show their strengths. When I look at a candidate’s resume, I look for the following information:

• What kinds of companies has the candidate worked at? Startups or large corporations?

• What areas of the stack have they worked on? For example, for backend engineering at a large company, are they more focused on the data modeling, REST APIs, or offline data processing jobs? Or have they worked at startups where they worked on the integration of all the layers without diving into each layer separately?

• What kind of academic background do they have? Has the candidate recently completed a four-year computer science program with a heavy emphasis on math? Or are they mostly self-taught with less theoretical computer science knowledge?

These types of distinctions allow me to pick a problem best suited for their past experience. For example, when picking a system design question, I pick the one most closely aligned to the layer of the stack they have already worked on. This way, they can bring their past experience to the table when designing a new system, which is exactly why we would want to hire such a candidate.

What’s more, when actually working through the problem, you can help the candidate with the areas they are less proficient in, so they can focus on the areas of expertise. This mimics how collaborative development will happen on the job.

Making a candidate feel comfortable

Candidates can be shy during interviews, and for good reason. One way to make them feel comfortable is engage them on subjects they are familiar with, which usually entails projects they have worked on in the past. This can come from their past professional experience, or from other sources they have linked in their resume, like their Github profile.

It’s important to note that I don’t ever require a candidate to have or reveal their Github profile. However, if a candidate chooses to include a Github profile, I may take a look to see if they have projects they are passionate about. If they don’t, no problem, I simply ignore that possibility. But again, if they have featured a project, that can be a topic of discussion the candidate will be able to talk about more freely.

Finally, it’s useful to show you’re taking the interview seriously by reading the material the candidate has provided. If you come in with no information about the candidate, even though they have provided a resume, it’s a sign you haven’t put in any effort.

One word of caution however: limit your research to the materials the candidate has provided. That shows you respect their privacy and are letting them drive their story.

An interviewer’s job doesn’t start on the hour. Instead, it’s important to take the interview seriously by understanding who the candidate is. With that knowledge, you can pick an interview question that make sense for that candidate’s strengths, as well pick up on topics to break the ice if the candidate is shy. Most importantly, you’ll show you’re respecting the candidate’s time by reading the materials the candidate has provided.