The defence is going well. Then the interviewer names a real weakness — "your test set has 39 positives, so that recall has a wide error bar", "this feature would not exist at prediction time in production", "your eval set has twelve cases" — and you disagree. You explain why it is fine. They push once more, you explain again, more carefully, with more detail. Four minutes go by on one point. The interviewer says "sure, fair enough" and moves on, and the rest of the round feels flat. The feedback says "defensive", "did not take feedback well", or "would need close supervision", and none of those phrases mention the technical point you spent four minutes winning.
Deep-dive project rounds, code reviews, and the first month of any job. It hits strong students hardest, which is the cruel part: a student who knows their project well has a real answer ready for every criticism, and having an answer is exactly what makes them argue. It is also more common when the weakness is one the candidate already knows about, because a prepared rebuttal is sitting right there. The same pattern shows up in team settings later — pull-request comments answered with paragraphs, review meetings that run long — so panels screen for it deliberately. Linked module: 6.6 (Project defence drills).
Two different questions are on the table and the candidate answers the wrong one.
The interviewer's words are about your test set. The interviewer's question is "what is this person like when they are wrong?" That second question is being answered whether you notice it or not, and it carries more weight in the note than any modelling point, because every team already has technical gaps and very few have a cheap way to fix a person who cannot hear one.
Watch the arithmetic of the round. You have perhaps fifteen minutes. Four spent defending one weakness is a quarter of your evidence budget, spent on the topic where you look worst, and spent proving a point that changes nothing about the hiring decision. Even if you win it, you lose: the interviewer now has a disagreement in their notes and three fewer answers to weigh against it.
There is a subtler mechanism too. A criticism named by somebody else is a gift you were supposed to have given yourself. The limits-first habit exists precisely so this moment does not happen: if you had said "the 39 positives make my recall noisy" during your own walkthrough, the interviewer would have agreed with you, and the same fact would have scored instead of costing. Once they have named it first, the fact is no longer neutral — your response to it is the thing being graded.
Note the failure that looks like the opposite and is equally bad: total collapse. "You are right, it is completely broken, I should not have used it." That reads as somebody with no judgement who will fold in front of any confident voice. The target is neither defence nor collapse. It is agreement plus a plan.
Learn one three-part move and use it every time.
The move: agree, price, plan.
Total: about twenty seconds. Compare that with four minutes of argument, and note that the twenty-second version contains more technical content than the argument did.
When you actually disagree. You are allowed to, and sometimes you should — but buy the right first. Agree with the part that is true, then ask a question rather than making a counter-claim: "You are right that it leaks if it is written after the outcome. My understanding is that this field is stamped at application time — is that the case in your systems too?" A question invites them to correct you cheaply. A counter-claim invites them to prove you wrong.
The one-exchange rule. You get one round of clarification on any single point. If the disagreement survives it, close the topic yourself: "Let me note that as something to check rather than spend your time on it — shall I show you the monitoring instead?" Closing a topic on purpose reads as maturity. Being closed by the interviewer does not.
Prevention beats the move. Say your three limits during the walkthrough. Every weakness you name yourself is a weakness that can no longer be used against you.
Write the three biggest weaknesses of every project into your dossier and say them out loud in the walkthrough, before anyone asks. Practise the agree-price-plan sentence on real criticism until the first four words arrive automatically, since this failure is a reflex and only another reflex fixes it. In pair practice, ask your partner to attack one point unfairly on purpose and grade yourself only on your first sentence and the clock: agreement first, twenty seconds total. Record one practice defence and count how many seconds you spent on your worst topic — most people are shocked. Carry the habit into code review after you are hired, because the same twenty-second move ends a pull-request thread that would otherwise take a morning.
Q: "This feature would not be available at prediction time in production, would it?" Strong answer: "You are right, and that is a real leak — it is written after the outcome is known. On my table it was pushing accuracy up by several points, so the honest score is the one without it. The fix is a snapshot rule: every feature must be knowable at the moment of prediction, and I would rebuild the table with a timestamp filter." Weak answer: any sentence that begins with "but" or "actually". The panel is measuring one thing here — what you do with a correction — and the technical content of your reply matters less than the first four words of it.