You have told me what the team did. What did you personally do?

Why this follow-up exists

Interviewers ask this constantly, and they ask it because behavioural stories drift into the collective almost automatically. Good engineers describe work the way it happened, and it happened in a team, so the natural pronoun is "we". The problem is that the interviewer is scoring one person and cannot score a group. When the whole story is in the plural, they have no material, so they ask the direct question — and a striking number of otherwise strong candidates then produce a much thinner answer than the story implied.

The question is not an accusation. It is the interviewer trying to give you credit and being unable to work out what to give it for. Understanding that changes how you should hear it: this is an opportunity being handed to you, not a challenge, and the right response is precision rather than defensiveness.

Convert the plural into four kinds of specific

The reliable way to answer is to look for four things in your own account, because they are the four things that belong to an individual rather than to a team.

Decisions you made, especially the ones you could have escalated and did not. Artefacts you produced, which are checkable and therefore convincing: the design document, the migration plan, the load test, the runbook, the schema. Conversations you initiated, which is where most influence actually lives: you went to the platform team, you raised it with the product owner, you got the security review moved earlier. And problems you personally unblocked, which is often the most senior-sounding category because it describes making other people's work possible.

Any of those four, stated plainly, answers the question. "I owned the write path and the migration; the read path and caching were two colleagues; I wrote the cutover plan and ran the cutover on the Saturday" gives the interviewer something to score in one sentence.

The rewrite, line by line

Most candidates already have the material and lose it in the grammar. Compare the two columns and note that the right-hand versions are not larger claims, they are smaller and more definite ones.

What you said	What the interviewer can score
"We decided to shard by customer."	"I proposed sharding by customer; the tech lead pushed for date-based and I argued it through with a query-distribution analysis."
"We got the latency down."	"I profiled it, found the serialisation cost in the response mapper, and rewrote that layer. Someone else did the caching work that got the rest."
"We rolled it out over three months."	"I wrote the rollout plan and ran the first two cohorts myself, then handed the remainder to the team with a runbook."
"We worked with product to cut scope."	"I took a list of what would not fit to the product owner and recommended dropping the export feature. She agreed and told the customer."
"We had a postmortem and fixed the process."	"I wrote the postmortem, and the action I owned was the pre-deploy check on config diffs, which is still in the pipeline."

The right-hand column also does something the left cannot: it makes the boundaries of your work visible, which is what allows the interviewer to believe the parts you do claim.

Overcorrection is the failure nobody warns you about

Told that they must say "I", candidates arrive at the opposite defect and narrate a project in which the six other people are invisible. This is worse than the original problem, and it fails in a specific way. The interviewer asks who else worked on it. The candidate, having already implied ownership of everything, either has to reclaim ground awkwardly or continue the overclaim into detail they cannot support. One question about the part somebody else designed usually settles it, and the whole story becomes suspect rather than just that clause.

The stable position is to give away credit unprompted. Naming the colleague who solved the hardest technical problem, the manager who cleared the political obstacle, or the junior engineer whose observation redirected the work costs you nothing measurable and buys you the interviewer's trust in everything else you say. It also reads as the behaviour of somebody who has worked in a real team, which is, in the end, the trait being hired for.

Watch the calibration too. The contribution you claim has to match the level you are interviewing at. A senior candidate whose entire personal contribution is "I implemented the tickets I was given well" has answered honestly and unfavourably, and should be looking harder for the decisions and conversations that were genuinely theirs. Conversely, an entry-level candidate claiming to have set the architecture of a multi-team programme invites a line of questioning that will not end well.

Preparing so the question never lands hard

The practical fix is to do this work before the interview rather than during it. For each story you intend to use, write down the team's size, your role in it, the two or three decisions that were yours, and the one artefact you would be happy for someone to read. Then say the story aloud once and listen for every "we". Most of them are harmless narration, but the ones sitting in front of a decision are the ones that will cost you, and they are easy to fix in advance.

If you are asked mid-story, do not restart. Answer the narrow question, then offer to continue. And if the honest answer is that a particular decision was not yours, say so and say what you did instead. "That call was my tech lead's. What I did was the analysis he used, and I disagreed with where he landed" is a better answer than a claim, because it contains a fact, a contribution and a judgement all at once.

Interviewers cannot hire a team. Every sentence beginning "we" is a sentence that scores nobody, so name the decision, the artefact or the conversation that was yours — and hand the rest back by name.