Backend Engineer Interview Prep: Questions and a Mock Test

API design rounds test whether you know what the protocol already promises, because designing on top of a contract you have half-remembered produces subtle bugs.

RFC 9110 defines the two properties that matter most. A method is safe if "their defined semantics are essentially read-only; that is, the client does not request, and does not expect, any state change on the origin server". GET, HEAD, OPTIONS and TRACE are safe. A method is idempotent if "the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request". That set is the safe methods plus PUT and DELETE.

Two consequences come up constantly. First, POST is deliberately not idempotent, so any create operation that a client might retry needs an idempotency key supplied by the caller, since the protocol will not save you. Second, DELETE is idempotent even though the second call usually returns 404, because the specification is about the effect on server state rather than the status code: after a DELETE, "subsequent DELETE requests to that resource will likely result in a 404 (Not Found) status code, which accurately reflects the fact that the resource is no longer available".

Status codes are worth getting right too. 401 means unauthenticated, 403 means authenticated but not permitted, 409 signals a conflict with current state, and 422 is the common choice for a syntactically valid request that fails semantic validation.

Almost every backend loop contains a database question, and almost all of them reduce to two things: what an index can and cannot help with, and what a transaction actually guarantees.

On indexes, the mental model to bring is that a B-tree index is sorted, so it can serve equality and range lookups and can also satisfy an ORDER BY without a sort. That ordering explains the leftmost-prefix rule for composite indexes: an index on (a, b) helps a query filtering on a, or on a and b, but not one filtering on b alone. It also explains why wrapping a column in a function usually disables the index, since the stored order is of the column and not of the function's output. A covering index, one that contains every column the query needs, avoids reading the table at all.

On transactions, be precise about the anomalies rather than reciting the level names. PostgreSQL's documentation is unusually clear here: "you can request any of the four standard transaction isolation levels, but internally only three distinct isolation levels are implemented, i.e., PostgreSQL's Read Uncommitted mode behaves like Read Committed". Its Repeatable Read is stronger than the standard requires, because it does not permit phantom reads. Read Committed, the default, permits both non-repeatable reads and phantoms, which is exactly why a read-modify-write sequence needs either explicit locking or an atomic update.

Caching questions are easy to answer badly because the addition is obvious and the removal is not. Interviewers are listening for invalidation.

The usual patterns are worth naming precisely. Cache-aside means the application checks the cache, and on a miss reads the database and populates the cache; it is simple and leaves the cache and database briefly inconsistent. Write-through updates both on every write, keeping them consistent at the cost of write latency. Write-behind acknowledges the write after updating only the cache and flushes later, which is fast and can lose data.

The failure modes have names and are frequently asked about directly. A stampede, sometimes called a thundering herd, happens when a hot key expires and every concurrent request goes to the database at once; the answers are a lock so only one request recomputes, or serving stale data while a single background refresh runs. Cache penetration is repeated lookups for keys that do not exist, which pass straight through; caching a negative result, or a probabilistic filter, is the usual defence.

On eviction, know that a TTL bounds staleness while LRU bounds memory, and that they solve different problems. The senior answer to "how long should the TTL be" is a question back: how stale can this data be before someone is harmed.

Concurrency questions in a backend loop are rarely about threads in the abstract. They are about two requests arriving at the same time and doing something incoherent.

The canonical example is the read-modify-write race: two requests read a balance of 100, both subtract 30, and both write 70. The fixes are worth being able to compare. An atomic update performed in the database, expressed as a single statement rather than a read followed by a write, removes the window entirely. Pessimistic locking takes a row lock for the duration of the transaction, which is correct and reduces concurrency. Optimistic concurrency control adds a version column and fails the write if the version changed, which suits low-contention cases and requires the caller to handle a retry.

Deadlock is the other staple. Two transactions taking the same locks in different orders will eventually block each other, and the standard prevention is a globally consistent lock ordering. Databases detect deadlocks and abort one participant, so application code has to be prepared for a transaction that fails and can be safely retried.

Be ready for distributed locks as a follow-up, and for the honest answer that they are harder than they look: a lease can expire while the holder still believes it holds the lock, so the protected operation ideally needs to be idempotent or fenced by a monotonically increasing token.

System design rounds go wrong in a predictable way: the candidate starts drawing boxes before establishing what the system must do. The strong opening is to extract functional requirements, then scale numbers, then the quality attributes that actually drive the design.

Estimation is a tool, not a ritual. Deriving reads per second from daily active users and a usage assumption tells you whether the design needs a cache at all, and deriving storage growth per year tells you whether partitioning is a day-one concern or a year-three one. Stating the assumption out loud so the interviewer can correct it is part of the exercise.

The twelve-factor methodology remains a good shared vocabulary for the operational half. It asks you to "store config in the environment", to "treat backing services as attached resources" so a database can be swapped without a code change, to "execute the app as one or more stateless processes", and to "maximize robustness with fast startup and graceful shutdown". Statelessness is the one that does the most work in an interview, because it is what makes horizontal scaling, rolling deploys and autoscaling possible, and it is why session state belongs in a shared store.

Finally, expect to be pushed on a tradeoff you proposed. The answer that scores is not the one with no downsides; it is the one where you already know what the downsides are.