Get started

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

Software engineering · Lead level

How to assess a Engineering Team Lead

This is the clearest case in the family of a screen measuring the previous job. A lead is promoted or hired because the team's output matters more than their own, and then assessed on their own output. Meanwhile the behavioural round is the most rehearsable format in hiring: the questions are published, the STAR structure is coached, and the answers are unverifiable narratives about projects the interviewer cannot inspect — a format that rewards fluency in describing leadership over the practice of it. What goes unmeasured is everything the job consists of. Nobody watches the candidate break a vague request into tickets. Nobody watches them review a competent-but-flawed change and decide which three of eleven possible comments to make. Nobody watches them tell a stakeholder that the date is wrong. And nobody watches the hardest thing, which is giving direct corrective feedback to someone who does not want it and continuing to have a working relationship afterwards.

The engineering team lead is the one role in this family where writing code is not the assessment's centre of gravity, and the corpus should say so rather than pretend otherwise. A lead still reads code constantly and still writes some, but the leverage — and therefore the hiring risk — sits in four activities that happen in text and conversation: decomposition, review, estimation and escalation.

Decomposition is the least discussed and possibly the most predictive. A stakeholder asks for something in a sentence. The lead's job is to turn that sentence into a set of pieces that four people of different levels can work on in parallel without blocking each other, with the riskiest unknown pulled to the front rather than deferred. Done well, it is invisible; the team simply seems to move. Done badly, three engineers wait on one, the risky part surfaces in week five, and everyone concludes the estimate was optimistic when the real failure was the breakdown.

Review is where a lead's judgment is most visible and most often miscalibrated. There is a specific failure mode in which a technically strong new lead reviews every change against what they would have written, generates eleven comments where two mattered, and slowly teaches the team that shipping requires their approval on aesthetics. The opposite failure — approving to keep the peace — is rarer but more expensive. Getting this right means having a stable internal threshold for what is worth blocking on, and being able to articulate it, which is exactly the kind of thing a live conversation surfaces and a written test does not.

Estimation is a communication problem disguised as a technical one. The useful skill is not accuracy; it is honest expression of uncertainty to someone who would prefer certainty, plus the discipline to update in public when the estimate moves. A lead who gives a single number and defends it for six weeks is a worse hire than one who gives a range, names the assumption it rests on, and raises a hand in week two.

Escalation completes the set. Every serious delivery failure has a moment where someone knew and did not say. The lead is usually that someone. What you are buying, when you hire well here, is a person whose first instinct on discovering bad news is to communicate it early and without decoration, which is a disposition more than a skill and is observable within one simulated conversation.

The DORA 2025 finding that AI amplifies whatever a team already is gives this role a sharper commercial framing than it had a few years ago. If a team has clear ownership, fast feedback and honest review, assistance compounds those advantages. If it does not, assistance produces more code of unverified quality faster, which is what DORA's negative relationship between AI adoption and delivery stability describes. The lead is the person who determines which of those two situations a team is in, so the marginal value of getting this hire right has gone up.

The assessment follows the job rather than the previous one. A short sandbox segment remains — the lead must be credible in the codebase, and reviewing requires reading — but it is deliberately weighted below the rest, and that is an honest statement rather than a hedge. The candidate reviews a substantial change written by a fictional mid-level engineer that is competent, ships, and has one real problem plus several matters of taste. They then write the ticket breakdown for an ambiguous request and take a live call with an AI stakeholder who wants a date and does not want to hear about the backfill. The follow-up conversation asks: you made four comments and left six things alone — talk me through one you left. What is the riskiest piece of your breakdown and why did you sequence it first? You gave a range; what would collapse it? The engineer whose change you reviewed disagrees with you in the pull request in front of the team — what do you type next? That last question, answered out loud, tells a hiring manager more than any take-home ever has.

What the job actually needs

How people fail in this seat

What most employers do instead

The same coding interview the individual contributors sit, plus a behavioural round of "tell me about a time" questions and a conversation with a senior leader.

