Backend Engineer Interview Questions

Give the shape in two sentences, then narrow hard. "Order processing for a grocery delivery app — a service that took orders, held stock, and talked to a payment provider and a dispatch system. I owned stock reservation and the reconciliation job that fixed it when the two disagreed."

Then volunteer a number that establishes the scale honestly. Requests per second, rows in the biggest table, orders per day, number of services. If the numbers are small, say the small numbers — an engineer who ran something modest and understood it completely interviews better than one who was adjacent to something large.

Close with the part that was hard, and make it a real engineering problem rather than a deadline. The interviewer is deciding, in this answer, which of the next questions to ask you.

Answer with what you have actually operated, not what you have read about. Then say what you have done with it beyond writing queries: migrations on a live table, reading an execution plan, restoring a backup, changing a connection-pool setting because something fell over.

That second half is the whole answer. Everyone has used a database. Far fewer have had to fix one at speed, and this question exists to find out which you are.

One sentence on leaving, then spend the time on what you want — that half is the useful one and almost nobody uses it. Being specific here filters out roles you'd resent, which is worth more than sounding agreeable.

"I want to own a service end to end rather than one endpoint of it" is a real answer. "New challenges" is not one, and it invites an interviewer to fill in the blank themselves.

Give a range and say what market it's anchored on — local, the client's country, or the currency of the contract. For remote work across borders those are three different numbers, and a figure with no stated basis invites the other side to supply one.

Give status, transferability and a realistic start date in a single pass. A transfer and a new visa are different problems on different timelines, and a hedged answer here is read as postponing bad news rather than as discretion.

If the position is complicated, lead with the complication and follow immediately with the date. Employers plan around dates. They cannot plan around ambiguity, and ambiguity is what loses the slot to someone else.

This looks technical and is often commercial, which is why it sits here. For a government client, a bank, or a customer with data-residency obligations of its own, the region a database runs in can be written into the contract — and an engineer who treats it as a latency question has missed what is being asked.

The answer that lands: find out what the customer's contract requires before choosing anything, name the constraint as a constraint rather than a preference, then talk about what it costs. And if you have never worked under one of these requirements, say so and say how you would find out — that is far stronger than improvising a compliance opinion, which is the easiest way to sound unsafe in a regulated-sector interview.

Asked outright for distributed-team roles in offshore delivery markets, and measured silently almost everywhere else. What is being tested is not fluency; it is whether you can disagree with a design decision in English, in writing, in front of people who don't know you.

Describe the usage rather than a level: written daily in reviews and design documents, spoken in a weekly call with a team in another country. "Advanced" describes nothing and gets tested two minutes later.

Read the plan. Say that first, before anything else, because a lot of candidates start guessing at indexes and the plan is the only thing that turns this from opinion into diagnosis.

Then narrate what you'd look for: whether it's scanning a table it should be seeking into, whether the row estimates are wildly off from actual (which points at stale statistics rather than a missing index), and whether an index that exists is simply not being used — a function wrapped around the column, a type mismatch, or a leading wildcard will each defeat one silently.

The addition that separates a working engineer: say what you'd check about the query and not just the schema. A query that was fine at ten thousand rows and dies at ten million usually asks for something it doesn't need — the full row set to count them, an unbounded result the application then truncates, an N+1 the ORM generated where a join would do. And say what you would not do: add an index in production at peak without knowing what it costs on writes.

Confirm it's being used at all — a composite index is only usable from its leading columns, so an index on (a, b) does nothing for a query that filters on b alone. Then check whether the planner chose it and rejected it, which usually means statistics.

And consider that the query may not be the problem. Lock contention, a connection pool at its limit, or a saturated disk all look exactly like a slow query from the application's side, and distinguishing them is the actual skill here.

The single best question in this whole interview, and the answers separate people sharply. The naive version — read the count, decide, write — has a race in it that no amount of application code closes, and saying so out loud is the first mark.

Then give the options and their costs. Let the database decide: a unique constraint or a conditional update whose row count tells you whether you won. Cheapest, most reliable, and it turns a race into an error you can handle. Pessimistic locking: correct, and it serialises everything behind it, which is how a fast endpoint becomes a slow one under exactly the load you built it for. Optimistic concurrency: a version column, retry on conflict, good when conflicts are rare and bad when they are not.

