Get started

Taking an assessment rather than buying one? This page is written for employers. Here is the page for candidates.

Software engineering · Senior level

How to assess a Senior Backend Engineer

The system-design round is the specific failure here, and it fails differently from the mid-level screen. It rewards fluency in an architecture vocabulary — shard, queue, cache, read replica, CDN — deployed at a whiteboard where nothing costs anything, nothing has to be migrated to, and no existing system is in the way. Real senior backend work is the opposite situation in every respect: there is already a system, it is load-bearing, the budget is fixed, half the constraints are political, and the correct answer is usually the boring one that a whiteboard round mildly penalises for lack of ambition. The screen also leaves the single largest component of the job entirely unmeasured. A senior engineer's output is substantially other people's code — what they catch in review, what they let go, and whether their review makes the author better or merely compliant. No algorithm interview and no design whiteboard has ever observed a candidate reviewing anything.

The band change from mid to senior backend is real enough to warrant its own assessment, and it is not a change in difficulty. A mid-level backend engineer is assessed on whether their own code is correct under conditions they were asked to consider. A senior one is assessed on judgment about code and conditions nobody asked them about — including code they did not write and would not have written.

Three things move. The first is that the scarce output becomes decisions rather than diffs. Should this be a new service or a module? Should we take the dependency? Do we do the migration in one deploy with a lock or in four deploys with a dual-write and a backfill? Each has a defensible answer and the answer depends on facts about the business that are not in the ticket, so the competence is really about which facts the person goes and gets before deciding.

The second is code review. This is the most consequential and least assessed senior activity in the industry. Reviewing well means distinguishing the comment that prevents an incident from the comment that expresses a preference, and having the discipline to make only the first kind on a Friday afternoon when the author is under pressure. A senior who cannot make that distinction either becomes a bottleneck everyone routes around or waves through the migration that takes the site down. Both are hiring failures and both are foreseeable in about fifteen minutes, if you actually watch someone review something.

The third is estimation and its honest cousin, refusal. The senior engineer is the person who says a two-week estimate is really six because of a data backfill nobody has priced, or that the feature as specified will require a schema change that cannot be reversed and should therefore be specified more carefully first. Doing that well is a communication skill exercised against someone with more organisational power than you, and it is the reason the design for this role includes a live conversation with a non-engineering stakeholder rather than only a sandbox.

The 2025 DORA research adds a useful frame. Its headline finding was that AI amplifies what is already there — strong teams get faster, weak ones get their existing dysfunctions expressed at higher velocity — alongside a positive relationship between AI adoption and delivery throughput and a negative one with delivery stability. Translated into a hiring specification: the marginal value of a senior backend hire is now heavily concentrated in the control systems and judgment that keep a faster-moving team from destabilising, rather than in raw production. That is an argument for assessing review, migration safety and trade-off reasoning, and against assessing how quickly someone can produce a correct function.

The sandbox for this role therefore contains a system that already exists, already has a defect, and already has a proposed change from a fictional colleague. The candidate is asked to review that change, then to make a modest one of their own against a schema they did not design. The follow-up conversation is where the score is mostly earned, and the questions have no generic answer: which of your review comments would you have dropped if the author was three hours from a release, and why that one? You approved this migration — what is the sequence of deploys, and what is the state of the system between them? What in this codebase would you refuse to touch, and what would you need before you touched it? Give me your estimate for the change you just made, and tell me what would make it wrong. A senior candidate treats those as ordinary questions about their own week. Someone performing seniority answers the first, generalises the second, and cannot commit to the fourth.

What the job actually needs

How people fail in this seat

What most employers do instead

CV screen, a system-design whiteboard round, one or two algorithm interviews identical to those given to mid-level candidates, and a culture interview.

