Backend Engineer Interview Questions — Senior Level

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.

Two questions, and candidates answer the first one and stop. The second is the interview.

Name the service, then be specific about the exposure: which parts only you have debugged, which runbook does not exist, which alert routes to you personally rather than to a rota. Assume there is at least one — the interviewer does — and saying it plainly is not a confession — it is the thing the interviewer is trying to find out whether you can see.

Then spend the rest on what you have done about it. Somebody else took a release. The failure mode you had in your head is now a page in a document with the three things that actually break. The alert goes to the team address. And if the honest answer is that you have not done any of that yet, say what you would do in your first month here, because the question is about a habit, not a service.

The strongest ending available: name something you deleted. A component that no longer needs an owner is worth more than a document about how to own it.

This is not the diagnosis question. Diagnosis is what somebody else in the channel is doing while you do this, and answering it as diagnosis is how a genuinely good engineer fails it.

Start by saying the role out loud in the channel — "I'm running this" — because an incident with three teams and no named commander is three parallel investigations and two duplicated rollbacks. Then: one person on customer impact, so the answer to "how bad is it" is somebody's job rather than everyone's guess. One person per plausible cause, named, so nobody is investigating what someone else is investigating. You do not debug. The commander who starts reading logs has stopped commanding, and it is an easy mistake to make, because debugging is the comfortable thing to do.

Then the two things that separate somebody who has actually run one: timestamps in the channel, in writing, because the post-mortem is only as good as the log somebody kept while it was happening; and a stated interval — "I'll ask for status every ten minutes" — which stops the silence where everyone assumes somebody else has it.

And decide the mitigation on a clock. Roll back, flag off, shed load, cut the expensive feature. If a proposed fix will take longer than the mitigation, mitigate first and say so — the customer needs the service, the write-up needs the cause, and they are not the same deadline.

The tell is whether the answer contains a person's name and a fault attached to it. Blame in a post-mortem is the thing that makes the next one less honest, and an interviewer at this level is listening for whether you know that in practice rather than as a slogan.

Give the shape: what happened, the timeline with real times in it, why it was possible rather than who did it, and what changed. Then say which of the actions actually shipped, and do not round it up. A candidate who says "two of the four; the third is still open and I own it" is more credible than one whose post-mortems all closed cleanly.

If you have never written one, say so and say what you would put in it. Do not invent one; the follow-up asks for a date and a timeline, and there is nowhere to go.

Something gets one when there is a person on the other end who would notice and a decision that would change if it were missed. Everything else is a metric, and calling a metric an objective is how a team ends up with a wall of numbers nobody is accountable for.

Pick the user-facing thing rather than the component: the checkout completing, the message being delivered, the report arriving before the morning. A database's own uptime is not an objective, it is an input to one.

Then the half people skip: what missing it actually does. If the answer is "we talk about it", it is not an objective. The version with teeth is that feature work stops and reliability work starts until you are back inside it — and saying you have been on a team that actually did that, or that you have not and it was theatre, is a better answer than the textbook either way.

Different job, and one that arrives with the title. A pull request review asks whether this is right. A design review asks whether this is the thing, and whether it can be undone.

What to look for, in order: is the problem stated in a way that could be wrong, or has it been written to justify the solution already chosen; what does this make impossible later; what happens at ten times the volume; and what is the smallest version that would tell us we are wrong before we build all of it.

Then the human half, which matters more here than on code: comment on the decision, not on the prose. A document returned with thirty wording notes and no position on the architecture has been reviewed by somebody who did not want to disagree.

Asked about a strong engineer rather than a difficult one, and that is the point of it. The person may be right on the technical merits and expensive anyway, and an interviewer wants to know whether you can hold both of those at once.

Do not start with the process fix. Start with what they are protecting — assume it is something real, and something they have been burned by. An engineer who blocks every schema change may well have restored a database at two in the morning. Naming the fear out loud is the move that changes the conversation, and it is what gets skipped on the way to a policy.

Then make the disagreement cheaper rather than louder: separate blocking comments from opinions and say which is which explicitly, put a time on the escalation — at the fourth reply it becomes a call, and if the call does not settle it, somebody decides and writes down why. And say who that somebody is. A team where nobody can end a technical argument has a much bigger problem than the person in the question.