Then the part people forget: what the user sees. Losing this race is a normal outcome, not an error, and an interviewer notices when a candidate designs the failure message as carefully as the lock. If they push further they'll ask what happens when the seat and the payment live in different systems — that is the next section.

Answer at the level of consequences rather than reciting the acronym. Atomicity means the partial state never becomes visible; durability means a committed write survives the process dying. Isolation is the one that matters in practice and the one nobody checks: the default level on most systems permits anomalies people assume are impossible.

Name the concrete thing: read-modify-write across two statements is not safe just because both are inside a transaction, unless the isolation level or an explicit lock makes it so. Say which level your systems ran at. Most candidates do not know, and knowing is a strong signal.

Expand, migrate, contract — and say it as three deploys, because the reason this is asked is to see whether you think in deploys or in DDL statements.

Expand: add the new column as nullable with no default that rewrites the table, and deploy code that writes to both and reads from the old. Migrate: backfill in batches with a pause between them, watching replication lag rather than wall-clock time. Contract: flip reads to the new column, deploy, then drop the old one in a separate release once you're certain nothing reads it.

The details that show you have done it: adding a `NOT NULL` column with a default can rewrite the whole table and take a lock on some engines and versions; a long-running backfill can hold a transaction open and bloat the log; and the rollback plan matters more than the forward plan, because the release you cannot undo is the one that turns a bad afternoon into an incident. Say too that you would test the migration against a copy of production data — a hundred seeded rows tells you the syntax is right and nothing else.

When a read path is measured as too slow and the join is the measured cause — in that order, and say the order, because denormalising first is how a schema becomes unmaintainable in service of a problem nobody had.

Then name the cost honestly: you now own the consistency yourself, which means every write path that touches the source of truth must update the copy, including the ones written by someone else next year. Saying that out loud is what separates a decision from a habit.

Cache things that are expensive and tolerate being slightly stale, and be explicit about what "slightly" means for that data — seconds for a product listing, never for an account balance.

The interesting half is invalidation. Say which strategy you'd use and what it fails at: time-to-live is simple and serves stale data for exactly as long as you chose; event-based invalidation is precise and breaks silently when a write path forgets to publish. Then mention the failure everyone meets eventually — when the cache empties and every request goes to the database at once.

Have a real answer rather than a preference — a document store where the shape genuinely varies per record, a search index for full text, a time-series store for metrics, a blob store for files that people keep putting in a database. Then say the default is relational and the burden of proof is on moving off it.

By never making a breaking one in a single step — the same expand-and-contract discipline, applied to a contract rather than a table. Add the new field, tell the consumers, give them a deadline that is a real date, and remove the old one only after checking that nothing reads it rather than after being told nothing does.

The sentence that earns trust: you would find out who the consumers are before you start, and "we'll announce it in the channel" is not finding out.

Do not reach for distributed transactions. Say what actually gets built: the operation is made idempotent with a key the caller supplies, so a retry lands on the same result rather than charging twice; state is written before the external call, in a pending state, so there is always a record to reconcile from; and something reconciles afterwards, comparing your records against the provider's and resolving the difference.

The most convincing thing you can add is that reconciliation is a real job that runs on a schedule and has an owner, not a script somebody wrote once. And if you have never worked on payments, the same shape applies to any external call with an effect — sending a message, provisioning an account, dispatching a driver. Say the shape and name the case you actually worked on.

That doing it twice leaves the same state as doing it once, and the practical version is: the caller sends a key, you record it with the result, and a second request with that key returns the stored result instead of doing the work again.

Then say the awkward part, because it's the follow-up: the key has to be stored in the same transaction as the effect, or a crash between the two gives you the double-charge you were preventing. That detail is the whole difference between having read about this and having implemented it.

The bad answer is retries. Retrying a saturated service is how a slow dependency becomes an outage, and it is worth saying that sentence out loud because it is the most common real-world version of this failure.

Build the answer up: a timeout shorter than your own caller's, so you fail before they do rather than holding their connection. Retries with backoff and jitter, capped, and only for operations that are safe to repeat. A circuit breaker so that once it is clearly down you stop asking and fail fast. Bulkheads — a bounded pool per dependency, so one slow thing cannot consume every worker you have.

