Backend Engineer Interview Prep: Beyond the Coding Round

To prepare for a backend engineer interview, practice four things out loud: a capped amount of coding, data modeling, concurrency, and what happens when something fails. The coding round is real, but the questions that decide senior backend offers are about schemas, races, retries and the same request arriving twice, and those are not on a problem archive.

The four things a backend loop tests

Rows two to four 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 experience can be put into words with practice, and putting it into words 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 the word, you have probably missed the point of at least one question. Any endpoint that moves money, sends a message or creates a record will be probed on what happens when the client retries after a timeout it could not tell apart from a failure.

Worked example: an idempotent transfer endpoint

"Design the endpoint that transfers money between two accounts" is the classic way this gets asked. The client sends a key it generated, the same key on every retry, and the server remembers what it did with it:

POST /transfers
Idempotency-Key: 7f3c9a...        (generated by the client, reused on retry)

idempotency_keys(key PK, request_hash, status, response, created_at)

1. INSERT the key with status 'in_progress'.
   If the key already exists, read its row instead:
     same request_hash, status 'done'         -> return the stored response
     same request_hash, status 'in_progress'  -> 409: still running, retry soon
     different request_hash                   -> 422: key reused for another request
2. In one transaction: debit, credit, store the response, set status 'done'.
3. A key stuck 'in_progress' past a timeout may be taken over by a retry.

Three sentences carry the answer. The key is claimed before the side effect, so two retries cannot both move money. The transfer and the stored response commit together, so a crash leaves either nothing or both. And a retry with the same key gets the original response, not a second transfer. Then say what the table costs (a write per request, and a cleanup job for old keys) before the interviewer asks.

"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 lesson is not about null itself. 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 topics, in the order to prepare them

1. Indexes and why a query is slow. It touches every other topic: reading a query plan, composite indexes and why column order matters, why a function on an indexed column stops the index being used, and why every index makes writes slower.
2. Transactions and isolation. What each isolation level allows, which anomalies you would actually see, and when a row lock beats a retry.
3. Schema design and normalization. Which facts live once, which you copy on purpose, and how the copies stay in step.
4. Replication and read replicas. Replica lag, and reading your own writes when the next page load goes to a replica.
5. Which database product. Last, because the right answer follows from the four above, and naming a product first is a common way to lose the interviewer.

If you prepare one topic properly, make it indexes. The guide to choosing and modeling a database starts from access patterns and works through keys and indexes with a worked example.

Five backend questions, and what a strong answer says

• "This query got slow. What do you do?" Read the plan before guessing. Look for a full scan, a function or type conversion on the filtered column, or a composite index whose leading column the query does not use. Fix it, then say what the new index costs on writes.
• "Two users buy the last item at the same time." Make the check and the write one statement, such as decrementing stock only where it is still above zero and checking that a row changed, or lock the row for the length of the transaction. Say which you would pick and why: the conditional update holds no lock while the user waits.
• "The payment provider timed out." You do not know whether it succeeded, so never mark the payment failed on a timeout. Retry with the same idempotency key, and reconcile against the provider's records for anything still unknown.
• "Add a column to a very large table without downtime." Expand, then contract: add it as nullable, deploy code that writes both shapes, backfill in batches, switch reads, and only then remove the old path.
• "One slow dependency is taking the service down." Timeouts on every call, bounded retries with backoff and jitter, a circuit breaker, separate pools so one dependency cannot use every thread, and a fallback that is actually useful to the user.

For the concurrency side in more depth, concurrency questions that trip up most candidates covers deadlocks, races and locks, and API design interview questions covers rate limiting, versioning and idempotency keys at the interface.

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 serializes 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."

A two-week backend plan

Week one, the coding round, but capped: an hour a day, spoken aloud, on medium problems. Past the point where medium problems feel routine, extra algorithm practice pays less for a backend role than the rest of this list.

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 one exercise prepares the data modeling, concurrency and failure rounds together, using material you already have rather than material you have to learn. Then say it to an interviewer who asks why: a system design mock interview covers the data modeling and failure questions, a coding mock interview the week-one work, and a mock interview built from your resume asks about the services you actually listed.

Frequently asked questions