Ask Engineering Interview Candidates to Explain Something

Technical explanations allow candidates to demonstrate their technical skills and social skills at the same time

Dan Fabulich

Published in

Code Red

5 min readJun 13, 2018

Dan Fabulich is a Principal Engineer at Redfin. (We’re hiring!)

Discuss on Hacker News
Discuss on Reddit

Interviewing engineers is a hard problem. Every interviewing technique has vocal detractors who say, “I would never work at a company that used that interviewing technique.” Whiteboarding, take-home assignments, pair programming, reviewing open-source contributions, contract-to-hire … you name it, somebody hates it.

But almost everybody I talk to seems to like the idea of asking candidates to explain something, at least as one part of the interview process.

And it seems to me that very few people know that this is a widely shared consensus view, perhaps because popular online discussions about interviewing and hiring are dominated by debates about controversial techniques.

When I’m interviewing candidates as part of an interview loop, I always ask the candidate to explain something technical. Sometimes I let the candidate choose the topic, sometimes I choose the topic for the candidate, and sometimes I ask the candidate to tell me a story. I’ll discuss all three approaches in this article.

Letting the Candidate Choose the Topic

When I interview candidates, one of my questions asks them to explain a topic of their choice. When I do it this way, I ask that the candidate choose a “complex” topic, something that requires some effort to explain, and I give a few examples, typically saying something like this:

Some people, when I ask this question, choose to explain a piece of software that they’ve worked on, often with a boxes-and-lines diagram on the whiteboard. “These functions call these functions,” “these objects talk to those objects,” “these servers communicate with these servers,” and so forth. But it doesn’t have to be that. You could instead choose to explain a computer-science algorithm, a mathematical proof, a scientific concept, or even the rules to a complicated game. It’s up to you.

I also request that candidates choose a topic that they know pretty well, such that I could ask a few follow-up questions and they would be able to answer them.

I learn a lot about a candidate when I ask this question. Communicating about technical subjects is an essential skill for working on a team, so the explanation itself can be a very good “work sample.” Candidates can convey a sense of how interested (how excited) they can be about their chosen topic. I also feel that the ability to communicate clearly about complex topics is indicative of general cognitive ability, though I admit that there’s no way to prove the connection.

Overall, asking the candidate to explain something is an efficient way of evaluating social skills and technical skills at the same time. That’s important because the tech industry has incorrectly undervalued social skills (calling them “soft skills”) relative to technical skills (“hard skills”). Prioritizing explanations helps to counterbalance that bias.

Choosing the Topic for the Candidate

Rather than ask a totally open-ended question, you can narrow the scope a bit while still giving the candidate a lot of freedom to choose a topic. You can ask the candidate to explain something (candidate’s choice) about JavaScript, something about machine learning, or something about concurrency.

I have in the past sometimes handed the topic to the candidate directly.

Explain how JavaScript closures work.
Explain git rebase.
In Java generics, explain the difference between <? extends T> and <? super T>.

The problem with this approach is that these questions primarily test the candidate’s knowledge, rather than their ability to learn, understand, and explain. It can work better if you make it clear to the candidate up front that they absolutely have to know git rebase before the interview.

When I want to hand the candidate a topic, I typically instead prefer to introduce a problem to the candidate, allow them to solve it, and then ask them to explain their answer.

I’ve had surprisingly good luck using logic brainteasers for this. However, I always clarify that I don’t actually care whether the candidate can solve the brainteaser, like this:

I’m going give you a logic deduction puzzle. It has no “trick answers.” If you cross off all of the wrong answers, you’ll get the right answer. However, I don’t care at all if you solve it. You can ask me for hints, or even just give up; that’s totally fine, no points off. At the end, I’ll erase the puzzle from the board, and ask you to explain the question of the puzzle to me, as if you were interviewing me, and then I’ll ask you to explain the answer again as clearly as you can.

When I present a brainteaser in this way, some candidates actually take me up on the offer and ask me to just explain the answer. I do; the solution is a proof by contradiction. Then I ask the candidate to explain the answer.

This approach, combined with the open-ended approach, allows me to see how well the candidate can learn something tricky, understand it, and communicate it, all of which are important job skills. I’ve used this technique not just with engineers, but with engineering managers and product managers. Everybody on the team needs these skills.

Asking the Candidate for a Story About Their Past Behavior: Behavioral Interviewing

You can also use this technique to assess other job skills, asking the candidate to tell you how they behaved in a particular kind of situation. You can ask for a story about how they handled a conflict with their team, how they finished a project that was about to go past its deadline, or when they took initiative without waiting to be asked.

Normally, the purpose of a behavioral interview question is to evaluate the behavior that the candidate describes. (You can reject candidates who say that they handle team conflict by shouting at their peers until everybody else gives up.) Behavioral interviewing can also be a depressingly useful technique for discovering when the candidate has lied on their resume. 😞

But while answering these questions, you can also get a sense for how clearly they explain the situation as well. How well did you understand the situation? How many times did you need to ask for clarification? How well did the candidate understand the problem that they themselves had to solve?

This Can’t Be the Whole Interview

Nobody has the entire solution for engineering interviews. I can’t tell you everything you need to know about interviewing because nobody can. Nobody knows if they’re a great interviewer — the only way to measure if you’re a good interviewer is with performance reviews — but nobody’s really sure whether performance reviews are accurate, either.

But if we can agree on something, we can agree that “explanation” style questions should be a part of your interview process. Start there, and build on that.