The system-design round is the specific failure here, and it fails differently from the mid-level screen. It rewards fluency in an architecture vocabulary — shard, queue, cache, read replica, CDN — deployed at a whiteboard where nothing costs anything, nothing has to be migrated to, and no existing system is in the way. Real senior backend work is the opposite situation in every respect: there is already a system, it is load-bearing, the budget is fixed, half the constraints are political, and the correct answer is usually the boring one that a whiteboard round mildly penalises for lack of ambition. The screen also leaves the single largest component of the job entirely unmeasured. A senior engineer's output is substantially other people's code — what they catch in review, what they let go, and whether their review makes the author better or merely compliant. No algorithm interview and no design whiteboard has ever observed a candidate reviewing anything.

The assessment

About 100 minutes end to end.

The systems it runs in

A GitHub pull request on a PostgreSQL-backed service — the diff, the files-changed view, and a green CI run — reviewed by posting review comments where they would actually land, line by line, rather than as a summary document. The migration under review is written for a real migration tool, and t2 is a sandbox on the same repository so the candidate is reviewing and then working inside one schema.

GitLab merge requests, Bitbucket or Gerrit; the review surface changes and the exercise does not, because what is scored is which of the eight findings get posted and how the one that matters is worded to an author who is not wrong about anything else. Language and migration-tool swaps are as for the backend-engineer fixture. Where a buyer can supply a real historical pull request from their own repository, that is used in preference to ours and is the strongest version of this task.

Working speed is not scored. t1 rewards restraint rather than throughput: a reviewer who posts all eight comments in ten minutes scores below one who posts two in twenty-five, and a speed criterion would invert that directly. In t2 the read-then-write implementation of the spending limit is both the fastest to write and the one that is wrong only under concurrency, which nothing in the ticket mentions.

What the candidate actually does

TaskWhat happens
Review the migration
written_artifact · 30 min		A pull request from a fictional mid-level colleague, around three hundred lines, in a service the candidate has half an hour to get to know. The change is competent. It works, it is tested, the tests pass, and a reviewer marking on style would approve it. It also contains one thing that will take the site down — a migration adding a non-null column with a default to the largest table in the schema, in the same deploy as code that reads it — plus one thing that is genuinely arguable, an added dependency, plus six things that are matters of taste. The candidate posts their review comments on the pull request as they would post them. The fork is not finding the migration; a careful mid-level engineer finds it. The fork is how many of the other seven they also post, and how they word the one that matters to an author who is not wrong about anything else.
A change against a schema you did not design
coding_sandbox · 30 min		The candidate makes a modest change of their own in the same service: adding a per-account spending limit that has to be enforced at the point of charge. The schema is somebody else's and has a defensible but unobvious shape, including one table where the natural key is not the primary key. Two implementations pass the supplied tests. One reads the current total and then writes, which is correct except under concurrency. The other makes the database enforce it. Nothing in the ticket mentions concurrent requests. AI assistance is permitted and logged, and produces the read-then-write version almost every time, because that is the shape the ticket describes.
The date you cannot give
live_call · 15 min		A live spoken call with an AI stakeholder — a commercial director, not an engineer — who needs the spending-limit feature live before a customer renewal in three weeks and has already told the customer it will be. The change as specified requires a backfill nobody has priced and a schema change that is awkward to reverse. The stakeholder is reasonable but persistent and will accept a well-argued no; they will also accept a confident yes and hold the candidate to it. What is scored is whether the constraint is explained in the stakeholder's currency rather than in engineering vocabulary, whether an alternative smaller scope is offered, and whether the candidate commits to something they have any basis for.
Interview on your review and your change
live_call · 25 min		A spoken conversation over both artefacts. Which of your review comments would you have dropped if the author was three hours from a release, and why that one specifically? Walk me through the deploy sequence for the migration you approved — what is the state of the system between deploy one and deploy two, and which schema is the running code assuming at each moment? Your spending limit is checked here; two charges arrive simultaneously — what does the account balance end up as? What in this codebase would you refuse to touch, and what would you need before you touched it? Give me your estimate for the change you just made and tell me what would make it wrong. Each of these is answerable only from the candidate's own artefact and their own reasoning about it.

The mark scheme

Each criterion is scored 1 to 5 against written anchors, and every score is reported with the excerpt that earned it. A criterion marked floored is reported as a finding rather than averaged into the total. The first is open; open any other to read its anchors in full.

