What backend engineer interviews actually test

You searched for a list of questions. There are plenty of those, and most of them are useless, because a backend loop is not one test repeated four times. It is three or four different tests, run by different people, scoring different things, and a list flattens them into trivia. Someone who can recite the CAP theorem still fails the design round. Someone who solves the array problem in fifteen minutes still fails the deep dive on their own work.

What follows is the shape of the thing, and what the person on the other side is actually listening for.

The shape of the loop

For a mid-level or senior backend role at a company with more than about fifty engineers, the loop is usually some subset of:

1. Recruiter screen, 20–30 minutes. Stack, level, notice period, location and visa, compensation expectations, whether you are on call now and whether you are willing to be.
2. Hiring manager call, 30–45 minutes. What you own, what you have shipped, why you are leaving. Sometimes a light technical probe.
3. A coding exercise. Live in a shared editor, live in your own repo pairing with an engineer, or a take-home you submit and then walk through.
4. A system design round, 45–60 minutes, whiteboard or a blank Excalidraw canvas.
5. A deep dive on something you built, sometimes merged into the design round, sometimes separate.
6. A behavioural or cross-functional round, often with an engineer from another team or a product manager.

Smaller companies compress this: a founder call, a take-home, a final onsite that does everything at once. Big-tech loops add a dedicated round for the company's own value system and may weight the algorithmic coding much more heavily. Whether a heavy algorithmic screen predicts on-the-job performance is genuinely contested — you will find engineers with strong opinions in both directions and very little public evidence either way. It is still the gate at a lot of places, so the practical question is not whether it is fair but whether this particular employer uses it. Ask the recruiter. They will tell you, and the format they name tells you what to prepare.

Who is actually in the room

The coding round is usually run by a senior engineer on or near the team, sometimes with a second person silent and note-taking. They have a rubric. They are not trying to trick you, and by round three they are mostly bored, which is worse.

The design round is more often a staff or principal engineer, or an experienced senior who does this frequently. This person has opinions about queues, and they have been woken at 04:00 by something you are about to describe casually.

The deep dive may be the hiring manager or a tech lead. Their job is to establish whether the decisions in your stories were yours or were handed to you.

This matters because the same answer scores differently depending on who asks. "We used Kafka" is a fact to a recruiter, a starting point to a manager, and to the staff engineer it is an invitation to ask why not SQS, what your partition key was, and what happened to ordering when you had to reprocess.

The coding exercise, and what it is really scoring

Three formats dominate, and they score different things.

Algorithmic screen. Usually 45 minutes, one or two problems, hash maps and two pointers and the occasional graph traversal. The scoring is mostly: did you get to a working solution, did you talk while doing it, did you notice the complexity, did you test it. Silence is the common failure mode, not wrongness.

Realistic exercise. Increasingly common at mid-sized companies. Parse this file and expose it over HTTP. Implement a rate limiter. Add an endpoint to this existing repo. Here the scoring is closer to actual code review: do you handle errors or swallow them, do you validate input, are your names sensible, did you write a test, did you notice the ambiguity in the spec and ask rather than guess.

Pairing on a real codebase. You will be dropped into an unfamiliar repo with a bug or a small feature. This tests navigation more than authorship: can you find where the thing lives, do you read the tests first, do you run it before changing it.

In all three, the language question comes up. If you pick Go, expect someone to ask about context cancellation, goroutine leaks, or why you used a channel where a mutex was simpler. If you pick Java, expect the JVM: heap versus off-heap, what a full GC pause does to your p99, thread-pool sizing, and something Spring-shaped about bean scopes or transaction boundaries. Python invites the GIL and whether your blocking call just stalled the event loop. Node invites the same question in different clothing. Pick the language you actually write, not the one you think sounds senior.

System design: the questions inside the question

The prompt will be broad — design a URL shortener, a notification service, a ticket booking system, whatever the interviewer has run forty times. The prompt is not the test. The test is the set of follow-ups, and they are fairly predictable because they are the things that actually break in production.

Idempotency. "The client calls POST /payments, times out, and retries. Now what?" A good answer reaches for an idempotency key supplied by the client, a unique constraint in the database, and a decision about what to return on the duplicate. A very good answer mentions the transactional outbox, because you are about to publish an event about this payment and the write and the publish are not atomic.

