What topics should I study for a backend developer interview?

Five areas cover most questions: API design and correctness under retries (idempotency, status codes, versioning), databases (indexes, transactions and isolation levels, query plans), caching (cache-aside, invalidation, stampedes), asynchronous work (queues, delivery guarantees, duplicate processing) and scaling (stateless services, load balancing, replicas). Add the language you will code in and enough Docker to explain how your service is built and run.

How long does it take to prepare for a backend developer interview?

If you already ship backend code, one focused week is realistic: a day per area, a day building a small service that exercises all five, and a day answering questions out loud. If databases are your weak spot, give them two days, because indexes and transactions generate more follow-up questions than any other topic.

Do backend developer interviews include system design?

Yes, from mid-level upwards almost always. For backend roles the design round tends to be concrete rather than planetary: an order service, a notification pipeline, a file upload flow. Interviewers look for where state lives, what happens when a request is retried or a worker dies, and which component becomes the bottleneck first.

What is idempotency in a REST API?

An operation is idempotent when performing it several times has the same effect as performing it once. GET, PUT and DELETE are idempotent by definition; POST is not, so APIs that create resources usually accept an idempotency key from the client and store the outcome under that key, returning the stored result when the same key arrives again.

What is the difference between optimistic and pessimistic locking?

Pessimistic locking takes a lock before reading data it intends to change, so other writers wait. Optimistic locking takes no lock: it reads a version number with the row and makes the update conditional on that version being unchanged, failing the write if someone else got there first. Optimistic locking suits low-contention data edited by humans; pessimistic locking suits short, high-contention updates such as stock counters.

How to Prepare for a Backend Developer Interview in 2026

The fastest way to prepare for a backend developer interview is to stop studying frameworks and start studying failure. Interviewers rarely ask what an annotation does. They describe a service that charges a customer twice, a query that is fast in staging and slow in production, or a worker that died halfway through a job, and then they listen to how you look for the cause.

Across companies, backend interview questions fall into five areas:

API correctness - what happens when a request is retried, duplicated or arrives twice at once
Databases - indexes, transactions, isolation levels and the plans behind slow queries
Caching - who fills the cache, when it goes stale, and what happens when it empties
Asynchronous work - queues, workers and the duplicates that at-least-once delivery creates
Scaling - stateless services, load balancers, replicas and what breaks when a server disappears

This article covers what each area asks and the shape of an answer that lands, then closes with a 7-day plan. Before reading any of it, find out which areas you actually need.

Start here: a 5-question self-check

Five questions from squizzu's question bank, one per area, in the same order as the sections below. Each comes from a real scenario rather than a definition. Pick an answer and you get the explanation plus an in-depth breakdown. Your score matters less than where you missed, because each miss names the section to read slowly.

System Design • API Design & Communication Protocols

Question 1 / 5

Your API handles an Idempotency-Key like this: look up the key; if it is absent, create a shipment by calling the carrier's API, then store the key with the response. Under load, two retries carrying the same key sometimes arrive together, both find no key, and both create a shipment. A duplicate must never happen. What fixes it?

The idempotency question trips up experienced engineers most often. Every option sounds like something a reasonable team would ship, and three of them leave a window where two requests both believe they are first. If that one got you, area 1 is where to start. The composite index maps to area 2, cache-aside to area 3, the visibility timeout to area 4 and the logged-out users to area 5.

What a backend developer interview looks like

Most loops have four or five stages:

Recruiter screen. Your recent work. The services you name here become the material for later rounds, so mention only what you can defend in detail.
Technical screen. Concepts from the five areas, usually with one live coding task in the language of the job: parse something, call something, handle the error path.
Coding round. Practical rather than puzzle-heavy at most product companies. Build a small endpoint, fix a race condition, write a query. Large tech companies still add a data structures round, which is a separate preparation track.
System design. From mid-level upwards. Expect a concrete service rather than "design Twitter": an order flow, a notification system, an upload pipeline.
Behavioural. An incident you handled, a design decision you would reverse.

Area 1: API design and idempotency questions

Every backend question about APIs eventually becomes a question about retries. Networks time out, clients retry, load balancers retry, and a request your server already processed can arrive again. Interviewers check whether you design for that from the start.