Then the product question, which is the part that impresses: what does the user get? Degrading to a cached or partial answer is often better than an error, and deciding that is a conversation with whoever owns the product rather than a decision an engineer makes alone at 3am.

When the caller doesn't need the result to continue, when the work is bursty and the consumer should smooth it, or when you need the work to survive the consumer being down. Say those as three separate reasons because they have different consequences.

Then the costs, which get skipped: you have inherited ordering questions, duplicate delivery, a dead-letter queue that somebody has to actually look at, and an end-to-end latency you can no longer see in a single trace. A candidate who names the dead-letter queue has run one.

Additive changes without a version bump, breaking changes with one, and a stated policy for how long the old version lives. The specific mechanism matters far less than having decided one, and saying so is fine.

The realistic addition: most breaking changes are avoidable. Adding an optional field, tolerating unknown fields on the way in, and never repurposing the meaning of an existing one will avoid the majority of version bumps people end up making.

On the server, on every request, checked against the resource being touched rather than against the shape of the route. Then name the failure this exists to prevent: an endpoint that verifies the caller is logged in and never checks that the record they asked for is theirs.

For a multi-tenant system, say how the tenant boundary is enforced — and say whether it is enforced in one place or repeated in every query, because the second is where the eventual leak comes from.

Order of operations, out loud, and the first one is not a hypothesis. Was anything deployed or changed? Deploys, config flags, a migration, a dependency's own release. Most incidents are a change, and starting there resolves a large share of them in two minutes.

Then is it everything or something? One endpoint, one region, one customer, or all of it — that single split halves the search space. Then where in the stack: application, database, dependency, network, or the queue in between; the trace or the four golden signals tell you this faster than reading code.

Then say the thing that distinguishes an engineer who has been on-call: restore service first, diagnose second. Roll back, scale out, shed load, turn off the expensive feature — the post-mortem needs a cause, the customer needs the service. And keep a written timeline while you do it, because nobody remembers the order afterwards.

Fix the alert or fix the cause, and refuse the third option, which is to keep acknowledging it. An alert nobody acts on trains a team to ignore the page that matters.

Say which you'd do and why: if it is not actionable it should be a dashboard, not a page. If it is actionable and keeps happening, the follow-up work goes on the board with a real priority rather than in somebody's head.

Pick one where you were genuinely the cause. The instinct to pick one where you were the hero is visible and it costs you.

Cover four things and no more: what broke, how it was found (and say honestly if a customer found it), what you did in the first ten minutes, and what changed afterwards so the class of failure is smaller. The fourth is the one being scored.

Answer with what you'd actually look at, in order — error rate, latency at the tail rather than the average, saturation, and the one business metric that says whether users are getting what they came for.

The last one is the answer most candidates miss. A service can be green on every technical dashboard while orders have dropped to zero because a partner changed a field, and a team that watches only its own metrics finds out from the customer.

Ask about the policy before the exercise starts, not afterwards. Employer positions vary sharply — no assistance during assessment, assistance in preparation only, or an explicit interest in watching how you use it — and asking is always received better than being found out.

Where it is allowed, what's being measured is your review, not your prompting. Say which part you took as written, which you rejected and why, what you tested about it, and where you went to the documentation because you weren't sure. For backend work name the specific things you always check yourself: anything touching authorisation, anything that writes money, anything with a retry in it.

The failing answers are the two extremes — claiming you write everything unaided in a profession where almost nobody does now, or handing over code you cannot defend line by line. Both are the same failure: claiming ownership you cannot back under one follow-up question.

A better question than the one about a decision you won, and it is asked more often than candidates expect. What's being tested is whether you can be overruled and still do the work well.

Say what you look for in order — does it do what it claims, what happens on the unhappy path, what happens on a retry, and is anything here going to be expensive at ten times the volume. Style comes last and mostly belongs to a linter.

Then the human half: separate the blocking comment from the suggestion, say which is which explicitly, and move to a call at about the fourth reply. Reviewers who mark every comment as blocking are a real cost on a team and interviewers know it.

In time and money and risk, not in nouns. "Two weeks now and it stays fast at ten times the traffic, or three days now and we redo it around March" is the answer; naming the architecture is not.