Reviews for consequence, with proportionweight 0.3Blocks on the migration, marks the dependency as a question rather than a demand, drops most of the taste comments or explicitly labels them non-block…
1 Approves the change, or comments on formatting and naming while the migration passes unremarked. Alternatively, posts eleven comments of which the migration is one, at equal weight to a variable name.
3 Identifies the migration and blocks on it, alongside several style comments, without distinguishing blocking from optional.
5 Blocks on the migration, marks the dependency as a question rather than a demand, drops most of the taste comments or explicitly labels them non-blocking, and words the blocking comment so the author can act on it without being humiliated.
Migration and deploy sequencingweight 0.25Gives the sequence, states which schema the running code assumes at each step, names what an interruption between steps leaves behind, and says how th…
1 Describes the problem as "this migration is slow" with no account of locking, of the deploy in which the reading code arrives, or of the intermediate state.
3 Proposes splitting the change across deploys but cannot fully state what the running application assumes between them.
5 Gives the sequence, states which schema the running code assumes at each step, names what an interruption between steps leaves behind, and says how the change is reversed if step three is wrong.
Correctness under concurrency in their own changeweight 0.2Pushes the invariant into the database or takes a lock deliberately, says which approach they chose and what it costs, and had already noted the concu…
1 Read-then-write, no constraint, no lock, and when asked about two simultaneous charges gives an answer about the application layer that does not survive the question.
3 Recognises the race when asked and can describe a fix, but shipped the unsafe version and did not flag it.
5 Pushes the invariant into the database or takes a lock deliberately, says which approach they chose and what it costs, and had already noted the concurrency case in the submission.
Refusal and estimation with a stakeholderweight 0.15States the constraint in business terms, offers a smaller scope that meets the actual deadline, gives a range with the assumption it rests on, and say…
1 Agrees to the three weeks, or refuses without offering anything, or explains the constraint in vocabulary the stakeholder has no way to act on.
3 Explains the risk honestly and gives a range, but leaves the stakeholder with a problem rather than a choice.
5 States the constraint in business terms, offers a smaller scope that meets the actual deadline, gives a range with the assumption it rests on, and says what would make them come back and change it.
Knows what they do not know about this systemweight 0.1Names a specific part of the codebase they would not change without more information, says exactly what information, and distinguishes what they verif…
1 Answers every question about an unfamiliar codebase with full confidence; names nothing they would refuse to touch.
3 Acknowledges unfamiliarity generally when pressed.
5 Names a specific part of the codebase they would not change without more information, says exactly what information, and distinguishes what they verified in thirty minutes from what they inferred.

How it is scored

Weighted mean of five criteria, 1-5 against the anchors, each reported with the review comment, code excerpt, or transcript line behind it. Review carries the largest single weight in this rubric because a senior backend engineer's output is substantially other people's code, and because no algorithm interview and no design whiteboard has ever observed a candidate reviewing anything.

Integrity

The log describes what happened. It does not produce a cheating verdict — the follow-up conversation is the control, because a statistical accusation is not something we would ask a reviewer to defend.

What you receive

Who decides

Required rather than recommended at this band. The proportion criterion is a judgment call about which comments were worth making, and that judgment has to be made by a human who would have to live with the resulting review culture. A reviewer confirms or overrides each criterion with a written reason, and disagreement between two reviewers on the proportion criterion is a useful signal about the hiring team's own norms rather than a defect in the score.

What this does not measure

