8 exercises — practice structuring strong English answers to senior backend interview questions: API design, database schema, scalability, distributed transactions, data consistency, observability, security, and code review.
How to structure Senior Backend Engineer interview answers
API design questions: start with consumer-driven design → versioning strategy → backwards compatibility rules → documentation and contract testing
Database questions: establish read/write patterns first → then justify normalisation vs denormalisation → indexing trade-offs → schema evolution practices
Distributed systems questions: explain why 2PC fails → introduce Saga pattern (choreography vs orchestration) → name eventual consistency as a deliberate trade-off
Code review and security questions: structure as a checklist (correctness, design, security, readability, mentorship) and distinguish blocking from non-blocking issues
0 / 8 completed
1 / 8
The interviewer asks: "How do you design an API that will be consumed by multiple clients?" Which answer best demonstrates REST design depth?
Option B is the strongest: it introduces the important concept of consumer-driven design, covers versioning strategies with their trade-offs, states the backwards compatibility rule clearly (add, never remove), mentions deprecation workflow, addresses the mobile/divergent-client problem with field filtering and GraphQL, and adds consumer contract testing — a senior-level tool for catching breaking changes. Key vocabulary for API design answers: REST (Representational State Transfer) — architectural style: stateless, resource-oriented, uses HTTP semantics (GET/POST/PUT/PATCH/DELETE). Backwards compatibility — existing clients continue to work unchanged when the API evolves. URI versioning — /v1/users/ visible in the URL. Header versioning — Accept: application/vnd.myapi.v1+json. Deprecation strategy — announce, set a sunset date, support both versions, remove. OpenAPI / Swagger — machine-readable API specification. Consumer contract testing (Pact) — each consumer defines what it expects; the provider runs those contracts in CI to detect breaking changes before deployment. Option D mentions design-first correctly but misses backwards compatibility rules and consumer-driven concerns.
2 / 8
The interviewer asks: "How do you approach database schema design for a high-traffic application?" Which answer best demonstrates data modelling depth?
Option B is the strongest: it starts with the key senior principle — understand read/write patterns before making design decisions — then shows that normalisation vs denormalisation is a deliberate trade-off, not a dogma. It explains the indexing trade-off precisely (indexes speed reads, cost writes), mentions composite index alignment, partitioning for scale, and schema evolution practices. Key vocabulary for database design answers: Normalisation — organising data to reduce redundancy (1NF → 2NF → 3NF). Denormalisation — intentionally duplicating data to eliminate joins and speed up reads. Not a mistake — a deliberate optimisation for read-heavy workloads. Write amplification — when one logical write causes multiple physical writes (exacerbated by redundant data storage). Composite index — an index on multiple columns; most useful when the query predicates match the leading columns of the index. Partitioning — splitting a large table into smaller physical segments by range (date), hash (user_id), or list. Keeps index sizes manageable. Backwards-compatible migration — add columns nullable first, backfill data, then add NOT NULL; never drop or rename columns in the same deploy as the code that removes references to them. Table lock — long-running ALTER TABLE statements can lock a table; use tools like pt-online-schema-change or pg_repack in production.
3 / 8
The interviewer asks: "Explain how you would design a system to handle 1 million concurrent users." Which answer best demonstrates scalability thinking?
Option B is the strongest: it gives a layered, ordered strategy (CDN → stateless services → horizontal scaling → message queues → caching → database → fault tolerance), explains the reasoning behind each layer (why stateless matters for horizontal scaling, why async decoupling works), and ends with failure-mode thinking. Key vocabulary for scalability answers: Stateless service — a service that holds no session data locally; any instance can handle any request. Prerequisite for horizontal scaling. Horizontal scaling (scale out) — add more instances. Contrasted with vertical scaling (scale up — bigger machine). CDN (Content Delivery Network) — serves static assets from edge nodes close to users, eliminating origin requests. Often absorbs 60–80% of total traffic. Message queue (Kafka, RabbitMQ, SQS) — decouple producers from consumers; accept writes at peak rate, process at sustainable throughput. Enables async processing. Read replica — a copy of the database that handles read traffic, offloading the primary. Sharding — horizontal partitioning of the database across multiple nodes by a shard key. Circuit breaker — stops sending requests to a failing downstream service to prevent cascade failure. Graceful degradation — the system continues at reduced functionality when a dependency is slow or unavailable.
4 / 8
The interviewer asks: "How do you handle distributed transactions in a microservices architecture?" Which answer best demonstrates distributed systems depth?
Option B is the strongest: it explains why 2PC is avoided (coupling, coordinator SPOF) rather than just stating a preference, introduces the Saga pattern with both implementation variants (choreography vs orchestration), explains the compensation mechanism, names the key trade-off (eventual consistency), and adds the important architectural principle of minimising cross-service transactions by design. Key vocabulary for distributed transaction answers: ACID — Atomicity, Consistency, Isolation, Durability: the guarantee relational databases provide for single-node transactions. Lost across service boundaries. Two-phase commit (2PC) — a protocol for distributed atomicity: prepare phase (all participants vote), commit phase (all commit or all rollback). Problems: synchronous, blocking, coordinator is a SPOF, tight coupling. Saga pattern — a sequence of local transactions; each step publishes an event. On failure, compensation transactions undo completed steps (e.g., refund a payment). Choreography-based saga — services react to events; no central coordinator. Looser coupling, harder to visualise. Orchestration-based saga — a central orchestrator directs each step. Easier to reason about, single point of control. Eventual consistency — the system will become consistent, but not immediately. Option D correctly describes the outbox pattern — a valuable addition — but misses the Saga explanation that directly answers the question.
5 / 8
The interviewer asks: "How do you ensure data consistency in an eventually consistent system?" Which answer best demonstrates reliability engineering depth?
Option B is the strongest: it systematically covers all major techniques for consistency in eventually consistent systems — idempotency keys, at-least-once delivery semantics, deduplication strategies, event sourcing, and read-after-write consistency — and finishes with the overarching design principle: assume duplicates and out-of-order delivery, and engineer consumers to be correct anyway. Key vocabulary for eventual consistency answers: Idempotency key — a unique identifier (UUID) sent by the client with each request; the server stores processed keys and discards re-submissions. Prevents double-charging, double-booking, etc. At-least-once delivery — message queues (Kafka, SQS) guarantee a message is delivered, but may deliver it more than once. Consumer must handle duplicates. Exactly-once processing — harder to achieve; typically approximated via idempotent consumers + deduplication rather than true exactly-once. Deduplication — tracking event IDs already processed (in a seen_events table or Redis set) and discarding known duplicates. Event sourcing — storing the full history of events rather than a mutable current state. Enables replay, audit, and reconciliation. Read-after-write consistency — ensuring a user who just wrote data can immediately read their own write back. Achieved by routing to the write replica or using a short cache TTL for recent writes.
6 / 8
The interviewer asks: "What is your approach to logging and debugging in production?" Which answer best demonstrates observability maturity?
Option B is the strongest: it gives a complete, layered approach — structured logging, deliberate log levels, correlation IDs with an explanation of why they matter in distributed systems, distributed tracing, and the advanced practice of dynamic log-level adjustment to avoid deploy-to-debug cycles. The final principle (logs as immutable audit trails) shows senior-level maturity. Key vocabulary for logging and debugging answers: Structured logging — logs emitted as JSON objects with named fields rather than free-text strings. Enables filtering, aggregation, and machine processing. Log levels — DEBUG (verbose, off in production), INFO (normal events), WARN (unexpected but recoverable), ERROR (failure requiring attention), FATAL (process-crashing). Correlation ID / Trace ID — a UUID assigned at the entry point (API gateway or first service) that is propagated in HTTP headers (X-Request-ID, traceparent) and included in every log line. Allows tracing a single user request across dozens of services. Distributed tracing — records the path and timing of a request across all services as a tree of spans (OpenTelemetry, Jaeger, Tempo, Honeycomb). Answers "where is this request slow?" Dynamic log-level adjustment — changing log verbosity at runtime (via feature flag or API call) without redeploying. Avoids the deploy→observe→rollback loop in production debugging. Log aggregation — centralised collection (ELK/Loki/Splunk) so all service logs are searchable in one place.
7 / 8
The interviewer asks: "How do you handle sensitive data and security in a backend system?" Which answer best demonstrates security engineering depth?
Option B is the strongest: it structures security as a layered, cross-cutting concern, covers encryption (at rest and in transit with specifics — AES-256, TLS 1.2+, HSTS), PII classification and minimisation, column-level encryption, parameterised queries, authentication with secret vaults, the OWASP Top 10 as a reference framework, embedding security in code review, and threat modelling as a proactive practice. Key vocabulary for backend security answers: Encryption at rest — data stored on disk is encrypted (AES-256). Protects against physical disk theft or database dump leaks. Encryption in transit — TLS 1.2+ for all HTTP traffic; enforced with HSTS (HTTP Strict Transport Security). PII (Personally Identifiable Information) — name, email, address, IP, payment data. Subject to GDPR/UK GDPR data minimisation requirements. Data minimisation — collect only the data you actually need. Pseudonymisation — replacing PII with a token; the mapping is stored separately and secured. Parameterised query (prepared statement) — separates SQL code from user-supplied data, preventing SQL injection. OWASP Top 10 — the industry-standard checklist of the ten most critical web application security risks: Injection, Broken Auth, Sensitive Data Exposure, IDOR, Security Misconfiguration, XSS, Insecure Deserialization, etc. Threat modelling — a structured process (STRIDE) to identify potential threats to a system design before building it. Least privilege — services and users have only the permissions they need, nothing more.
8 / 8
The interviewer asks: "How do you approach code review as a senior engineer?" Which answer best demonstrates senior engineering leadership?
Option B is the strongest: it explicitly names five review dimensions (correctness, design, security, readability, mentorship), explains the principle behind each, introduces the important distinction between blocking issues and non-blocking suggestions (which reduces friction and helps authors prioritise), describes the questioning vs mandating approach (respecting author context), and adds the cultural dimension — leaving positive feedback to encourage early sharing. Key vocabulary for code review answers: Correctness — does the code do what it's supposed to, including edge cases and error paths? Design review — does this fit the architecture? Are new patterns justified? Will this be maintainable? Security review in PRs — looking for missing auth checks, unsanitised inputs, hardcoded credentials, unsafe deserialization. Readability — can a future maintainer understand this code without the author present? Blocking vs non-blocking comments — blocking: must be fixed before merge (bug, security issue). Non-blocking (nit): suggestion, style, optional improvement. Using this distinction clearly reduces back-and-forth and speeds up merges. Mentorship through review — explaining the why behind a comment, not just the what. Asking "have you considered X?" rather than "change this to X". Psychological safety — code review culture where engineers feel safe sharing imperfect work early leads to better outcomes; positive feedback reinforces this. Option C is solid but misses the mentorship and blocking/non-blocking distinction. Option D mentions knowledge sharing but lacks the structured review framework.