Backend Interview Questions: Databases, Concurrency and Incidents

The six categories are a miniature of the job. A backend engineer stores data, moves it across a network, absorbs simultaneous requests, restores service when it breaks, and designs features that do not exist yet. The sixth category, follow-ups on your resume, checks whether the other five show up in work you have actually done.

Split your hours according to the full job posting, including the preferred qualifications. Tools named in the posting, whether a database, a message queue, or a deployment tool, can draw questions about defaults and limits, so prepare those before tools the posting does not mention.

One complete answer runs definition, trade-off, then the choice you made. For an index, add what it costs in write throughput and storage, and which columns you indexed because of that cost. Recurring topics are indexes and query plans, normalization, ACID, isolation levels, locking, the N+1 problem, and connection pools.

Isolation levels are not a four-name memorization exercise. The PostgreSQL documentation describes what each level permits under concurrent transactions (official reference). If you used PostgreSQL, confirm the behavior there; if you used another database, check that database's own documentation. Levels with the same name are implemented differently across databases, so cite the documentation of your own database rather than generalizing from another.

This is an illustrative example, not a real candidate. Asked 'have you ever changed an isolation level?', a candidate might say: 'Two reads inside one settlement transaction returned different results. I checked the documented behavior of the default level, raised the level for that transaction only, and added retry logic for conflicts.' The follow-up then moves toward reasoning, such as how the retry count was chosen.

Follow-ups usually arrive as failure cases. For 'it is still slow with the index', walk through the query plan, cardinality, composite index column order, and expressions that prevent index use. For 'how did you find the N+1?', cite query logs and queries per request, then name the cost of each fix: join, batch loading, or cache.

Describe the path through your actual system: DNS, connection setup, load balancer, server and storage, including cache hits and reused connections. For HTTPS over HTTP/1.1 or HTTP/2, explain TCP and TLS; HTTP/3 uses QUIC, so not every request starts a new TCP connection (HTTP/3 standard).

Prepare transport protocols, HTTP versions, status codes, cookies, sessions, JWTs, CORS, timeouts and retries against your implementation. For authentication, explain what state the server stores and checks. Using a JWT does not make the whole system stateless. Compare how your design handles logout, token revocation, expiry and consistency across servers.

If your project calls an external API, expect 'what happens when the response takes 30 seconds?' and 'if you retry, does the customer get charged twice?'. Explain, from your own code, whether you set connect and read timeouts separately, whether you used exponential backoff, and how you decided which requests were safe to retry.

Inventory decrements, limited coupons, duplicate payments, and loyalty points are the usual settings. The answer has three parts: locate the race precisely, pick a defense, and state its cost. Defenses include a pessimistic database lock, optimistic locking with a version column, a unique constraint, a distributed lock, or serializing through a queue.

This is an illustrative example, not a real candidate. 'I reproduced locally that two simultaneous requests from one user issued two coupons. I added a unique constraint on user id plus coupon id and made the application respond as already issued when the constraint fires. I considered a distributed lock, but adding another piece of infrastructure was a cost the database constraint made unnecessary.' That one paragraph holds the race, the defense, and the rejected alternative.

For retries of the same operation, explain how the client reuses the same idempotency key and how the server records the key and processing result. A new key on every attempt cannot identify the repeat. Stripe’s idempotent-request documentation provides one implementation; retention and error behavior must be checked for the API you use. Adding a key alone does not prevent duplicate side effects: test concurrent attempts and partial failures.

Tell incident stories chronologically: detection, containment, cause, resolution, prevention. Even a small outage shows your reasoning when it follows those five steps. If a user reported the problem before any alert fired, say so, then continue with the metric and alert you added afterward. That version is accurate and shows what you learned.

For design questions, your first move is asking questions back. Establish traffic volume, read-to-write ratio, acceptable latency, and how strict consistency needs to be, then sketch the shape, name your own bottleneck (a single database, a hot key, fan-out), and pair each fix with its cost. There is no fixed correct answer, so the narrowing questions and spoken trade-offs are the substance of the response.

Junior candidates usually get a scoped-down version, closer to 'what tables and endpoints would you build for this feature?'. Asking back and naming the limits of your design still applies. The habit of anticipating the next question is covered in the developer mock interview guide.

Junior rounds weigh CS fundamentals and the reasoning behind project choices. Senior rounds shift toward design judgment, operational history, and decisions made inside a team. The same resume line, 'added a cache', tends to draw 'why did you need one?' for a junior and 'how did you handle invalidation and the consistency you gave up?' for a senior.

Early in your career, fill the gap with density of reasoning rather than scale. A toy project with no users still yields a well-structured answer when you can say you fired concurrent requests, watched inventory go negative, fixed it, and verified the fix. Run that experiment before the interview and record the numbers so you are not inventing them mid-answer.

If you are experienced, the risk runs the other way: talking only about code. Migrations without downtime, on-call rotations and postmortems, compromises accepted because of legacy constraints, and the documents or conventions you left for the team are the raw material. Prepare one story for each so technical and collaboration questions draw on the same material.

The template below is a Preterview editorial suggestion, not a published scoring rubric. Fill four boxes for every technical choice on your resume.

• Why you chose it: the requirements, constraints, and comparison criteria at the time
• What the alternatives were: options you evaluated and why you dropped them
• Result and evidence: measured values or logs, or 'not measured' if that is the truth
• What you would do now: what you would change and why

Backend portfolios attract three follow-ups in particular: what breaks first if traffic rises 100x, what the user sees if that external API goes down, and how you would notice data starting to drift. Write answers per project, and if you have no numbers, run a load test now and record response time and error rate. For getting outside eyes on the portfolio itself, see how to get feedback on a developer portfolio.

The two-week routine separates gathering material from practicing it. 1. In week one, pull likely questions per category and fill the four-box template. 2. In week two, take one category per day, answer the same questions three times out loud, and keep a review note of questions that stalled you, answers that rambled, and concepts you did not know. 3. In the last two days, polish the five weakest answers from your notes and re-read the company's engineering blog instead of learning anything new. If your resume lines need tightening first, the developer resume writing guide covers the order.

If you cannot find someone to talk to, Preterview's document-based mock interview, post-interview feedback, and portfolio review can serve as rehearsal. Check current conditions on the pricing page and the output format in a sample report. Whatever tool you use, verify version-dependent facts such as isolation levels and framework defaults against official documentation.