The first line of the resume is the strongest project on the page, and the interviewer opens the round with it. The walkthrough goes well, because it was rehearsed. Then a second-level question arrives — "why chunk by paragraph rather than by fixed length?", "what does this decorator do here?", "what was your retrieval hit rate?" — and the answers turn general: "that is the standard approach", "I would have to check the repo". The interviewer asks for one small change to the code and the candidate cannot find the file that would need to move. The feedback, when it comes, says "could not evidence ownership". In the worst version the offer has already been made and is then withdrawn after a second technical call.
Any deep-dive or project round, and it is now the most common serious failure in fresher hiring. Two routes lead here and both feel innocent at the time. Route one is the tutorial project: a video or blog was followed end to end, the code runs, and the student honestly believes they built it, because they typed every character. Route two is the generated project: a model wrote most of it across a weekend, the student read the output, and it worked first time, which is exactly what removes the learning. The failure is heaviest on ambitious-sounding lines — multi-agent platforms, fine-tuned models, "end-to-end" anything — because those are the lines a panel picks first. Linked module: 6.6 (Project defence drills).
A borrowed project fails at a predictable depth, and the depth is level two.
Level one asks what the system does. A tutorial and a generated project both answer that fine, because the shape of the thing is easy to hold in memory. Level two asks why one option was chosen over another, and that answer never travelled with the code. Nobody writes down the option they rejected while following a tutorial, because they never faced a fork — the tutorial had already walked past it. So the candidate has outputs without decisions, and the interviewer hears "standard approach" three times in four minutes.
The second tell is numbers. Somebody who ran a project has a small mess of figures they cannot forget: the row count, the base rate, the score that disappointed them, the number that moved after one fix. Somebody who watched a project has round numbers or none. An interviewer does not need to prove anything; they simply keep asking until the answers stop containing evidence.
The third tell is the change request, and it is the one that ends the round. Ask for a small modification and an owner navigates: the file, the function, the number that will move. A non-owner navigates the README. This is the check that cannot be prepared around, which is why interviewers reach for it — and it is the same reason this course grades projects by defence rather than by inspecting the code. AI-written code cannot be reliably detected. An owner can always be questioned.
The cost is not one project. Doubt spreads sideways: once line one is not believed, lines two and three are read as decoration, and the panel stops spending questions on them. That is why a withdrawn offer is possible here while a plain "I do not know" almost never causes one.
Two rules and one remedy.
Rule 1 — the ten-minute test. For every line on your resume, ask: can I be questioned about this for ten minutes without repeating myself or reaching for the README? If not, the line comes off. A shorter honest resume outperforms a longer one, because the panel opens exactly one project and judges the page by it. Two projects with dossiers beat six listed ones.
Rule 2 — list what you did, not what the repository contains. If you followed a tutorial and then extended it, say exactly that: "I built this from a tutorial, then changed the chunking and added an eval set of twelve cases, which is the part I can defend." That sentence is safe. Interviewers have no problem with a learning project; they have a problem with a claim that does not survive questions.
The remedy — rebuild it yourself, small. Do not try to memorise a borrowed project. Rebuild a smaller version from an empty folder, with the original closed:
decisions.md: what you chose, what
you rejected, and why. That file is the thing you were missing, and it is what
an interviewer is actually asking for at level two.A rebuilt small project takes a weekend and it can be defended for an hour. The borrowed large one cannot be defended for eight minutes.
On AI assistance, specifically. Using a model to explain an error, to write boilerplate, or to review your code is normal professional work and needs no apology. Using it to produce a project you then present as understood is the failure in this entry. The line is not how much AI touched the code; it is whether you made the decisions and verified the output.
Keep decisions.md from the first day of any project, because the reason for a
choice is only available on the day you make it. Run a ten-minute defence of each
project with a classmate before the resume line is written, not after, and delete
any line that does not survive. Prefer one project you extended and measured over
three you completed. Whenever you accept generated code, do one of two things
immediately: rewrite it in your own structure, or write a comment explaining why
each non-obvious line is there — if you cannot write that comment, you cannot
defend that line either. Before any interview, open your own repository and time
yourself finding four named files; if that takes more than five seconds each, the
project is not yet yours.
Q: "This is a strong project. Walk me through it, and then I would like you to change one thing." Strong answer: a ninety-second walkthrough of problem, approach, result and limit, then — on the change request — say what does not change, name the file and function that do, and say which number will move and in which direction. If part of the work was borrowed or generated, say so before the probing starts and name precisely what you added: "the retrieval loop came from a tutorial; the eval set, the chunk-size comparison and the refusal path are mine." Weak answer: "it is a fairly standard implementation." The interviewer is not hunting for AI. They are checking whether the decisions in that repository were made by the person sitting in front of them.