Backend Engineer Interview Prep: Beyond the Coding Round
Marcus Weaver
Tech Lead
Backend engineer interviews look like algorithm interviews on the schedule and behave like something else in the room. The coding round is real, but the questions that decide senior offers are about concurrency, data modelling, failure, and what happens when the same request arrives twice. Those are not on a problem archive either.
The four things a backend loop tests
| Area | The question you will actually hear | What it is really checking |
|---|---|---|
| Coding | A data structure problem, often with a real-world skin | Fluency, not cleverness |
| Data modelling | "Design the schema for this feature" | Whether you have maintained a schema, not designed one |
| Concurrency | "Two requests arrive at the same time. What happens?" | Whether you have debugged a race in production |
| Failure | "The downstream call times out. Now what?" | Whether you think in terms of retries and idempotency |
Rows two through four all share a property: they reward experience over revision, which is why candidates who have shipped and operated services do better than candidates who have solved more problems. The good news is that the experience can be articulated with practice, and articulating it is most of the assessment.
The word that carries a whole round
Idempotency. If a backend interview goes past the coding round and you never use it, you have probably missed the point of at least one question. Any endpoint that takes money, sends a message, or creates a record will be probed on what happens when the client retries after a timeout it could not distinguish from a failure.
| Failure | The answer that scores |
|---|---|
| Client retries a payment | Idempotency key, stored, checked before the side effect |
| Two writers update one row | Optimistic locking with a version column, or a transaction |
| Queue delivers twice | Consumers must be idempotent; at-least-once is the default |
| Downstream is slow | Timeout, bounded retry with backoff and jitter, circuit breaker |
| Everything retries at once | Jitter, because synchronised retries are how you turn a blip into an outage |
"I call it my billion-dollar mistake. It was the invention of the null reference in 1965."
- C.A.R. Hoare, QCon London (2009)
The interview-relevant lesson is not about null specifically. It is that the expensive bugs come from states the design allowed but nobody considered. When you are asked to model something, saying which states your schema makes impossible is a senior signal that costs one sentence.
Database questions, ranked by how often they decide things
If you prepare one database topic, prepare indexes: what a composite index does, why column order matters, why a query with a function on the indexed column stops using it, and why an index makes writes slower. That single topic covers more interview surface than everything below it on the chart.
Talking about concurrency without hand-waving
The weak answer is "I would add a lock". The strong answer names what is being protected, for how long, and what it costs. "I would take a row-level lock on the account for the duration of the transfer. It serialises transfers on that one account, which is acceptable because a single account is not a hot key here, and if it became one I would move to an append-only ledger."
๐ Three sentences, every time
What am I protecting. What does this cost when it is contended. What would I do if it became contended. That template turns a vague concurrency answer into a senior one, and it works for locks, queues, caches, and rate limiters alike.
A two-week backend plan
Week one, the coding round, but capped: an hour a day, spoken aloud, on medium problems. Backend loops rarely go as hard on algorithms as the reputation suggests, and diminishing returns arrive early.
Week two, the rest of it. Take three services you have worked on and, out loud, describe the schema, where the races are, what happens when a dependency is down, and what you would change now. That exercise prepares the data modelling, concurrency and failure rounds simultaneously, and it uses material you already have rather than material you have to learn.
More Articles
Concurrency Questions That Trip Up 90% of Candidates
January 30, 2026 ยท 11 min read
API Design Interview Questions: REST, GraphQL, and Beyond
November 20, 2025 ยท 13 min read
The System Design Interview Is Not About Systems: It's About How You Think
February 18, 2026 ยท 12 min read