Backend Developer Interview Questions — Databases, Concurrency, Incidents, and the Follow-Ups on Your Own Code

Six: databases and transactions, networking and HTTP, concurrency, incident response, system design, and portfolio follow-ups. Databases cover storing and reading data safely and fast; networking covers the path a request travels; concurrency covers what happens when several requests hit the same resource; incident response covers your behavior when something breaks; design covers judgment when you're building something that doesn't exist yet; and follow-ups verify that the other five live in your hands, not just your notes.

The categories map onto the job itself. A backend engineer stores data, moves it across a network, absorbs simultaneous requests, and restores service when it breaks. Interview questions are a miniature of that work, which is why answers improve the moment you describe a concrete situation instead of a definition.

How you split your hours should follow the stack in the posting. It's also worth knowing how crowded this lane is: in the 2025 Stack Overflow survey, 27% of respondents described their role as full-stack developer and 14.2% as back-end developer, making backend work the largest specialized track. Broad demand also means broad question surface — one interviewer will care about query plans, the next about deployment and rollback.

One complete answer runs definition, trade-off, then the choice you made in your own project. For an index, don't stop at 'a data structure that speeds up reads' — add what it costs (write throughput and storage) and which columns you actually indexed because of that cost. The recurring topics are indexes and query plans, normalization and denormalization, ACID, isolation levels, locking, the N+1 problem, and connection pools.

Isolation levels are not a four-name memorization exercise. Answer with the default your database actually uses and what that default permits. The PostgreSQL documentation states plainly that "Read Committed is the default isolation level in PostgreSQL," and notes that two successive SELECT statements inside a single transaction can see different data if another transaction commits in between. MySQL's manual, on the other hand, gives REPEATABLE READ as the default for InnoDB. The fact that two mainstream databases ship different defaults is itself good material — it lets you move the conversation to which anomaly would actually hurt the product you're building.

Follow-ups usually arrive as failure cases. For 'it's still slow with the index — what do you look at?', walk through the query plan, cardinality, composite index column order, and expressions that prevent the index from being used. 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, cache). Listing tool names without costs collapses at the next question.

Whether you can narrate the full round trip of a single request without gaps. From a URL in the address bar to a rendered response: DNS lookup, TCP connection and TLS handshake, load balancer, application server, database, and the response traveling back. Rehearse that path out loud once and most networking questions turn out to branch off it.

The recurring cluster is TCP versus UDP, HTTP/1.1 versus HTTP/2 and HTTP/3, status code selection (400 versus 422, 401 versus 403), cookies and sessions versus JWT, what CORS does and doesn't block, and timeouts and retries. Authentication almost always turns into a trade-off question. Sessions keep state on the server, so revocation is instant but scaling needs a shared store; JWTs are stateless and scale easily, but killing an issued token mid-flight is hard. The answer isn't what you picked — it's what you gave up.

Timeouts and retries separate candidates more than anything else in this category. If your project calls an external API, expect 'what happens when the response takes 30 seconds?' and 'if you retry, doesn't the customer get charged twice?'. Say whether you set connect and read timeouts separately, whether you used exponential backoff, and how you decided which requests were safe to retry at all.

'What happens when the same request arrives twice at once?' is the standard problem. Inventory decrements, limited-quantity coupons, duplicate payments, and loyalty points are the usual settings. The answer has three parts: locate the race precisely (between the read and the write), pick a defense (pessimistic database lock, optimistic locking with a version column, a unique constraint, a distributed lock, or serializing through a queue), and state what that defense costs.

Remember that the cheapest reliable defense is a unique constraint. A unique index on something like order id plus product means the database still catches the duplicate when your application logic is wrong. Layer idempotency on top and the answer gets stronger: assigning a client-supplied key to a request so repeating it produces the same result is the standard way to make retries safe on an unreliable network.

The follow-ups then bend toward your runtime. Thread-based stacks invite questions about thread pool and connection pool sizing, deadlocks, and lock ordering; event-loop stacks invite questions about what you moved off the loop so it never blocks. If you can explain in one paragraph how your runtime handles requests in parallel, this category is covered.

