5 exercises — choose the best-structured answer to common backend interview questions. Focus on technical accuracy, named examples, and explanation depth.
What separates good from great technical answers
Named specifics: say "B-tree index" not just "index", "mutex" not just "lock"
Trade-offs: every technology has them — mention at least one draw-back
Decision criteria: explain when you'd use something, not just what it is
Counter-intuitive insight: show you've seen the edge cases in practice
0 / 5 completed
1 / 5
An interviewer asks: "Can you explain database indexing?" Which answer is the most complete and professionally expressed?
Option B is the strongest response: uses an analogy (table of contents), names the specific data structure (B-tree), includes time complexity (O(log n) vs O(n)), explains the concrete trade-off (write overhead), and gives a practical rule (high-cardinality columns in WHERE and JOINs). This demonstrates both depth and practical experience. Option A is good but lacks technical specificity. Option C is too brief. Option D is correct but reads like a definition rather than an explanation — no depth or practical insight.
2 / 5
The interviewer asks: "What is a race condition?" Choose the most precise and well-structured explanation.
Option C is the strongest: formal definition (correctness depends on relative timing), a concrete counter example showing the exact failure mechanism, and the standard solutions (mutexes, semaphores, atomic operations). This shows you understand the problem deeply, not just the name. Option A is colloquial and over-simplified. Option B is accurate but lacks the example and solutions. Option D focuses on symptoms (hard to reproduce) which is a useful point but doesn't define the concept. In technical interviews, give: definition → concrete example → prevention.
3 / 5
The interviewer asks: "Describe your approach to API versioning." Which answer best demonstrates experience and clear structure?
Option B is the strongest: states the goal (stable interface while API evolves), gives a preference with rationale (URI versioning because it's explicit), names a specific signal for deprecation (Sunset header), and provides the governing principle (version when breaking, not on every change). This is an experienced, opinionated answer. Option A is vague and non-committal. Option C mentions semantic versioning correctly but lacks depth on the practical workflow. Option D lists strategies but lacks a concrete preference or the nuance about when NOT to version.
4 / 5
The interviewer asks: "When would you choose SQL over NoSQL, and vice versa?" Choose the strongest answer.
Option C is the strongest: starts with the decision criteria (data model, consistency, scale), gives named examples (PostgreSQL, MongoDB, Redis) with their use cases, and ends with a nuanced counterpoint (choosing NoSQL purely for scale is a common mistake). This last point signals seniority — it shows you've seen the trade-offs in practice. Option A is accurate but superficial. Option B is factually thin. Option D lists examples but lacks a clear decision framework and the counter-intuitive insight. Strong interview answers always include: decision criteria → named examples → the edge case or common mistake.
5 / 5
The interviewer asks: "How do you approach reducing the risk of a production deployment?" Which answer demonstrates the most engineering depth?
Option B is the strongest answer with a clear structure: before → during → after. It names specific strategies with explanations (canary releases, feature flags), specifies what to monitor (error rate, p99 latency), and describes the decision trigger (if any metric degrades, roll back immediately). Option A is too brief. Option C explains blue-green well but that's one strategy without the broader risk framework. Option D lists all the right elements but as disconnected bullet points — no structure or prioritisation. Tip: "before / during / after" or "people / process / tooling" are reliable frameworks for structuring process-based interview answers.