Backend Developer Interview Guide

Backend interviews orbit one obsession: what happens when it scales or fails? Writing code that works for one user is table stakes. The interview is about the hundred-thousandth user, the dead database, the duplicate payment. If you prep with that lens — reliability and scale — you'll find the questions far less scattered than they first appear.

The core idea: A backend engineer's craft is managing state and concurrency safely under load. Every topic — databases, caching, queues, APIs — is a different battlefield for that same fight.

The question taxonomy

• API design. REST resource modelling, pagination, versioning, idempotency keys for unsafe operations, status codes that actually mean something.
• Databases. Indexing, transactions and isolation levels, N+1 queries, when NoSQL genuinely fits. The SQL guide covers query depth.
• Caching. Cache-aside vs write-through, TTLs, invalidation, and the honest admission that caching is where correctness goes to die.
• Asynchrony. Queues for slow work, retries with backoff, dead-letter queues, at-least-once delivery and the deduplication it demands.
• System design. The capstone: "design a URL shortener / chat service / rate limiter."

Worked example: the idempotent payment endpoint

"How do you stop a retried request from charging a customer twice?" This question appears constantly because it tests everything at once:

1. Client sends an idempotency key (a UUID) with the charge request.
2. Server stores the key with the result. On a retry with the same key, return the stored result instead of charging again.
3. Enforce uniqueness in the database, not in application logic — races happen between the check and the write.
4. Handle the in-flight case: a retry arriving while the first request is still processing should wait or return a conflict, not double-charge.

Then zoom out: this same pattern — unique constraint as the source of truth, application code as convenience — applies to duplicate orders, double bookings, and replayed webhook deliveries. Naming the general pattern after solving the specific case is what senior answers sound like.

How answers get scored

Rubrics reward failure-first thinking: before celebrating the happy path, say what breaks and what you'd do about it. In system design, clarifying requirements and estimating scale before drawing boxes earns more than an elaborate diagram. And throughout, trade-off language — "strong consistency here, eventual there, because reads dominate" — signals real experience.

Common mistakes

• Adding caching as the first answer to every performance question, without asking whether the query is the actual problem.
• Designing APIs where retries are unsafe — no idempotency on POST endpoints that move money or create resources.
• Trusting application-level checks for uniqueness instead of database constraints.
• Drawing a microservice diagram for a system with a few thousand users. Complexity must be justified by scale.

The database depth interviewers expect

Beyond "write a query," backend rounds probe operational database knowledge. Know what an index costs — faster reads, slower writes, storage — because "add an index" as an unconditional answer is a red flag. Understand transaction isolation at the level of the anomalies each level prevents: dirty reads, non-repeatable reads, phantoms, and why the default your database chose is a deliberate trade-off. Be able to explain the N+1 problem and its fixes (eager loading, batching) without being prompted when you sketch a data access layer. And when designing, say where your strong-consistency requirements actually live: inventory and payments need transactions; a view counter does not. Splitting requirements by consistency need — rather than applying one setting everywhere — is one of the clearest senior signals in the entire backend interview, and it costs you one sentence.

FAQ

How much algorithms vs system design? It depends on company size — larger companies weight algorithms heavily regardless of role; smaller ones lean practical. Prepare both; the software engineer guide covers the algorithm side.

Which language should I interview in? The one you know best — Python, Java, and Go are all well understood by interviewers. Depth beats fashion.

Complement this with the full-stack tips if your role spans the stack, and drill with Aissence's coding copilot.