skip to content

How do you quote a metric your whole team moved without overstating your own share of it?

level: seniorimportance: should knowfreq 57%

answer

  1. Narrow the claim, keep the number
  2. Never divide a result by headcount
  3. Name the component or decision you owned
  4. Helped and supported are not contributions
  5. Saying who did what makes you credible

basics

~20 s

Keep the team's number whole and narrow the claim around it: state the result, then name the specific piece you built or decided. Splitting a shared figure into a personal fraction invents data; narrowing the claim does not.

solid answer

~40 s

Do not shrink the number — shrink the claim. The bullet keeps the real result and attaches your actual slice: `Team cut worst-case queue-drain time from 41 minutes to 9; I rewrote the batching in 3 of 17 consumers and owned the rollout`. That reads as one honest sentence and it gives a behavioral interviewer exactly what they are calibrating on, which is the scope of the change you personally drove. The two failure modes sit either side of it. Dividing a shared improvement by headcount produces a figure nobody measured. Presenting the whole team's win as yours survives until the drill-down asks who wrote which part. Naming your piece precisely is the only version that gets stronger under questioning.

go deeper

for a junior

Practise saying what you personally built or ran in one sentence, in the first person. Avoid helped with and was involved in, which describe being present rather than contributing.

for a middle

Explain why narrowing the claim beats shrinking the figure, and be able to name your unit of ownership precisely — a component, a rollout, a decision you defended.

for a senior

Show that you can state a team result, name your slice and describe what colleagues owned, without either inflating your share or disappearing into the plural.

for a principal

Own the harder call about which results to lead with at all. A small project you drove end to end often signals more than a share of a large one, and you should be able to argue that choice.

## What the interviewer is actually measuring When a behavioral interviewer hears a large result, the next thing they want is the size of *your* contribution to it, because that is the input to a level decision. A candidate attached to a big result with a small role and a candidate attached to a modest result they drove end to end are different hires, and the number alone does not distinguish them. So the attribution sentence is not a modesty ritual — it is the part of the answer that carries the level signal. ## Shrink the claim, not the number The instinct when a result was collaborative is to reduce the figure so it feels fairer. This is the wrong lever, for two reasons: any fraction you invent is unmeasured, and a smaller number is less memorable while remaining just as hard to defend. The right lever is the claim wrapped around the figure. | Version | Problem | |---|---| | Cut worst-case drain time from 41 minutes to 9 | overclaims silently; collapses when asked who wrote what | | Contributed to a project that improved queue performance | true and worthless; no measure, no scope, no role | | Cut drain time by roughly a quarter of the total improvement | invents a fraction nobody measured | | Team cut drain time from 41 minutes to 9; I rewrote batching in 3 of 17 consumers and owned the rollout | keeps the real result, states a checkable personal slice | ## What counts as your slice Be concrete about the unit of ownership. Useful slices include: a component you wrote, a decision you made and defended, a subsystem you were the reviewer of record for, the rollout or migration you ran, the measurement you set up, or the problem definition itself if you framed it. Weak slices are participation words — helped, was involved in, supported — which describe presence rather than contribution. The framing decision is often the strongest slice available and the one candidates most often skip. Realising that worst-case drain time, not average, was the measure that mattered is a real contribution, and it is easy to evidence because you can explain the reasoning. ## Handling the direct probe Expect a version of *what was your specific contribution to that drop?* Answer it in one sentence, with a mechanism attached, and without hedging: *I rewrote the batching path in three of the seventeen consumers — the ones on the settlement flow — and I ran the staged rollout; another engineer changed the retry policy and a third did the load testing.* Naming what other people did is not self-sabotage. It demonstrates that you know where the boundaries were, and it makes your own claim more believable, not less. ## The failure on the other side Under-claiming is a real cost, not a safe default. Candidates who say we for an entire loop give the interviewer nothing to score, and the notes end up recording an unclear contribution — which in a level discussion tends to be read down rather than up. If you drove something, say so in the first person, and say what driving it consisted of. ## Where a team number still belongs on your resume A collaborative result is legitimate material as long as the sentence makes the shape clear. Keeping the team's figure preserves the stakes; the personal clause supplies the evidence. And if your genuine slice of a very large result is small, that is information too — it may be the wrong bullet to lead with, and a smaller project you owned outright will usually do more for you than a share of a famous one. ## A note on plural pronouns This is about the number, not about grammar policing. Describing the team's work as we is natural and correct. The requirement is that somewhere in the same breath there is a first-person clause stating what you built, decided or ran — so that the shared figure and your slice of it are both on the record.

  • What was your specific contribution to that drop from 41 minutes to 9?
    I rewrote the batching path in three of the seventeen consumers — the ones behind the settlement flow — and I ran the staged rollout across them. A colleague reworked the retry policy on a different set, and someone else built the load harness we validated against. The framing was partly mine too: I argued we should track worst-case drain time rather than the average, because the worst case was what paged people.
  • Why not just divide the improvement between the engineers who worked on it?
    Because that fraction is a number nobody measured, and the moment I quote it I own it. The contributions were not comparable anyway — a batching rewrite and a retry-policy change do not decompose into equal shares. Keeping the team result intact and naming my component gives you something checkable, whereas an invented fraction gives you a figure that falls apart on the first question about how it was derived.
  • Would you still put it on your resume if you had only reviewed the change?
    I would, but written as review ownership rather than authorship — being the reviewer of record for the batching change, including the failure mode I sent it back for. That is a real contribution and it is defensible. What I would not do is leave the sentence ambiguous enough that a reader assumes I wrote it, because that assumption is the one that gets tested.

saying these in an interview costs you the question

  • Divides a shared result by headcount to invent a personal number
  • Presents the whole team's improvement as an individual achievement
  • Says we for an entire answer and never names anything they decided
  • Falls back on helped with or was involved in as the contribution
  • Drops a real number entirely because the work was collaborative

context