Backend Interviews in 2027: What to Study and Be Able to Explain

If you are preparing for backend interviews in 2027, a useful question is: which parts of a system could you explain confidently if someone kept asking “why?”

You might know that an application needs transactions, caching, queues, and authentication. The deeper work is explaining what each mechanism guarantees, where that guarantee ends, and what happens when requests overlap or a dependency fails.

AI can help you draft an implementation or explore a topic. You still need enough understanding to judge the result and explain the decisions behind it. Make that the focus of your preparation.

The study map below draws on the topics and follow-up scenarios in DeepRound's backend interviews. Use it with your own stack. For each area, it identifies what to study, what you should be able to explain, and where to go deeper.

1. How your application executes work

Start with the execution model of the runtime you use. Follow a request from arrival through application code, database access, and response creation. Identify which parts use CPU, which wait for I/O, and which resources remain occupied while waiting.

Study: concurrency and parallelism, blocking operations, scheduling, shared state, cancellation, and resource cleanup.

Be able to explain:

• How your service handles another request while one is waiting for a database response.
• What happens when a request performs expensive computation or starts too many background operations.
• Who owns unfinished work when the caller disconnects, a timeout expires, or the application shuts down.

A useful question is: “We made every operation asynchronous. Why does the service still slow down under load?” Your answer should connect the execution model to a finite resource: CPU time, connections, workers, memory, or downstream capacity.

Go deeper: distinguish limiting active work from limiting queued work. A design can allow only ten operations to run while still creating a million waiting tasks. Explain where you would apply backpressure, what happens when capacity is reached, and how cancelled work releases its resources.

You do not need to study every language's runtime. Build an accurate model of the one you would use in the role.

2. How the database protects correctness

Transactions become easier to reason about when you start with a business rule: stock cannot go below zero, an email must be unique, or a balance change and its payment record must be saved together.

Study: constraints, atomicity, isolation levels, row locks, conditional writes, transaction boundaries, and deadlocks.

Be able to explain:

• Why checking a condition in application code and then writing can fail when two requests overlap.
• Which database mechanism enforces the rule even when several application instances are running.
• Which changes must commit together, and what should happen if one of them fails.

For example, two registration requests can both observe that an email is available. Explain how a uniqueness constraint resolves that race and how the application turns the losing write into a useful response.

For a purchase, explain both how competing stock reservations are coordinated and why order creation belongs in the same transaction. “Use a transaction” leaves the concurrency mechanism unspecified.

Go deeper: describe a possible execution order under your chosen isolation level. Know which conflicts cause waiting, which can abort a transaction, and when retrying the whole transaction is appropriate. The PostgreSQL isolation guide is a useful reference for concrete guarantees; check the equivalent documentation for your database.

3. What happens when an operation only partly succeeds

A request can fail from the caller's perspective after the server has already changed state. A worker can save its result and crash before acknowledging the message. These gaps are central to reliable backend design.

Study: timeouts, retryable failures, idempotency, acknowledgements, duplicate delivery, backoff, and reconciliation.

Be able to explain:

• Why a timeout may leave the outcome unknown.
• How a repeated request is recognized as the same logical operation.
• What happens if a worker crashes immediately before or after saving its result.

Take a background import. Explain when the job is acknowledged, where progress is stored, and what a second delivery does. Then change the scenario to an external payment: which guarantees still hold when the side effect happens outside your database?

Go deeper: define the boundary of an idempotency guarantee. A process-local set does not coordinate several instances. Recording an event and applying its database change in separate transactions leaves a failure window. An external service introduces its own contract.

Also explain how retries affect load during an outage. Know why attempts need limits and why backoff with jitter helps avoid synchronized retries. AWS's guide to timeouts, retries, and backoff covers these mechanisms.

4. How to investigate a slow system

Practice describing an investigation before proposing a fix. A slow endpoint may be waiting for a connection, blocked behind another transaction, making too many queries, or spending time in an external service.

Study: latency distributions, throughput, saturation, tracing, query plans, indexes, connection pools, and N+1 queries.

Be able to explain:

• Which measurements would tell you where a request spends its time.
• Why individually fast queries can still produce a slow endpoint.
• How you would verify that a change improves performance under representative load.

Suppose average latency is stable but the slowest requests are getting worse. Explain why you would inspect the latency distribution, request mix, and periods of resource contention.

Traces help connect operations within a request; metrics help show patterns across requests. The OpenTelemetry tracing documentation explains how spans represent work and its timing.

Go deeper: separate time spent executing from time spent waiting. Increasing a connection pool might reduce application-side waiting while putting more pressure on the database. Adding an index can improve a read path while increasing write cost. Explain what evidence would justify either change and what you would measure afterward.

