5 exercises — practise explaining technical concepts clearly: using analogies for juniors, structured project walkthroughs, whiteboard narration, technical vocabulary in trade-off answers, and communicating with non-technical stakeholders.
Technical explanation essentials
To a junior: lead with an analogy ("think of it like…"), then explain the behaviour, then give an example
Project walkthrough: Context → Challenge → Decision → Outcome — state the structure upfront
Whiteboard: clarify requirements before drawing — ask 2–3 targeted questions first
Trade-offs: name the property → connect to use case → give a concrete example
To stakeholders: lead with the analogy, connect to business impact, offer a next step
0 / 5 completed
1 / 5
A junior developer on your team asks you to explain what a cache is. Which answer is most effective for a junior audience?
Option B applies the analogy-first technique — the gold standard for explaining a technical concept to a junior developer: ① Start with something familiar — "notepad on your desk" vs "filing cabinet" maps directly onto the cache vs primary storage relationship. The junior doesn't need to understand memory or latency to grasp this. ② Then state what it actually does — "stores frequently-used data in a fast place so it doesn't have to re-fetch it every time" describes the behaviour in plain English. ③ No jargon — no TTL, no eviction policy, no Redis — those come later when the concept is understood.
Framework for explaining concepts to juniors (AEEL):
Analogy — "It's like…"
Explain what it does — "What this means in practice is…"
Example — "For instance, if you…"
Link to their work — "In our codebase this is why we use…"
Phrases to use:"Think of it like…" · "Imagine you have…" · "In practice, what this means is…" · "The reason we do this is…" · "Does that make sense? Any questions?"
Option A is the textbook definition — correct, but dense with jargon and passive voice. Option C uses hedging ("kind of", "basically") that signals the explainer isn't confident. Option D avoids explaining entirely.
2 / 5
An interviewer asks: "Walk me through the most complex project you've worked on." Which answer structure is most impressive?
Option B uses the structured project walkthrough — the only format that consistently scores well in senior technical interviews: ① Picks one clear project — "the most complex was X at Y" — decision, no hedging ② States the structure upfront — "I'll walk you through the context, the challenges, the decisions, and the outcome" — this is a power move: it tells the interviewer you think in structured ways and it signals you won't ramble ③ Each section has a concrete point — Context = scope/stakes · Challenge = what was technically hard · Decision = why you chose one approach over another (this is what separates senior from mid-level) · Outcome = measurable result
The 4-part project answer template: Context: "This was at [Company], working on [domain]. The system was [scale/state]." Challenge: "The hardest part technically was [specific problem], because [why it was hard]." Decision: "We considered [option A] and [option B]. I recommended [B] because [reasoning]." Outcome: "As a result, [metric improved by X%] / [we shipped on date] / [the system now handles Y]."
Option A is vague — "I learned a lot" and "the team was great" are filler. Option C hedges instead of answering. Option D creates unnecessary friction by not just picking a project.
3 / 5
During a whiteboard round, the interviewer gives you a problem: "Design a rate limiter." You haven't started drawing yet. Which narration best demonstrates senior engineering thinking?
Option B demonstrates the clarify-before-solve pattern that separates senior engineers from junior engineers in system design interviews: ① State your intent before doing it — "Let me start by clarifying the requirements" signals meta-awareness. You're not just solving, you're designing a process. ② Ask targeted questions, not open ones — "external clients or internal services?", "how many RPS?", "per user, per IP, or per API key?" — these are the exact parameters that change the architecture. Compare to asking "what are the requirements?" which is too vague. ③ Signal what you'll do after — "Once I have those, I'll define the core components" — this shows you have a mental model of the full design process.
Whiteboard narration phrase bank: Opening: "Before I start drawing, I'd like to clarify a few requirements…" Scoping: "I'd suggest we focus on the happy path first, then handle edge cases." Thinking aloud: "I'm considering [option A] here because…" · "The trade-off is…" · "This would work but at the cost of…" Checking in: "Does that constraint make sense for our use case?" · "Should I go deeper on this component?" Summarising: "To recap the design: [X] handles [Y], [Z] handles [W], and we use [Q] for [R]."
Option A starts solving without context — classic junior mistake. Option C demonstrates pattern-matching ("I know this one") without scoping — senior engineers know the right answer depends on the requirements. Option D stalls instead of leading.
4 / 5
An interviewer asks you to describe the trade-offs between a SQL and NoSQL database. Which answer demonstrates the best command of technical vocabulary in context?
Option B is the model answer that demonstrates technical vocabulary in professional context: ① Precise terms with immediate definition — "enforce a rigid schema", "ACID transactions", "complex joins", "horizontal scalability", "eventual consistency", "write throughput" — each term is specific and used correctly ② Connects terms to trade-offs — this is the critical skill: not just knowing the vocabulary but knowing when to use one vs. the other ③ Gives concrete examples — "payment system" for SQL, "user activity logs / product catalogues / real-time feeds" for NoSQL — these make the answer memorable and show domain experience ④ Acknowledges nuance without hedging — "the right choice when…" and "better suited for…" shows calibrated judgment, not uncertainty
Technical vocabulary comparison answers — formula: "[Term A] → [key property] → [use case where it wins]" "[Term B] → [key property] → [use case where it wins]" "I'd choose [A/B] when [condition] because [reason]."
Key terms to know for SQL vs NoSQL: schema, ACID, atomicity, consistency, isolation, durability, base consistency, eventual consistency, horizontal scaling, vertical scaling, sharding, replication, query language, JOIN, index, denormalisation, CAP theorem
Option A is oversimplified and factually imprecise — "NoSQL is faster" is not categorically true. Option C is pure hedge. Option D contains a misconception — SQL is not legacy.
5 / 5
A non-technical stakeholder (your product manager) asks why the feature is taking longer than expected because of "technical debt." Which explanation is most effective?
Option B is the professional approach to explaining technical concepts to non-technical stakeholders — it uses the financial analogy that Ward Cunningham (who coined "technical debt") himself intended: ① Uses the canonical analogy — "like a loan" / "borrowed time" / "paying back the interest" — this frames technical debt in terms a PM already understands. You're not dumbing it down; you're finding the right translation ② Acknowledges the original decision was rational — "we built this feature quickly last year… the shortcut worked then" — this is important: it shows you understand context, not just blame the past ③ Explains the current impact clearly — "paying back that interest" is exactly what slow delivery feels like to a PM ④ Offers a path forward — "I can walk you through what we'd need to do to fix it properly" — this turns a frustrating situation into a collaborative problem
Explaining technical concepts to stakeholders — key principles: • Lead with the analogy, not the term • Acknowledge the trade-off was a choice, not a mistake • Connect to business impact (time, risk, cost) • Offer a concrete next step or solution direction
More analogies for common concepts: Refactoring — "cleaning the kitchen before cooking a complex meal" Tests — "a safety net so we can change things without breaking them accidentally" Microservices vs monolith — "one large multi-tool vs a set of specialised tools"
Option A is condescending ("bad code") and imprecise. Option C is apologetic ("it's complicated") and vague. Option D uses technical vocabulary that a PM cannot act on.