The 5-minute guide to interviewing software engineers

There’s nothing quite like an awful interview—the kind where both you and the candidate leave feeling as though you’ve just barely survived a terrible first date. Done poorly, interviews can be just like bad first dates: awkward pauses, a dim feeling the other person is avoiding certain topics, confusion as to why you got together in the first place.

My aim here is to help people avoid this feeling. Maybe you’re new to interviewing software engineers, or maybe (like me) you’ve been tasked with planning the interview process for your company. Whatever the case, there’s a reasonably clear set of things to do, and things to avoid.

I learned both—the do’s as well as the don'ts—having interviewed hundreds of engineering candidates for companies like Nordstrom and Microsoft, as well as coaching hundreds of candidates for their interviews via Interview Kickstart.

From these experiences I’ve developed a pretty clear understanding of what makes for a good interview, and what makes for a terrible one!

Three Measures to Find Fit

At Socratic, we follow a three-interview progression:

1. Screening (30 minutes)

2. Technical (90 minutes)

3. Culture fit (30 minutes)

Screening interview (30 minutes)

The screening interview is truly introductory. I start with a run-through of what our business does, and what our tech stack is. I’ll ask the candidate to give a brief rundown of their work history and expertise. The aim here is two-fold. I want to (a) discover any areas of contention and (b) remove any doubts, from both sides.

As part of this, I ask the candidate about the kind of work they love doing, as well as the kind of work they’d rather never do again. The phrasing here matters. It’s easy to talk about what we love doing. Usually you can see passions coming to the surface, and it keeps the conversation fluid.

The dislikes are just as important of course, but I’m also interested to see how candidates convey those dislikes. Do they become irritated or resentful, recalling past lousy assignments? Did they take away anything useful, even if the work itself was a drag? How did they manage doing stuff they didn’t like?

When the candidate merits the next step, a technical interview, I also go over salary range, equity, and benefits. (Not necessary if you’ve included these in your job posting, which I recommend. But sometimes there are valid reasons to withhold.) Neither you nor the candidate wants to go through a 90-minute technical interview, only to find you’re not in the same ballpark on compensation.

Technical interview (90 minutes)

The content of the technical interview varies by role and seniority, but in all cases the coding challenge should be a direct reflection of the coding done on the job. Ideally it’s a real coding example your team recently worked through.

At Socratic, for a full-stack developer, we ask them to do a front-end challenge in React and a backend challenge with some API’s (payload, routing etc.). While it’s great if a candidate can complete a challenge, that’s not the outcome that is most important. I want to understand how they work through a problem, what their process is and what they do when they hit a roadblock.

For that reason, I always ask the candidate to speak openly about their thought process, and try to engage them in a conversation as we go through the code. If they get stuck, I have no problem if they want to look up things like syntax. We all forget syntax. We all look things up. Let’s interview in a way that honestly reflects that reality.

Also important to keep in mind: you want the candidate to succeed! You want this person to be exactly who you’ve been looking for. You want them at ease, and comfortable. If the technical interview feels antagonistic, if it feels like a trick, you’re unlikely to get a person’s best work—and you may alienate them in the process.

Culture fit (30 minutes per)

We often have multiple interviews at this round, as the candidate gets to meet both leadership and other people on the team they’ll be joining. It’s a chance for them to get a better sense of who we are, and for the team to get to know the candidate.

“Culture fit” can be a loose term for do I feel comfortable working with this person? That’s fine, but you want something beyond just gut feel. Some questions that may help clarify that feeling:

• How does this person prefer to work?

• How do they bring ideas to the table?

• What do they expect from teammates?

Of course, gauging culture fit assumes that your desired culture is clear to you! This often takes the form of explicit company values. In our case, we have general rubric for the kinds of people we want to work with: “Big brain, small ego.”

Post-interview communication

Usually I let the candidate know whether they’ve passed the screening and technical round at the end of the each. Sometimes I want to discuss the candidate internally. In these cases, I always aim to communicate results within one business day.

If candidates ask for feedback alongside their results, I’m happy to provide it. Feedback, especially for the technical interview, can be really useful in a developer’s progression. It’s an easy and worthwhile five minutes to write constructive feedback.

tl;dr

👍 In the screening interview, ask about job dislikes as well as likes. Both are revealing.

👍 Cover salary expectations up front, at end screening interview (if the candidate will advance).

👍 Aim for no later than one business day turnaround to communicate status / next steps.

👎 The technical interview is not a bar exam. Make them comfortable. You’re evaluating how they problem solve, not what they’ve memorized.

👎 Don’t skimp on feedback if asked for, even if the candidate is not a fit.