The interviewer picks a line from your resume — often not the one you rehearsed — and says "walk me through this one". Three minutes in you are describing what the project did rather than what you did. Asked why a particular model, dataset or threshold was chosen, you answer "that is what the tutorial used" or "my teammate handled that part". Asked what broke, you cannot name a single failure. The interviewer stops asking about that project and starts asking shorter questions about the others, and the round ends early. Feedback, when it comes, says "unable to explain own work".
Any round where a resume is open, which is nearly all of them. It bites hardest on projects copied from a tutorial or a YouTube series, on group projects where one person wrote the model code, and on the third and fourth bullet points that were added to make the page look full. The damage is not confined to that project: it spreads to every other claim on the page, including the true ones. Linked module: 6.4 (ML theory viva bank), 6.6 (Project defence drills).
A resume line is a claim, and an interview is where claims are tested. This programme treats project defence as the integrity layer for exactly that reason: code can be generated, tutorials can be followed, and a repository proves very little on its own — but nobody can defend, in real time, work they did not do.
The interviewer is not trying to catch you. She is doing the cheapest possible verification, and it works because the questions that expose an undefended project are not hard questions. They are ownership questions, and there are only four kinds:
The spread is the expensive part. Once one project has failed these four questions, the interviewer has no way to tell which of your other claims are real, so she discounts all of them. A student with one strong project and three padding bullets often scores below a student with one strong project alone.
Group projects create an honest version of this problem. If a teammate wrote the model code, you cannot defend it — and the fix is not to pretend, but to say what you owned and defend that part completely.
Apply one rule to your resume and one drill to every line that survives it.
The rule: never list what you cannot defend for ten minutes. Not summarise for ten minutes — defend. Questions, follow-ups, and the four ownership questions above. If a line cannot survive that, you have two options and no third: do the work until it can, or delete the line. Deleting is not a loss. A one-project resume you can defend outscores a four-project resume you cannot.
The ten-minute defence drill, run once per line, with a partner and a timer:
For group work, state the boundary before you are asked. "I owned the feature pipeline and the evaluation; my teammate wrote the serving layer, so I can describe its design but I did not build it." This is a strong sentence, not a weak one. It is the WR-158 protocol applied to your own resume, and it turns a trap into a demonstration of honesty.
Rebuild what you want to keep. If a tutorial project matters to you, redo it on a different dataset with your own decisions, break it on purpose, fix it, and write down what happened. That version is defensible, and the second build takes a fraction of the first.
Write the defence before you write the resume line: if you cannot draft the four ownership answers, the line is not ready. Keep a build log per project with the decisions you made and the reasons, because reasons evaporate within weeks and the log is what you will revise from. Deliberately break your own project once and fix it, so that "what broke?" has a real answer with a mechanism behind it. Name your ownership boundary in group work on the page itself, in the words you would use out loud. Run the ten-minute drill on every line before you send the resume anywhere — the drill costs an hour for a whole page and it is the only check that matches how the round actually works.
Q: "Walk me through this project, and tell me why you chose that model." Strong answer: two sentences of context, then the decision with the reason you had at the time, your measured number beside the baseline it beat, one failure you hit with how you diagnosed it, and one honest limit. Weak answer: a description of what the project does with no decisions and no failures in it. If an interviewer ever hears "nothing really went wrong", she stops believing the project happened — so bring your failures to the interview on purpose.