Say the last resort too, because it is real: if it does not change, this is a management conversation with a named consequence, not another retrospective item. Candidates avoid saying that, and at this level it is what is being checked.

Split when two parts of a system have genuinely different reasons to change, different scaling shapes, or different reliability requirements — and say that the strongest signal is organisational: two teams queuing behind each other's releases.

Refuse when the reason is that the codebase is untidy. A distributed system is a tidy codebase with network calls between the messy parts, and now the failure is partial. Say what you inherit the moment you split: a contract to version, a call that can time out halfway, data that lives in two places and disagrees, and a trace you need before you can debug anything.

The line worth ending on: the boundary you can draw as a module inside one deployment is one you can move next month. Draw it there first and see whether it holds.

Resist the rewrite, and say so in the first sentence, because that is the risk the question is testing for.

Instead: find out what it is for and who depends on it, from the people who call it rather than from the code. Get it running locally and write down every undocumented step as you go, because that list is the most valuable thing you will produce this month. Then find out what actually breaks — read the last six months of alerts and incidents rather than the code, since that is the difference between the system's reputation and its behaviour.

Change one small thing early and ship it. Not for the change; for the proof that you can get something from your machine to production, which is the fact you need before an incident, not during one.

No standard answer, which is why it gets asked, and one very clear bad one: reciting a career ladder to somebody who has written more of them than you have read.

The shape that holds up in this discipline: senior is measured on a system and the people around it — it works, it is understood by more than one person, and the team ships faster because you are there. The step after is measured on problems that belong to nobody: the data model three teams each half-own, the migration that needs somebody to care about it for two quarters, the decision that requires four teams to agree and has no owner with authority over any of them.

Say which one you are and say it plainly. Candidates reach up, and the follow-up asks for an example immediately. "I'm senior, and the thing I have not done is carry a decision across teams where I had no authority" is more hireable than a claim you then have to defend with a story that does not have it in.

One honest addition worth making: much of that work is writing and meetings rather than code, and saying whether you want that is more useful to both sides than saying you are ready for it.

Find out what it is spent on before proposing anything, and say that first — the answer may not be what the team assumes, and an engineer who arrives with an optimisation before a breakdown is guessing expensively.

Then the order worth working through: the things nobody owns — idle environments, forgotten snapshots, a staging cluster the size of production. Then the storage nobody has aged out, especially logs kept forever because nobody set a policy. Then data transfer, which is invisible on an architecture diagram and can be a far larger line than anyone expects. Only then the thing everyone reaches for first, which is instance sizing.

Say the sentence a senior engineer says here: name the number this costs in engineering time, and ask what you should stop doing to fund it. A third off the bill that costs two months of the team's roadmap is a decision somebody above you should make knowingly.

Say the real number, including the waiting. A candidate who says "about three days, and two of them are the release window" has told the interviewer more about their organisation than an hour of architecture talk would, and the willingness to say it is itself the signal.

Name it, say what it costs per month, and say what would make you finally pay it off. A senior engineer with no deliberately-kept debt has either not had to choose or has been fixing things nobody was suffering from.

How is the rota arranged · how do you onboard somebody onto it · what did you change after the worst month. One subject, three angles, and it is asked seriously here because on-call is the part of a senior backend job that people leave over.

Answer with the mechanics rather than the philosophy. How many people are in the rotation — the smaller it is, the more nights each person carries, and that number tells you more than any description of the culture does. Whether there is compensation or time back, and whether the day after a bad night is protected. Who the escalation is, by name, and whether they are actually reachable. And what happens to the rota when somebody is on leave.

The onboarding half is where senior signal lives, and it is simple: nobody carries the pager alone before they have shadowed a rotation and been handed a real page with somebody beside them. Say that you would rather delay somebody's first shift than have them wake at three with a runbook they have never opened.

Then the third: what you changed after the bad month. The answer that lands names a specific alert that was deleted or made actionable, because the culture that fixes alerts is the one where people trust the page. "We talked about it in the retro" is the answer that says nothing changed.