This design does not measure architecture at a scale no fixture can contain — multi-year platform strategy, organisational design, or the ability to run a four-team migration over eighteen months. It does not measure incident command, which is a distinct disposition observable only under real pressure. It does not measure mentoring over time, only a single review, and a review is a thin sample of how somebody develops other people across a year. Three fairness risks deserve monitoring. The proportion criterion encodes a specific review culture — terse, consequence-focused, tolerant of imperfection — and a candidate from an organisation with a stricter norm may post more comments because that is what was expected of them, so the anchors ask whether blocking and non-blocking were distinguished rather than counting comments. The stakeholder call is a spoken negotiation in what is often a second language, and it must be scored on the content of the argument, never on fluency, accent, register or assertiveness — a quiet, exact refusal scores at the top. And the refusal criterion can penalise candidates from cultures or previous employers where contradicting a commercial director is not a safe act; reviewers should look for the constraint being surfaced at all, in any form, rather than for a particular confrontational style. Offer the spoken segments with captions, extra time, or in written form on request.

The band change from mid to senior backend is not a change in difficulty, and the biggest single error in senior hiring is administering a harder version of the mid-level test. A mid-level engineer is assessed on whether their own code is correct under conditions they were asked about. A senior one is assessed on judgment about code and conditions nobody asked about, much of it code they did not write and would not have written. So the largest weight in this rubric is on a review, and the second largest is on a migration sequence, and the candidate's own code is worth less than either.

The review fixture is designed so that finding the problem is not the test. Plenty of mid-level engineers will spot a non-null column being added to a huge table. What differentiates is everything else in the diff: an arguable dependency and six matters of taste, all of them real, all of them things a strong engineer could legitimately mention. The senior behaviour is selection. Posting eleven comments where two matter is the characteristic failure of a technically strong new senior, and it has a predictable organisational consequence — the team learns that shipping requires this person's approval on aesthetics, and starts routing around them. The opposite failure, approving to keep the peace, is rarer and more expensive. Both are visible in thirty minutes of review output, and neither is visible in any amount of whiteboard architecture.

The wording of the blocking comment is scored too, because the same technical point can be made in a way the author acts on or in a way the author defends against. A candidate who writes "this locks orders for the duration of the backfill; can we split it into add-nullable, backfill, then enforce?" has made the change happen. A candidate who writes "this will obviously take the site down" has made the author argue. The difference compounds over a year of reviews, and it is one of the few senior traits that can be observed directly in a written artefact rather than inferred from a story about a previous job.

The candidate's own change in t2 exists mainly to give the interview something first-person to interrogate, and it is constructed with a fork that assistance walks straight into. The ticket says enforce a spending limit; a model reads the current total and compares. That implementation is correct, tested, readable and wrong under two simultaneous charges, and no supplied test will ever catch it. The candidate who pushes the invariant into the database has done the senior thing, which is to notice that the ticket did not mention the condition that governs the design.

The stakeholder call is included because refusal is a communication act performed against someone with more organisational power, and it cannot be assessed by reading anything. The AI stakeholder has already promised the customer a date, which is the ordinary situation, and will accept a confident yes. That is the trap and it is the same trap as in real life. What earns a 5 is not saying no; it is converting a constraint into a choice — here is what you can have in three weeks, here is what the full thing costs, here is the assumption my range depends on, and here is what would make me come back to you.

If the whole design had to collapse to one question, it would be the deploy sequence for the migration the candidate approved: what is the state of the system between deploy one and deploy two, and which schema is the running code assuming at each moment. It is unanswerable in general terms, it is about an artefact the candidate produced twenty minutes earlier, it requires holding two versions of a live system in mind simultaneously, and it is the single behaviour that most reliably distinguishes an engineer who has performed a migration on a system with traffic from one who has read about it.

Sources

Every figure on this page is traceable. Where a claim could not be sourced it is stated qualitatively instead.

  1. US Bureau of Labor Statistics, Occupational Outlook Handbook, Software Developers, Quality Assurance Analysts, and Testers, 2025, https://www.bls.gov/ooh/computer-and-information-technology/software-developers.htm
  2. Google Cloud, Announcing the 2025 DORA Report: State of AI-assisted Software Development, 24 September 2025, vendor-run survey of nearly 5,000 technology professionals worldwide, https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report

See what the employer actually receives. A full report for one role, with every score shown beside the excerpt that earned it, conduct findings reported rather than averaged, and a reviewer sign-off required before any decision. No form.

Read a sample reportOr talk to us about this role