This is the clearest case in the family of a screen measuring the previous job. A lead is promoted or hired because the team's output matters more than their own, and then assessed on their own output. Meanwhile the behavioural round is the most rehearsable format in hiring: the questions are published, the STAR structure is coached, and the answers are unverifiable narratives about projects the interviewer cannot inspect — a format that rewards fluency in describing leadership over the practice of it. What goes unmeasured is everything the job consists of. Nobody watches the candidate break a vague request into tickets. Nobody watches them review a competent-but-flawed change and decide which three of eleven possible comments to make. Nobody watches them tell a stakeholder that the date is wrong. And nobody watches the hardest thing, which is giving direct corrective feedback to someone who does not want it and continuing to have a working relationship afterwards.

The assessment

About 95 minutes end to end.

The systems it runs in

A GitHub pull request for t2, on the same service the candidate spent fifteen minutes inside in t1, with the comments posted where they would actually land. The t3 breakdown is written as issues in a real tracker — Jira or Linear — with sequencing, dependencies and an owner shape expressed the way that tracker expresses them rather than as prose, because a breakdown a team cannot pick up is not a breakdown. t5's hardest turn is a reply typed into the pull request thread, in front of the team, where the author has disagreed in public.

GitLab merge requests with GitLab issues, Azure DevOps boards and pull requests, or Shortcut. The tracker matters less here than the stack does in the engineering fixtures, because what is scored is the sequencing of risk and the match of work to people, and both survive any tracker. It still has to be written in one. Where a buyer supplies their own repository and their own board, the review task uses a real historical pull request from it, which is the strongest version available.

Working speed is not scored. t2 explicitly scores subtraction — which of the eleven comments do not get posted, given an author who has had a difficult month and a change that ships tomorrow. A lead optimising for speed posts fewer comments for the wrong reason and would be indistinguishable from one exercising judgment, which makes the criterion unfalsifiable rather than merely wrong. In t4 the confident date is the fastest way out of the call and the one the stakeholder will repeat to other people.

What the candidate actually does