Know the HTTP semantics cold. GET, PUT and DELETE are idempotent by definition, so repeating them changes nothing beyond the first call. POST is not, which is why creating an order is the classic trap. The standard defence is an idempotency key: the client generates one value per logical operation, sends it with every retry, and the server returns the stored outcome when it sees the key again.

The subtle part is the server side. "Look up the key, and if it is missing, do the work" has a gap between the check and the write, and two concurrent retries can both fall into it. The order in which you record the key and perform the side effect matters, and so does where the uniqueness is enforced.

Question: How do you make a payment endpoint safe to retry?

Short answer: Require an idempotency key per payment attempt, claim it atomically before charging, and store the response under it so a retry returns the original result instead of charging again.

Explanation: The key turns "has this been done?" into a database fact rather than a guess. Claiming it with a unique constraint means only one request can win, even when two arrive in the same millisecond. Any later request with the same key either waits for the first to finish or receives its stored response. The key needs an expiry, and the stored response needs to include failures, or a retry after a declined card will try again.

What the interviewer is testing: Whether you see the race. Candidates who describe the happy path of an idempotency key pass the screen; candidates who explain what happens when two retries overlap pass the onsite.

Common follow-up: "The payment provider call succeeded but your service crashed before saving the result. What happens on retry?" (This is where reconciliation with the provider and an "in progress" state come in.)

Also be ready for status codes chosen on purpose (409 for a conflicting state, 422 for a well-formed but invalid body, 429 with Retry-After), cursor pagination versus offset pagination on a changing dataset, and how you version an API without breaking existing clients.

Area 2: Database interview questions: indexes and transactions

This area produces more follow-up questions than any other, because a weak answer here causes outages in real life. Expect three clusters.

Indexes. Know what a B-tree index makes cheap: an equality lookup, a range scan, and reading rows already in order. Know why a composite index serves some queries and not others, and why column order is the decision that matters. Be able to read an EXPLAIN output well enough to spot a sequential scan or a sort that should not be there.

Transactions and isolation. Know what READ COMMITTED, REPEATABLE READ and SERIALIZABLE each prevent, and which anomaly survives each one. Lost updates and write skew are the two that interviewers like, because they appear in code that looks correct.

Concurrency control. Optimistic locking with a version column against pessimistic SELECT ... FOR UPDATE. Neither is "better"; the choice follows from how often two writers collide and how long a lock would be held.

Question: A query was fast last month and is slow now. How do you investigate?

Short answer: Get the actual plan with EXPLAIN ANALYZE, compare estimated and real row counts, and check whether the data distribution changed under an index that no longer fits.

Explanation: A query that degrades without a code change usually means the data changed. A table grew past the point where the planner prefers an index, statistics went stale and the row estimates are off by orders of magnitude, or a new filter value matches millions of rows instead of hundreds. The plan tells you which. Adding an index is sometimes the fix, but so are refreshed statistics, a rewritten predicate that can use the existing index, or a narrower SELECT that lets the index cover the query.

What the interviewer is testing: A method rather than a guess. "Add an index" without looking at the plan is the answer they are trying to filter out.

Common follow-up: "What does an index cost you?" (Write amplification on every insert and update, storage, and memory pressure that can push hot data out of the buffer cache.)

Area 3: Caching questions

Caching questions look easy and are scored on the edges. Know the three common patterns and who owns each step:

Cache-aside. The application checks the cache, reads the database on a miss, and fills the cache itself. The default in most codebases.
Read-through and write-through. The cache layer loads from or writes to the database on the application's behalf.
Write-behind. Writes land in the cache first and reach the database later, which is fast and risks losing data.

Then the failure modes, which are where the questions really are. Stale data: what invalidates an entry when the source changes, and whether a TTL alone is acceptable for this data. Stampedes: a popular key expires and a thousand requests miss at once and hit the database together; request coalescing, early refresh and jittered TTLs are the standard answers. Cold starts: a cache flush that turns a healthy database into an overloaded one.

Question: When should you not cache something?

Short answer: When the data must be exactly current, when it is rarely read twice, or when the cost of serving it stale is higher than the cost of the read you are saving.

What the interviewer is testing: Judgement. A cache is a second copy of the truth, and every second copy needs an answer for when it disagrees with the first. Candidates who cache everything by reflex have not yet debugged a stale-cache incident.

