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 / 10 completed
1 / 10
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 / 10
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 / 10
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 / 10
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 / 10
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.
6 / 10
Sarah from the QA team messages you: 'The API is returning 503 errors intermittently. Can you investigate?' What's the most appropriate response to provide her with initial troubleshooting guidance?
This situation requires a systematic approach. Suggesting a traceroute is valid *after* initial checks, but starting with network diagnostics is key. Checking deployments addresses a common cause of intermittent issues. Directing the question to another team without investigation is unhelpful and avoids taking ownership.
7 / 10
You're drafting a pull request description for a refactoring effort that improved code readability. Which of the following best summarizes the changes while adhering to common practices?
A good PR description needs specifics. Saying 'fixed some bugs' is vague. Describing the refactoring's *purpose* (improve maintainability) and *how* it was achieved (clearer variable names) demonstrates a technical understanding and provides context for reviewers. Avoidance of specific language like 'should be fine' is critical.
8 / 10
During a standup meeting, your team lead asks: 'What did you work on yesterday?' You respond with: 'I implemented the new user authentication flow.' Which of the following is the MOST effective way to expand on this response for clarity?
The key here is to provide *details* about your work. Simply stating you implemented a flow isn't sufficient. Mentioning specific technologies (Auth0, JWTs) demonstrates technical proficiency and allows others to understand the scope of your contribution. A vague response doesn't convey much useful information.
9 / 10
You're reviewing a colleague's code that uses a complex regular expression. They comment: 'This regex handles all possible username formats.' What is the MOST constructive response you can offer?
While the regex *might* work, it's crucial to question its robustness and potential issues. Asking about edge cases and performance highlights an understanding of potential pitfalls with overly broad regular expressions – they can be slow and difficult to maintain. A dismissive response is not helpful.
10 / 10
Your manager asks: 'The microservice is experiencing increased latency.' What's the MOST appropriate initial response focusing on gathering information?
A systematic approach is essential when troubleshooting performance issues. Immediately deploying a hotfix without investigation can exacerbate the problem. Requesting logs and monitoring key metrics allows you to identify the root cause before taking action. Blaming teams or dismissing the issue are unproductive.
What does "Technical Explanation Interview Questions — English for IT Professionals" cover?
Practice explaining technical concepts in English: caching, project walkthroughs, system design narration, SQL vs NoSQL trade-offs, and talking to non-technical stakeholders. 5 exercises.
How many questions are in this interview set?
This set has 10 exercises, each with a full explanation.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
Do these exercises include model answers?
Yes. Each interview question gives you several possible responses and asks you to pick the one that communicates most clearly and completely — the explanation then breaks down exactly why that answer works, including the specific vocabulary a strong candidate would use.
What if I choose an answer that isn't the strongest one?
You'll see which option was correct and read a full explanation of why it's stronger than the alternatives, plus the key vocabulary and phrasing worth reusing in a real interview.
Can I retry the questions?
Yes — use the "Try again" button on the results screen to reset and go through the set again.
Is this the same as a real technical or behavioural interview?
No — it's focused practice for the language side of interviewing: recognising which phrasing sounds precise and confident versus vague, and knowing the vocabulary interviewers expect for this role. It won't replace mock interviews, but it builds the vocabulary you'll need in one.
Where can I find interview prep for other roles?
Browse the full Interview exercises hub for 170+ modules covering behavioural, technical, and system design rounds across dozens of IT roles, or check the "Next up" link below to continue.
Do I need an account, and is my progress saved?
No account is needed. Progress is tracked only for your current visit — reloading or leaving the page resets the counter.
Who writes these interview questions?
Every question is written by the CoderSlingo team based on real technical interview patterns for this role, then reviewed for accuracy and clarity.