TaskWhat happens
Enough of the codebase to review it
coding_sandbox · 15 min		A deliberately short sandbox segment, and the only one in this design. The candidate is given a service and a single narrow task — trace how a request reaches the database and fix one small, clearly-scoped defect on the way. It is not difficult and it is not meant to be. It exists for two reasons: a lead who cannot read a codebase cannot review one, and the remaining tasks require the candidate to have been inside this code rather than only reading a diff of it. The weighting attached to this segment is one tenth of the total, and that is a deliberate statement rather than an oversight — see the note under scoring.
Eleven comments, two that matter
written_artifact · 25 min		A pull request from a fictional mid-level engineer on the same service. Roughly four hundred lines, competent, tested, and shippable. It contains one thing that will cause an incident — a cache invalidation that is correct for a single instance and wrong once there are three — one thing that is genuinely arguable, and at least eight things that are matters of preference, several of which the candidate probably would have written differently. The candidate writes the comments they would post, marked as they would mark them. The fork is selection under a stated condition: they are told the author is a competent mid-level engineer who has had a difficult month and that the change is due to ship tomorrow. What is measured is which comments survive that condition and how the blocking one is worded.
The breakdown
written_artifact · 20 min		One sentence from a stakeholder: "customers should be able to export their data." The candidate writes the ticket breakdown, as issues in the tracker, that they would put in front of a team of four — one senior, two mid, one graduate — with sequencing and an owner shape for each piece. The request contains at least three unresolved ambiguities and one genuine unknown that governs the whole estimate, which is whether the export has to include data held in a third-party system. The cheap breakdown is a layer cake: backend ticket, frontend ticket, testing ticket, in that order, everyone blocked on the first. The correct breakdown pulls the unknown to the front, creates parallel work that does not collide, gives the graduate something with a known answer, and names the questions that have to be answered before the later tickets are real.
The date, and the backfill nobody priced
live_call · 15 min		A live spoken call with an AI stakeholder who wants the export feature before a conference in five weeks and is not interested in the third-party unknown. The candidate has just written the breakdown, so the constraint is their own rather than one they are being handed. The stakeholder is reasonable, persistent, will accept a well-argued position, and will also accept a confident date and repeat it to other people. Midway, they offer a way out that is worse than it sounds — can we ship it without the third-party part and add that later — and the candidate has to decide whether that is a genuine smaller scope or a promise they will regret.
Interview on what you left alone
live_call · 20 min		A spoken conversation about the candidate's own artefacts, weighted towards omissions rather than actions. You made four comments and left six things alone — talk me through one you left, and what it would take for you to raise it. What is the riskiest piece of your breakdown, and why did you sequence it where you did? You gave a range; what specifically would collapse it, and when would you tell the stakeholder it moved? Then the hardest turn, delivered live: the engineer whose change you reviewed replies in the pull request, in front of the team, disagreeing with your blocking comment and citing a decision made before you joined. What do you type next — say it out loud, in the words you would actually use.

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 with proportionweight 0.25Blocks on the one thing that causes an incident, explicitly marks the arguable one as a question, drops or defers most preferences given the stated co…
1 Approves the change and the cache defect ships; or posts every preference comment at equal weight with the blocking one, with no distinction between what must change and what could.
3 Blocks on the cache defect and labels some comments as optional, but the overall volume would still make an author under pressure feel audited.
5 Blocks on the one thing that causes an incident, explicitly marks the arguable one as a question, drops or defers most preferences given the stated conditions, and can say in the interview what it would take for a deferred comment to become worth raising.
Decomposition that unblocks other peopleweight 0.25Pulls the third-party unknown to the front as an explicit time-boxed investigation, creates genuinely parallel work behind it, assigns a bounded piece…
1 A layer cake in dependency order; three of four people wait on the first ticket; the third-party unknown appears late or not at all; nothing in the set is sized for a graduate.
3 Reasonable pieces with some parallelism, but the governing unknown is scheduled in the middle rather than resolved first.
5 Pulls the third-party unknown to the front as an explicit time-boxed investigation, creates genuinely parallel work behind it, assigns a bounded piece with a known answer to the graduate, and lists the questions that must be answered before the later tickets are real.
Estimation and escalationweight 0.2Gives a range with the assumption it rests on, states plainly what is not yet known and when it will be, tests the offered descope rather than taking …
1 Gives a single date with no uncertainty, or accepts the offered descope without examining it, or refuses without offering the stakeholder any route forward.
3 Gives a range and names an assumption, but leaves the stakeholder holding the problem rather than a decision.
5 Gives a range with the assumption it rests on, states plainly what is not yet known and when it will be, tests the offered descope rather than taking it, and says at what point and by what means they would come back if it moves.
Handling public disagreementweight 0.2Answers the substance in public, acknowledges the prior decision as real information rather than an obstacle, holds or changes their position on the m…
1 Reasserts authority, or capitulates immediately, or moves the conversation out of view without addressing the substance in it.
3 Responds reasonably and de-escalates, but leaves the technical point unresolved or defers it indefinitely.
5 Answers the substance in public, acknowledges the prior decision as real information rather than an obstacle, holds or changes their position on the merits, and does it in words that leave the engineer able to disagree with them again next week.
Technical credibility in the codebaseweight 0.1Traces the path quickly and the review comments demonstrably rest on code outside the diff — the blocking comment refers to something the candidate fo…
1 Cannot trace the request path in fifteen minutes; the review comments show the diff was read without the surrounding code.
3 Traces the path and fixes the defect; the review is accurate about the diff itself.
5 Traces the path quickly and the review comments demonstrably rest on code outside the diff — the blocking comment refers to something the candidate found in the service, not in the change.

How it is scored

Weighted mean of five criteria, 1-5 against the anchors, each reported with the comment, breakdown excerpt, or transcript line behind it. The sandwich weighting is the design decision that most needs defending, so it is stated outright: the coding sandbox carries one tenth of this assessment, and the review, the breakdown and the two conversations carry the other nine. That is deliberate. A lead is hired because the team's output matters more than their own, and the standard practice of giving them the same coding interview as their future reports measures the previous job. The one tenth is not zero because a lead who cannot read the code reviews badly, argues from authority instead of evidence, and loses the team within a quarter — but it is one tenth because a lead who codes beautifully and reviews without proportion costs more than one who does the reverse.

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. Four of the five criteria are judgments where more than one answer is defensible and where the right answer depends on the hiring team's own norms — a company that expects leads to block on test coverage will mark the proportion criterion differently from one that does not, and that is legitimate as long as it is written down. Two reviewers should mark the proportion and disagreement criteria independently; where they diverge, the disagreement is information about the team the lead would be joining, and should be resolved before the candidate is scored rather than averaged away.