Common follow-up: "You update a product price in the database. In what order do you update the database and invalidate the cache, and why?"

Area 4: Queues and asynchronous processing

Anything slower than a few hundred milliseconds should not run inside an HTTP request, and interviewers check that you know where it goes instead. The answer is a queue and a pool of workers, but the questions are about what the queue promises.

Most queues and streams deliver at least once. A message can arrive twice: the worker finished but crashed before acknowledging, the acknowledgement was lost, or the message became visible again while a slow job was still running. "Exactly once" is achieved by making the consumer idempotent, not by finding a broker that promises it. That links straight back to area 1.

Be ready to explain ordering (a single queue rarely guarantees it; a partitioned log guarantees it per partition, so the partition key decides which events stay in order), dead-letter queues for messages that keep failing, and backpressure when producers outrun consumers.

Question: A consumer processes a message, writes to the database, and crashes before committing its offset. What happens?

Short answer: The message is delivered again after restart, so the database write happens twice unless the consumer detects the duplicate.

What the interviewer is testing: Whether you design consumers on the assumption that every message may arrive twice. The strong answer names a deduplication key and stores it in the same transaction as the side effect.

Common follow-up: "Why not commit the offset before processing?" (Then a crash loses the message instead of duplicating it. You are choosing between at-most-once and at-least-once, and most business events cannot be lost.)

Area 5: Scaling and stateless services

Horizontal scaling only works if any server can handle any request. That makes where state lives the core question of this area. Sessions, uploaded files, in-memory caches and scheduled jobs that run "on the server" all break when the autoscaler adds a fourth instance or replaces the second one.

Know the components and their trade-offs. Load balancers need health checks and a routing algorithm. Read replicas add capacity and replication lag, so a user who writes and then immediately reads from a replica may not see their own change. Connection pools multiply: a hundred instances with fifty connections each can exhaust a database. Add enough container knowledge to explain how your service is built and started: a multi-stage Dockerfile, configuration through environment variables, a health endpoint the orchestrator can probe, and a graceful shutdown that finishes in-flight requests.

Question: What makes a service stateless, and why does it matter?

Short answer: No request depends on data held in one particular instance's memory or disk. It matters because instances can then be added, removed or replaced at any time without users noticing.

What the interviewer is testing: Whether you can find the hidden state in a real service, which is rarely where people first look. Local file uploads, in-process rate limiters and cron jobs are the usual suspects.

Common follow-up: "Your read replicas lag by two seconds. A user edits their profile and the page shows the old value. What do you do?"

A 7-day preparation plan

One small service, built with intent, teaches more than a week of reading. Build an order API backed by a relational database, with a background worker. If you only have two days, skip the build and spend them on day 2 and day 6: databases generate the most follow-ups, and saying answers out loud is the skill candidates practise least.

Day 1: API correctness. Build POST /orders with an idempotency key. Then fire two identical requests concurrently and check that only one order exists.
Day 2: Databases. Load a million rows. Write the three queries your API needs, read their plans, and add indexes only where the plan says they help. Reproduce a lost update with two sessions, then fix it with a version column.
Day 3: Caching. Put cache-aside in front of the product lookup. Change a price and watch what the cache serves. Write down your invalidation rule.
Day 4: Async work. Move order confirmation emails to a queue and a worker. Kill the worker mid-job and observe the redelivery. Make the handler idempotent.
Day 5: Scaling. Run two instances behind a load balancer in Docker Compose. Find everything that breaks, which is usually sessions and anything written to local disk.
Day 6: Answer out loud. Take the questions from each section and answer each in under two minutes: definition, mechanism, trade-off, example.
Day 7: Close the gaps. Revisit whatever the self-check and day 6 exposed, and prepare one incident story from your own work for each of the five areas.

How ready are you?

The self-check gave you five data points. The question bank behind it works the same way at scale: answer first, then read why each option is right or wrong.

Practise backend questions on squizzu, with an explanation and an in-depth breakdown on every question, across SQL, system design, Docker, Kafka and the language you code in.

If the design round is your weak spot, system design interview questions for 2026 goes deeper on estimation, sharding and consistency. For the database half, SQL interview questions for 2026 covers indexes, query plans and isolation levels with its own self-check.