I’ve worked at a pretty diverse range of companies from the massive (IBM, Microsoft) to the merely large (Amazon, Groupon), to the small (Boom, Pelago), to the positively tiny (Kima Labs, Redwood Labs).  In every place I’ve worked, interviews are conducted according to the same general pattern, but with a lot of differences in the details.  This series will explore what I think are the best practices I’ve seen across all those different places.

✧✧✧

Even before a candidate has been identified, the hiring manager should have prepared the team for the potential interview loop(s).  The first step is to actually have a team.  That is, a dedicated group of people for interviewing all the people coming in for a certain position.   This has several advantages:

• the team can form a “group memory” of all the candidate who have interviewed
• the team can coordinate on “focus areas” and even individual questions
• the team will get to know each other’s questions, and therefore save time in debriefing about the candidates

I’d like to talk more about assigning “focus areas”.  Each member of the team should be assigned a couple of very specific areas to focus on.  For example, in the case of hiring a software engineer, one person might be asked to look at algorithms, another object-oriented design, and yet another front-end development skills.  In additional to technical areas, people are generally also asked to investigate some cultural value of the company’s.  For example, at Boom, we value people who like to make things in their spare time, so we might have someone assigned specifically to dig into that a little bit.

Once assigned an area(s) to focus on, each interviewer should plan out what questions they want to ask in order to learn the most possible about that area.  Here it works best to develop questions in two different ways: a simulation of actual job skills, and asking the candidate to relate a story.

Simulating actual job skills works best for technical areas of focus, and the best questions are those which are closest to the real task involved.  So, in the case of assessing programming skills, I’ll always make sure to have a computer on hand, and a set of real development tools installed and ready to go.  Finally, I’ll have made up a question which is a simplified version of some actual challenge I’ve had to solve at work.  The goal is to come up with a question which, as nearly as possible, uses the tools and skills the candidate will actually have to demonstrate at work every day.

Asking a candidate to tell a story (i.e., Behavioral Interviews) work very well in cases where a skill is hard to demonstrate on the spot, or when trying to understand a candidate’s culture fit.  In this style of questioning, you ask the candidate to tell a story about a time when… you fill the blank.  These are often things like: you had to deal with a difficult customer, you missed a deadline, you were forced to be innovative, etc.  These can also be much more specific.  For example, I might ask a software engineering candidate to tell me a story about when they had to fix a particularly nasty bug in a piece of code they weren’t already familiar with.

It’s extremely helpful for each member of the interview team to use the same questions for each candidate for a particular position.  This allows them to:

• get better at asking the question in a clear way
• get a sense of what good and bad answers look like
• figure out what guidance works to help a candidate if they get “stuck”
• be able to compare answers directly between individual candidates

This also allows the other members of the interview team to plan their own questions to avoid any possible overlap: especially when multiple people share the same areas of focus.

✧✧✧

At this point, you’ve got your team together, and you’re ready to start talking with candidates.  In future posts, I’ll talk the best practices I’ve seen around getting candidates to show up, what to do before they arrive, how to conduct the loop, etc.