Unpacking Interview Questions:
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
- Do they communicate effectively at both levels of technical detail?
- Do they demonstrate knowledge of the topic at a level that’s appropriate to the role?
Positive signs
- 👍 Strong explanations at both levels
- 👍 Takes a moment at the beginning to consider and choose a good topic
- 👍 Tailors explanation for each skill level
- 👍 Effective use of metaphor or other rhetorical devices
- 👍 Focused, organized, succinct explanation
- 👍 Asks questions to guide their explanation
Red flags
- 🚩 Unable to give a strong description at either (or both) levels
- 🚩 At the non-technical level: excessive use of jargon or other assumed technical knowledge
- 🚩 Patronizing tone, especially when explaining “down”
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:
- Since this question is all about communication, be very careful about making judgement based on accent. We’re socially conditioned to believe that certain accents – Black accents, Southern accents, strong accents from non-native-English speakers – are indicators of low intelligence. This is bullshit; don’t fall for the trap.
- Be wary of judgement based on communication behavior that may be triggered by nerves. Many speakers have verbal tics that are especially bad when they’re nervous – e.g. stalling words like “um” or “like”, mumbling, long pauses, etc. Remember that job interviews make most people really nervous, so these behaviors will be substantially more pronounced in the interview than they’d be in real life.
- The primary behavior you’re evaluating here is communication skill. So pay close attention to the way the candidate structures their explanation, the way they talk and explain, how they engage (or don’t) with you, etc. Pay less attention to the technical details (other questions will get deeper there). Remember that we’re prone to think that members of underrepresented groups are less technically talented than the majority. If you find yourself thinking, “this person doesn’t know what they’re talking about”, come back to what specifically they said or did to give you that impression. Is the judgement coming from their specific behavior, or from 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.