The project is genuinely yours. You built it, you debugged it at midnight, and you can explain every design choice. Then the interviewer asks three flat questions in a row — "how many rows?", "what was the baseline?", "what did you compare against?" — and you hear yourself say "around a few hundred, I think", "I do not remember exactly", "I would have to open the notebook". The tone of the round changes after that. Later questions get shorter, the interviewer stops following up, and the feedback says something like "unclear whether the candidate ran this end to end" or "could not substantiate results". You leave confused, because you did run it end to end.
Every project round, every viva, every campus panel, and it is worst four to eight weeks after the project was finished — which is exactly when placement season starts. It bites hardest on students who did the most work, because they made many runs and remember none of them precisely; a student with one run remembers that one. It also shows up in the first weeks of a job, when a manager asks "how big is that table?" and expects an answer in the same breath, not a query. Linked module: 6.6 (Project defence drills).
The interviewer is not testing memory. They are using memory as evidence of ownership, because it is the cheapest reliable test they have.
Numbers about your own project stick differently from facts you read. If you sat through a run that scored 0.824 after a run that scored 0.816, that pair is attached to an evening you remember. If you did not sit through it, the pair is just data, and data slides out of your head in a fortnight. So an interviewer who hears "around a few hundred rows" is not thinking "poor memory". They are thinking "this person may be describing somebody else's work" — and after this course's ruling on AI-written code, that is now the default suspicion for any project that cannot be evidenced.
There is a second, sharper reading available to them. Missing a number is one thing; missing the baseline is another, because a baseline is not a detail. It is the thing that decides whether the project achieved anything at all. A candidate who quotes 0.824 with no comparison beside it has reported a number that cannot be judged, and interviewers hear that as a habit, not an oversight. It is module 1.1's rule failing in public.
The third layer is worse and quieter. When two of your own figures disagree across two documents — a write-up that says the baseline was 0.74 and a repository that says 0.688 — the candidate who cannot explain the difference looks like they invented one of them. In this specific case both are correct, because a do-nothing baseline belongs to the class balance of a table, not to a model: 26 churners in 100 test rows gives 0.74, and 39 in 125 gives 0.688. An owner can say that in one sentence. A borrower has two numbers and no idea.
Finally, note what is not a failure. Not knowing somebody else's benchmark, an industry average, or a paper's result is fine and expected. The rule is narrow: numbers about your own work may not be looked up in the room.
Build a numbers card and drill it to three seconds.
The card, one page per project. Nine lines, no more:
DATA rows, features, split, and the positive rate
BASELINE the do-nothing score, and what it catches (often zero)
METRIC which one, and the business reason it was chosen
MY NUMBER the headline score, plus the count behind the ratio
COMPARED every model you ran, including the losers, with scores
SERVING p50 and p95 latency, error rate (if you served it)
MONITORING what you watch, the alert threshold, the label delay
COST rupees per month, or "zero, runs locally" — say which
ONE CHANGE the single thing you would do next, and why
Always convert ratios into counts. "Recall 0.667" is a number; "it catches 26 of the 39 churners" is a fact somebody can act on. Counts are also far easier to remember, because they are attached to an outcome rather than to a division.
The three-second drill. Hand the card to a classmate, close every file, and have them read the lines back as questions in random order. Anything that takes more than three seconds is not yours yet — write it on a separate list and repeat the drill tomorrow. Ten minutes twice a week keeps a card alive for a whole placement season.
Keep the card current. When you retrain, rerun or reserve the project, update the card the same day, and put the old number in the decision log with a date. A stale card produces the contradiction described in the diagnosis, which is a worse failure than not knowing.
When you genuinely do not know. Say it and give the shape: "I do not have the p95 in my head; it was under 20 milliseconds on one container, and I can show you the log line." Never invent a number in an interview. An invented figure is the one mistake that cannot be recovered when the next question drills into it.
Write the numbers card on the last day of a project, not on the first day of
interview preparation, because that is when the figures are still free. Print the
baseline at the top of every training script's output so it can never be
separated from the score — a score with no comparison beside it is how this
failure starts. Record counts alongside every ratio in your own logs (recall 0.667 — 26 of 39), since counts survive in memory and ratios do not. Keep one
numbers.md per project in the repository itself, so the card and the code move
together and cannot drift apart. Before any interview, run the three-second drill
once on each project you have listed; it takes four minutes and it is the highest
return preparation available in this phase.
Q: "How large was your dataset, and what did the model beat?" Strong answer, with no pause: "500 customers, six features, a stratified 75/25 split, so 125 test rows with 39 churners — a 31% positive rate. Predicting 'stays' for everyone scores 0.688 and catches zero churners. My model reaches 0.824 accuracy and 0.667 recall, so 26 of 39 caught, and I also ran a decision tree at 0.81 and boosting at 0.816." Weak answer: "a few hundred rows, and accuracy was about 82%." The interviewer is not admiring the arithmetic. They are checking that these numbers live in you and not in a document somebody else could have written.