title: “Explain a Topic At Multiple Levels…” url: https://jacobian.org/2021/feb/8/interview-questions-explain-a-topic/ hash_url: c9fad8039837ef9a671e1fb52cbbeb35

Each day this week I’ll be sharing one of the questions I use when I interview for technical roles. I’ll unpack the question, when to ask it, and how to evaluate answers. You can see all articles in this series here.

Background

Who this is for: technical roles at any level where communication with non-technical staff is important (which, for me, is all of them).

What it measures: ability to communicate technical topics effectively to a variety of audiences. Secondary to this, knowledge of some foundational web development topic.

This is one of my favorite questions to ask for engineering roles; strong performance on this question correlates very highly with high job performance on my teams. This is because my teams are almost always cross-functional teams. And, being able to communicate effectively is part of being a good engineer (IQ isn’t enough to get you hired).

Engineers on my teams need to be able to communicate effectively with their colleagues, who will have a wide range of software experience. An engineer who can’t talk about their work with others on the team isn’t a good team member, and isn’t someone I want to hire. This question simulates something that happens on these cross-functional teams: the need to explain technical topics and tailor the explanation for the audience’s skill level.

A secondary benefit is that this question can look for some level of technical knowledge – someone who knows web development well should be able to make that knowledge apparent – but that’s less important here than the communication aspects.


The question

“Pick a foundational web development concept (e.g. HTML, CSS, JavaScript, etc.) and explain it at two levels: first as you would to a colleague who’s not a software developer, like a designer or product manager; next, as you would to a peer.”

What behaviors to look for

Positive signs

Red flags


Discussion

In practice, when I ask the question I often have a longer preamble and more explicit way of asking this; I’ll say something like:

The job involves working with folks with a wide range of technical experience. We often need to discuss technical topics at a variety of different levels of detail. So, to simulate that: I’m going to ask you to pick a foundational web development concept (e.g. HTML, CSS, JavaScript, etc), and explain it to me at two levels of detail. First, I’ll ask you to explain it to me as if I were a a colleague who’s not a software developer, like a designer or product manager. Then, we’ll re-wind, and I’ll ask you to go deeper and explain it to me as if I were a peer.

Evaluating candidates is relatively straightforward – you’re directly measuring their ability to communicate. However, there’s a high risk that unconscious bias can color your evaluation of a candidate’s answers. A few things to keep in mind to help control for unconscious bias:

Alternate versions of this question

This can be adapted for nearly any domain by just changing “web development” to some other field. I’ve used versions of this question to interview data scientists, GIS analysts, security engineers, SREs, and more.

It’s probably also useful for non-engineering roles – I can imagine versions of this question being useful for designers, copywriters, etc. But I’ve not tried that myself.

See also

This is something of variation of a classic technical interview question: “in as much detail as possible, tell me what happens when you type google.com into your browser and hit enter.” That question also measures technical knowledge and communication ability (because they’re communicating it to you). But to fully answer that question would require an answer that is long to the point of absurdity.

My version makes the scope more manageable, and adds the additional challenge of making the candidate consider different audience skill levels.

Questions?

Next week, I’ll publish a series wrap-up, summarizing the series as a whole and addressing a few big-picture topics. If you have questions tweet at me (DMs are fine too). I’ll address common questions in the wrap-up.