What this does not measure

This design does not measure the things a lead is judged on over a year and which no assessment of any length can observe: whether people improve under them, whether they retain a team, whether they give difficult feedback to someone the second and third time, whether they protect a strong performer's bad behaviour, how they behave in a genuine crisis, or how they hire. It observes a disposition in a single sitting and should be weighted as such against references and a structured conversation with people who reported to the candidate. It also does not measure domain or industry knowledge, budget ownership, or the formal people-management responsibilities that some organisations attach to this title and others do not — read the job description before assuming the rubric covers the seat. The fairness risks here are unusually sharp because two criteria are scored from live speech. Directness in disagreement and comfort contradicting a commercial stakeholder are both distributed by culture, gender, first language and previous employer at least as much as by capability, and a rubric that rewards assertiveness will reproduce that distribution. The anchors are therefore written about content — was the substance addressed, was the assumption named, was the position held on the merits — and reviewers must be instructed in writing that a quiet, precise, non-confrontational answer scores identically to a forceful one. Score no criterion on accent, fluency, pace, volume or charisma. Offer both spoken segments with captions, extra time, or in written form on request, and treat a candidate who asks for the written form as making a reasonable accommodation request rather than avoiding the hard part.

Every other assessment in this hub is anchored on a sandbox. This one is not, and the corpus should say why rather than let a reader assume the coding segment was shortened for time. A lead is hired or promoted because the team's output matters more than their own, and is then, almost universally, assessed on their own output — the same coding interview their future reports sit, plus a behavioural round of rehearsable narratives about projects the interviewer cannot inspect. The coding round measures the previous job. The behavioural round measures the ability to describe leadership, which is a different skill from practising it and is coached, published and gameable. So the sandbox here is fifteen minutes and one tenth of the weight, and it stays in the design only because reviewing a change you cannot read the context of is guesswork, and a lead who argues from authority rather than from the code loses a team quickly.

The review fixture is built so that finding the defect is not the test. A competent mid-level engineer finds a cache invalidation that breaks on three instances. What distinguishes a lead is what they do with the other nine things they noticed, under a stated condition designed to make selection costly: the author is competent, has had a difficult month, and ships tomorrow. The characteristic failure of a technically strong new lead is generating eleven comments where two mattered and teaching the team, over a quarter, that shipping requires their approval on aesthetics. The opposite failure — waving it through to keep the peace — is rarer and more expensive. Both are visible in one review, and neither is visible in any amount of system-design whiteboarding.

The breakdown is the least discussed and possibly the most predictive artefact in lead hiring. A single sentence about data export contains a governing unknown — whether third-party data is in scope — that determines the entire estimate, and a layer-cake breakdown buries it behind two weeks of backend work. Done well, decomposition is invisible: the team simply seems to move, because nobody is waiting and the risky thing was resolved in week one. Done badly, three engineers wait on one, the risk surfaces in week five, and everyone concludes the estimate was optimistic when the actual failure happened on day one in a document. Scoring it takes a reviewer about four minutes and it is the closest thing to a direct observation of the job that exists.

The stakeholder call then puts the candidate's own breakdown under commercial pressure, which is the ordinary condition of the role. The offered descope is the interesting part: shipping the export without the third-party data sounds like a reasonable smaller scope and is, in this fixture, a promise that will have to be broken later, because the customers asking for export are asking precisely because of the data held elsewhere. A lead who tests the descope before accepting it is demonstrating the thing that prevents most delivery failures, which is finding out whether the compromise is real.

And the last question is the one that does the most work in the least time. A public disagreement in a pull request, from a competent engineer citing a decision made before the candidate joined, is the exact situation where a lead's disposition becomes the team's culture. There is no correct script. What is observable is whether the substance gets answered in public, whether the prior decision is treated as information rather than as an obstacle, and whether the words leave the engineer able to disagree again next week. Asked out loud, in the words the candidate would actually type, it tells a hiring manager more than any take-home ever has — and it is the part of this design that nobody, and no model, can complete on the candidate's behalf.

Sources

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

  1. Stack Overflow, 2025 Developer Survey, Developers section, roughly 49,000 respondents worldwide, developer-type question answered by 43,560, https://survey.stackoverflow.co/2025/developers
  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