Live Explain-to-Audience Exercise
What it tests
Real-time audience adaptation — the single most important DevRel skill — by putting the candidate in an improvised teaching scenario with a defined fictional audience.
Format
- 1Interviewer presents a scenario on the spot: 'Explain [technical concept] to [specific audience]' — e.g., 'Explain distributed tracing to a backend engineer who's never used observability tools'
- 2Candidate explains without preparation time — exactly as they would at a conference or in a customer call
- 3Interviewer plays the audience character, asking 'naive' questions or escalating complexity to test adaptation range
- 4Brief debrief: interviewer reveals the character's actual background and asks the candidate how they'd adjust
What to look for
- Does the candidate clarify the audience's background before diving in — great advocates ask before they talk
- Concrete analogies over jargon: can they explain it in a way that doesn't require knowing the answer already
- Recovery when they misjudge the audience — do they adjust gracefully or double down
- Energy and presence — developer advocacy is a performance craft, and flat delivery is a real signal
Adaptation guide
Run this exercise twice with two different audience types (e.g., a junior developer and a non-technical executive) to see whether the candidate can genuinely shift register, not just simplify vocabulary. Choose a technical concept from your actual product for maximum relevance.
Full description
Format:
- Interviewer presents a scenario on the spot: 'Explain [technical concept] to [specific audience]' — e.g., 'Explain distributed tracing to a backend engineer who's never used observability tools'
- Candidate explains without preparation time — exactly as they would at a conference or in a customer call
- Interviewer plays the audience character, asking 'naive' questions or escalating complexity to test adaptation range
- Brief debrief: interviewer reveals the character's actual background and asks the candidate how they'd adjust
Time: 15–20 minutes
What to look for:
- Does the candidate clarify the audience's background before diving in — great advocates ask before they talk
- Concrete analogies over jargon: can they explain it in a way that doesn't require knowing the answer already
- Recovery when they misjudge the audience — do they adjust gracefully or double down
- Energy and presence — developer advocacy is a performance craft, and flat delivery is a real signal
Adaptation: Run this exercise twice with two different audience types (e.g., a junior developer and a non-technical executive) to see whether the candidate can genuinely shift register, not just simplify vocabulary. Choose a technical concept from your actual product for maximum relevance.