How Backend Interviews Work
Backend interviews test whether you can build services that are correct, secure, fast enough and operable. Unlike pure algorithm rounds, they mix coding with databases, APIs, concurrency, failure handling and system thinking. This chapter maps the rounds, lists what each one looks for, and gives a plan for the rest of the track.
1. The rounds you will meet
| Round | What it checks | Typical prompts |
|---|---|---|
| Coding | data structures, clean code, edge cases | the DSA track; plus practical tasks such as parsing logs or building an in-memory store |
| API design | resources, methods, status codes, versioning, pagination, errors, idempotency | "Design the API for a booking service." |
| Databases | SQL, schema design, indexes, transactions, isolation, query plans | "Write a query for the top three customers per city." "Why is this query slow?" |
| Concurrency | threads, locks, race conditions, async I/O, worker pools | "Fix this race condition.", "Implement a thread-safe counter or rate limiter." |
| Distributed systems basics | consistency, replication, partitioning, retries, queues | "What happens if the message is delivered twice?" |
| System design | whole-system architecture and trade-offs | the System Design track |
| Security | authentication, authorisation, injection, secrets | "How do you store passwords?" |
| Operations | deployment, monitoring, debugging production incidents | "The API is slow in production. What do you check?" |
| Behavioural | ownership, incident stories, collaboration | the HR track |
Which languages? Interviewers usually accept whichever you know best (Java, Go, Node.js/TypeScript, Python, C#). The concepts in this track are language-neutral; examples use SQL and Python because they are easy to run and check, with notes where Java, Go or Node differ.
2. What interviewers look for
- Correctness first: handles edge cases, invalid input, partial failure.
- Data integrity: transactions, constraints, idempotency.
- Trade-off reasoning: SQL or NoSQL, cache or not, sync or async, and why.
- Operational thinking: logs, metrics, timeouts, retries, deploys, rollbacks.
- Security instincts: never trust input, least privilege, safe defaults.
- Scale awareness without over-engineering: estimate load, find the bottleneck, add complexity only when justified.
- Clear communication: state assumptions, draw simple diagrams, explain failure modes.
3. The map of this track
| Chapter | Use it for |
|---|---|
| HTTP and REST API design | methods, status codes, idempotency, pagination, versioning, errors |
| SQL fundamentals | joins, aggregation, window functions, query patterns |
| Indexes, transactions and isolation | why queries are slow; ACID; anomalies and isolation levels |
| Schema design and NoSQL | normalisation, modelling, choosing a datastore |
| Authentication and authorisation | passwords, sessions, tokens, OAuth, RBAC |
| Caching | strategies, invalidation, stampedes |
| Concurrency | races, locks, async I/O, thread-safe design |
| Messaging and event-driven design | queues, delivery guarantees, outbox, sagas |
| Resilience patterns | timeouts, retries, circuit breakers, rate limiting |
| Microservices and distributed basics | boundaries, consistency, CAP, service communication |
| Testing, deployment and CI/CD | test strategy, releases, migrations |
| Observability and performance | logs, metrics, traces, finding bottlenecks |
| Backend coding patterns | the practical coding questions that recur |
4. A request's journey
A useful mental model for many questions: follow a request through the stack and ask what can fail at each step.
<!--fig:request-->- Client sends a request (DNS, TLS).
- Load balancer / gateway routes, terminates TLS, rate-limits, authenticates.
- Service validates input, authorises, runs business logic.
- Cache may answer; on a miss the service reads the database.
- Database executes the query, with locks, indexes and transactions.
- Side effects: publish an event to a queue, call another service.
- Response with the right status code and body; metrics and logs written along the way.
For each step, practise answering: what is the latency budget, what happens on timeout, is it safe to retry, and how would I notice it failing?
5. A preparation plan
| Weeks | Focus |
|---|---|
| 1 | HTTP and REST, SQL fundamentals (do 30 SQL problems) |
| 2 | Indexes, transactions, schema design; read query plans |
| 3 | Authentication, caching, concurrency |
| 4 | Messaging, resilience, microservices basics |
| 5 | Testing, deployment, observability; two system designs |
| 6 | Mock interviews; build one small service end to end (API, database, tests, Dockerfile) |
Building a small real service teaches more than reading: add pagination, auth, a migration, a background job and a metrics endpoint.
6. How to answer design-flavoured questions
- Clarify requirements, scale and consistency needs.
- Sketch the main components and the data model.
- Walk the critical path (the happy path), then the failure paths.
- Name the trade-offs and the alternatives you rejected.
- Mention operations: monitoring, deployment, migration, rollback.
7. Common mistakes
- Jumping to microservices, Kafka or Kubernetes for a small problem.
- Ignoring failure: no timeouts, no retries or retries without idempotency.
- Treating the database as a black box: no indexes, N+1 queries, unbounded results.
- Trusting input and building SQL by string concatenation.
- Skipping the data model.
- Not saying what you would measure.
- Memorised buzzwords without the ability to explain them.
8. Practice questions
- Trace what happens when a user places an order, from the browser to the database and back.
- How do you decide between SQL and NoSQL?
- A request occasionally times out. How do you investigate?
- How would you make an endpoint safe to retry?
- What would you check first if the database CPU is at 100%?
- How do you roll out a schema change with no downtime?