Delivery semantics. Nearly every queue you will name is at-least-once. So: how do you not charge the customer twice, and what is your deduplication window, and where does the dedup state live, and what happens when it expires. If you say "exactly-once" without immediately qualifying what you mean, you have handed the interviewer their next question.

Failure propagation. "Your service calls a downstream service that has just got slow — not down, slow." The answer they want walks the chain: requests hold connections longer, the pool saturates, your own queue grows, your latency rises, your callers time out and retry, and the retries amplify the load on the thing that was already struggling. Then the mitigations: timeouts that are actually set, budgets rather than per-call timeouts, exponential backoff with jitter, circuit breakers, bulkheads, load shedding. The phrase "retry storm" earns you credit because it shows you have seen one.

Data. Expect index questions phrased as symptoms rather than theory: a query that was fast last month and is slow now with no code change. Plan flips, stale statistics, a selectivity assumption that stopped holding as the table grew, lock contention, bloat and vacuum behaviour in Postgres. Expect a schema migration question — renaming or splitting a column with no downtime — where the expected answer is expand and contract: add the new column, dual-write, backfill in batches, move reads, stop writing the old one, drop it later.

Caching. "Add a cache" is the beginning of the conversation. The follow-ups are invalidation strategy, TTL versus explicit eviction, what happens to the origin when a hot key expires and a thousand requests arrive at once, and whether you are prepared to serve stale data and for how long.

Measurement. If you say a system is fast, someone will ask how you know, and the right currency is percentiles and error rates, not averages. Knowing why the mean hides the problem — and that the user experiencing the p99 is often your highest-value user, because they have the most data — is a small thing that reads as experience.

The deep dive on your own work

This round decides seniority more often than the coding round does. The prompt is some version of "tell me about a system you designed or substantially changed." Then:

• What were the alternatives, and why did you reject them?
• What did you get wrong?
• What broke after it shipped?
• How did you know it was working?
• What would you do differently now?
• Who disagreed with you, and what happened?

The interviewer is testing whether you were the one making decisions. Candidates who inherited a design describe it beautifully and then have nothing when asked about the alternatives, because there never were any from their point of view. That is fine — say so, and describe a decision that was genuinely yours, even if it was smaller. A well-reasoned choice about how to backfill two hundred million rows is better evidence than a vague account of an architecture someone else drew.

Have rollout detail ready. Feature flag or percentage rollout, what the kill switch was, what metric you watched, what the rollback plan was, and whether you had to use it. Have one incident ready in which you were the cause. Blameless is the culture; owning the mistake without theatrics is the signal.

What a shallow answer sounds like

From the other side of the table, these are the tells:

• "We used Kafka because it scales." No partition key, no consumer group, no mention of what ordering guarantee you needed or lost.
• "We'd add Redis." Cache stated as the solution, with no invalidation story, no TTL, no thought about the stampede.
• "Microservices." Offered as an architecture rather than a trade — no mention of the transaction you just lost, the network call you just added, or how you now deploy them together anyway.
• "We'd index that column." With no sense of cardinality, write cost, or whether the query would use it at all.
• "It's eventually consistent." Used as an answer rather than a description of a problem you then have to handle in the UI or the reconciliation job.
• "It was fast, like 50 milliseconds." Average, at what load, measured where.
• "We have a hundred per cent test coverage." Volunteered without any account of what the tests actually assert, whether they run against a real database, or how flakes are handled.
• "I'd have to look that up." Fine for a syntax detail. Not fine as the answer to what happens when your service's downstream gets slow.

The common thread is a noun where a trade-off should be. Naming a technology is not an answer; describing what it costs you and why you accepted that cost is.

What to do next

Four things, in order of how much they will move the needle.

Write out two of your own systems, properly. A diagram, the three decisions you actually made, the alternatives, what broke, what you measured. An hour each. This is the round most often lost and least often prepared for.

Rehearse the failure chain out loud. Slow downstream, pool saturation, retry amplification, and the four mitigations. If you can say it fluently, a large fraction of design follow-ups become the same answer in different costume.

Pick a language and be ready for its sharp edges. One paragraph each on the memory model or concurrency model, how you would find a leak, and how you would profile a slow endpoint.

Ask the recruiter what the coding round is. Algorithmic, realistic, or pairing. They will tell you, and the three demand different preparation. Preparing for the wrong one is the most common avoidable loss in this process.