The Slow API series explores these distinctions through concrete investigations.

5. What caching changes about correctness and capacity

A cache introduces another copy of data and another lifecycle to manage. Before choosing a cache technology, decide what stale data the application can tolerate and what happens when the cache cannot help.

Study: cache keys, TTL, invalidation, eviction, cache-aside loading, concurrent misses, and capacity limits.

Be able to explain:

• Which data can be reused, for whom, and for how long.
• What happens when many requests miss the same key at once.
• How updates, load failures, and eviction affect what callers receive.

Consider a value that changes in the database while an older read is still in flight. Can that old read populate the cache after invalidation? Trace the order of events before proposing a fix.

Go deeper: distinguish a freshness policy from a memory limit. In a cache that removes expired entries only when they are read, untouched entries remain stored. Explain how eviction or admission control bounds stored data, and separately how you bound pending loads.

Be precise about scope. Sharing a pending fetch inside one process can reduce duplicate work there; it does not automatically coordinate every instance of a service.

6. How to structure a system so it can change

Architecture preparation should include small decisions you can explain concretely: where a business rule belongs, how a dependency is replaced in a test, or how two application versions coexist during deployment.

Study: separation of concerns, dependency direction, API contracts, test boundaries, compatible schema changes, and failure isolation.

Be able to explain:

• How an HTTP handler and a background worker can reuse a business operation.
• How you would test a declined payment without calling the real provider.
• How you would deploy a schema change while old and new instances are both serving requests.

For the shared operation, describe the inputs it needs and the result it returns. Explain where HTTP parsing ends, where business decisions happen, and how persistence is accessed. Naming layers is useful only if their responsibilities are clear.

Go deeper: plan a change in stages. If a column is being replaced, account for old readers, old writers, backfilled data, and updates made during the transition. Explain when it becomes safe to switch reads and remove the old interface.

For a role involving AI features, apply the same reasoning to model providers: what belongs in a provider adapter, which capabilities differ, how errors are represented, and how a slow provider affects the request. Tie abstractions to actual differences you need to support.

7. Where trust ends and authorization begins

A valid request from a logged-in user can still ask for something that user must not access. Build your security explanations around the resource and action being protected.

Study: authentication, authorization, tenant isolation, input validation, parameterized queries, secret handling, and session security.

Be able to explain:

• Why knowing the caller's identity does not establish access to a particular project or document.
• Where the server verifies that an action is allowed.
• How you would test that one organization's user cannot read or modify another organization's data.

A useful scenario is an endpoint that receives a project ID. Explain how the access decision uses trusted identity and the project's ownership or membership rules. An unpredictable ID can reduce guessing, but it does not replace authorization. The OWASP authorization guide covers permission checks and enforcing them consistently.

Go deeper: follow the same resource through list endpoints, exports, background jobs, and caches. Identify where the access context might be lost. If an AI feature can request backend actions, explain where your application checks those actions before executing them.

Choose depth according to the role

Use this as a study progression, then adjust it to the job description and interview format. The labels below are preparation targets, not a universal hiring rubric.

Preparation target	Focus	Evidence of understanding
Junior	Request flow, basic SQL, errors, validation, and access checks	Explain a straightforward operation and its common failure cases
Middle	Concurrent requests, transactions, retries, queues, caching, and diagnosis	Explain how a feature behaves under load and partial failure
Senior	Guarantees across components, capacity, migrations, and operational trade-offs	Define the boundaries of a design and explain how to change or recover it safely

Start with the topics where you can name a solution but cannot explain its mechanism. Those gaps give you a concrete study task.

For example, if your answer to duplicate messages is “idempotency,” go one level deeper: where is the key stored, what prevents a concurrent duplicate, and what happens if processing fails before commit?

Practice explaining one decision completely

Choose a scenario from one topic and give a short answer with four parts:

1. Requirement: what must remain true?
2. Mechanism: what enforces it?
3. Failure case: where can the approach break or need recovery?
4. Evidence: how would you check that it works?

For example:

Each payment event should credit the account at most once. I would claim the event using a unique database key and update the balance in the same transaction. A failure before commit leaves both changes unapplied, so a later delivery can try again. I would check concurrent duplicate deliveries and a failure between the two writes.

Keep the explanation within the question's scope. You do not need to recite every related pattern. If the interviewer adds an external side effect or another database, identify which assumption changed and revise the design.

You can use AI during preparation to propose follow-up questions or challenge an assumption. Try explaining the mechanism yourself first, then verify uncertain claims with documentation or a small experiment. Ask the recruiter separately which tools are permitted during the interview.

Use the backend preparation guide to organize your study schedule. When you are ready to practice answering follow-ups, choose a backend mock interview and work through the areas where your explanations still feel incomplete.