Tell incident stories in chronological order: detection (what told you), containment (how you stopped the bleeding), cause (what was actually wrong), resolution (how you restored service), and prevention (what you changed). Interviewers are not grading the size of the outage — they're checking whether you walked those steps deliberately. If a user reported it before any alert fired, say so, then continue with the metric and alert you added because of it. That version scores better than a tidy story with no learning in it.

Deployments breaking things is not an edge case, and the industry data says so. The 2025 DORA report from Google Cloud, based on a survey of nearly 5,000 technology professionals worldwide, found that 90% of respondents use AI at work and more than 80% believe it raised their productivity — yet AI adoption still shows a negative relationship with software delivery stability. The report explains it directly: "AI accelerates software development, but that acceleration can expose weaknesses downstream. Without robust control systems, like strong automated testing, mature version control practices, and fast feedback loops, an increase in change volume leads to instability." More change per week is exactly why interviewers keep asking how you behave when something breaks.

For design questions ('design a URL shortener', 'design a notification system'), your first move is asking questions back. Establish traffic volume, read-to-write ratio, acceptable latency, and how strict consistency needs to be, and only then sketch the shape. After that, name your own bottleneck — a single database, a hot key, fan-out — and pair every fix with its cost. There is no correct answer here; narrowing the requirements and saying trade-offs out loud is the score.

Junior rounds ask whether you know it; senior rounds ask whether you decided it. For juniors, the weight sits on CS fundamentals and the reasoning behind project choices. For experienced candidates, it shifts to design judgment, operational history, and decisions made inside a team. The same resume line — 'added a cache' — draws 'why did you need a cache?' from a junior panel and 'how did you handle invalidation and the consistency you gave up?' from a senior one.

If you're early in your career, fill the gap with density of reasoning rather than scale. A toy project with no users still produces a senior-shaped answer when it sounds like this: 'I fired 100 concurrent requests, inventory went negative, and here's how I stopped it and how I verified the fix.' The structure is identical to a production story; only the traffic differs.

If you're experienced, the mistake runs the other way — talking only about code. Migrations you ran without downtime, on-call rotations and postmortems, compromises you accepted because of legacy constraints, and the documents or conventions you left behind for the team are the raw material of a senior interview. Bring one story for each and the behavioral half of the loop takes care of itself.

Fill four boxes for every line on your resume: why you chose it, what the alternatives were, what the result was, and what you'd do differently today. Backend portfolios attract three follow-ups in particular — 'if traffic went up 100x, what breaks first?', 'if that external API goes down, what does the user see?', and 'if the data starts drifting, how would you even notice?'. Have answers to those three and most deep-dives stay in safe territory. If you have no numbers, run a load test now and record response time and error rate.

The two-week routine separates gathering material from practicing it. In week one (D-14 to D-8), pull 30-40 likely questions across the six categories and write the four-box Q&A for your projects. In week two (D-7 to D-3), take one category per day, answer the same questions three times out loud, schedule two or three mock interviews, and keep a review note after each — the questions that stalled you, the answers that rambled, the concepts you didn't know. Most candidates skip the out-loud part. In a survey of 131 people actively preparing for technical interviews, published at FSE 2025 as "How do Software Engineering Candidates Prepare for Technical Interviews?", 35% (46 people) had never attempted a mock interview and 82% (107) had done five or fewer, while 78% rated oral and verbal clarity as important or very important. The same paper found that candidates who practiced communication frequently or prepared with others reported significantly higher perceived preparedness, whereas the number of coding problems solved per day showed no such effect.

If you can't find someone to talk to, a tool can cover the gap. Something like preterview, which runs a spoken question-and-answer session and turns it into a report — plus a portfolio review — works for rehearsing the why-alternatives-result answers until they're automatic, and signing up includes one free pass so you can see the output first. Whatever you use, verify technical facts against official documentation; defaults like isolation levels and framework settings change between versions. Spend the last two days (D-2 to D-1) polishing the five weakest answers in your review notes and re-reading the company's engineering blog, not learning anything new.