Backend interviews are the least language-specific of any engineering loop. Whether you write Java, Python, Go, Node or C#, the same five conversations come up — and the syntax you know best is rarely what decides the outcome.

Below are 20 questions grouped by those five rounds, with the experience level each usually targets. For every group there's a note on how to say the answer out loud, because from the database round onward you're mostly talking, not typing.

WhalePrep observation: the most common backend interview failure isn't a wrong answer. It's a right answer with no tradeoff in it — describing what you did without ever saying what it cost you.

20
Questions across the 5 rounds backend loops reuse
5
Topic areas that stay the same across languages
1
Named tradeoff is what makes an answer sound senior

APIs and HTTP

The opening round. Weighted heavily for Junior and Middle candidates.

  1. Design an endpoint for placing an order. What are the resources, the methods, and the status codes?
  2. What's the difference between PUT and PATCH, and which HTTP methods are supposed to be idempotent?
  3. How do you change an API without breaking clients that already depend on it?
  4. REST, GraphQL, gRPC — when would you actually choose each one?

Saying it out loud: question 1 is a design question wearing a trivia costume. Weak answers list verbs. Strong ones narrate decisions: "POST to a collection to create the order, because the server assigns the ID. Return 201 with a Location header. If the client can retry, I'd want an idempotency key — otherwise a network timeout means a double order." That last sentence is the whole answer. It shows you've thought about what happens when the happy path fails.

Databases and data modelling

The Middle-level core, and the round most candidates underprepare.

  1. What does a database index actually do, and when does adding one make things worse?
  2. What is the N+1 query problem, and how would you notice it in a real codebase?
  3. What do transaction isolation levels protect you from? Give an example of an anomaly.
  4. When would you denormalise on purpose? When is a relational database the wrong choice?

Saying it out loud: for question 5, the second half of the question is the real one — anyone can say an index speeds up reads. Answer the cost: "An index is a sorted structure the planner can seek into instead of scanning. The cost is on writes: every insert and update has to maintain it, and it takes disk. So a table with heavy writes and a rarely used filter is exactly where an extra index hurts more than it helps." Benefit, then cost, then when the cost wins. Roughly twenty seconds, and it sounds like production experience.

Why this works: interviewers are trying to distinguish "has read about indexes" from "has watched an index slow down a write-heavy table at 2am." The only reliable tell is whether you volunteer the downside without being asked.

Performance, caching and concurrency

Middle to Senior. Usually framed as "this got slow, what now?"

  1. An endpoint that used to be fast is now taking two seconds. Walk me through your diagnosis.
  2. Compare cache-aside, write-through, and TTL-based invalidation. Which do you default to?
  3. Two requests try to charge the same customer at the same time. How do you stop a double charge?
  4. A request needs to do thirty seconds of work. How do you handle that without blocking the client?

Saying it out loud: question 9 rewards a stated order rather than a list of guesses: "First I'd want to know whether it's slow for everyone or just some requests, because a p99-only problem points somewhere different than a p50 problem. Then I'd look at the obvious suspects in order — a query that lost its index, an N+1 that appeared when someone added a field, or a downstream call that got slower." Interviewers are listening for whether you narrow before you dig. Candidates who immediately guess "probably the database" score lower than candidates who say what they'd measure first.

System design and architecture

The Senior round, and the one that usually decides your level.

  1. Design a URL shortener. Then: how would you add rate limiting?
  2. What makes an operation idempotent, and why does that matter when clients retry?
  3. This service handles a hundred requests per second and needs to handle a hundred thousand. What changes?
  4. Microservices or a monolith — and what actually goes wrong with microservices in practice?

Saying it out loud: the design round rewards scoping before solving. Open with constraints, not architecture: "Before I draw anything — what's the read-to-write ratio, and do short links ever expire? A read-heavy service that never expires is basically a caching problem. If links expire and we need analytics per click, that's a very different storage decision." Then pause. Interviewers deliberately leave this vague, and the pause is not dead air — it's the part of the answer where you demonstrate judgment.

Production, testing and reliability

Asked at every level. This is where interviewers find out if you've operated what you built.

  1. How do you test code that depends on a database? What do you mock and what do you not?
  2. How would you add a non-nullable column to a large table with zero downtime?
  3. A service you depend on becomes slow but doesn't fail. What does your code do about it?
  4. Something only reproduces in production. How do you debug it?

Saying it out loud: question 19 has a specific expected vocabulary, and using it precisely is the point: "Slow is worse than down, because slow ties up my connections until I run out. So: an aggressive timeout first, then retries with backoff and jitter — but only on idempotent calls — and a circuit breaker so I stop hammering a service that's already struggling." The clause most candidates omit is "only on idempotent calls." Saying it out loud tells the interviewer you've caused this bug before and learned from it.

Practical target: for each of the five groups, prepare one real story from your own work — an API you versioned, an index you regretted, a slowdown you traced, a service you scaled, an outage you debugged. Twenty questions become five stories, and stories hold up under interview nerves far better than definitions.

The part that isn't about backends

Notice how many of the answers above depend on a pause — scoping the URL shortener before designing, narrowing before guessing at the slow endpoint. That's not a stylistic preference. It's the actual skill being measured in a senior backend loop.

Under interview pressure the pause is the first thing to go: nerves push you to fill silence with the first plausible answer, which is exactly the failure mode these questions are designed to catch. We wrote about why that happens, and how to make silence work for you, in Why silence sounds professional in interviews.

The practical version: take three questions from this page — ideally one design question — and answer them out loud, all the way through. In your head everything sounds structured. Out loud is where you find out.