Prove it

Turn the work into something readable in twelve minutes. Pick the strongest thing you built, usually stage two or three, and write it up as a case: the problem, the constraint, what you tried, what failed, what you changed, what the numbers did. Lead with the failure. Anyone can present a system that works. Showing what broke and how you found out is what separates you, because finding out what broke is the job. Put the numbers in a table, before and after, with a note on what changed. Say what you would do next given another week, and mean it, because you will be asked. Then fix the entry points. Every repository gets a README whose first screen says what it is, what it proved, and how to run it, plus a screenshot or short recording so nobody installs anything to see it work. Cut anything you would not defend in an interview: four strong pieces beat nine weak ones. Last, rewrite your CV against the role brief from stage one, using the language from the postings you collected, and link the artifacts rather than describing them. Then have someone who does not know your work read it all and tell you what they think you do. If their answer is wrong, the writing is wrong, not the reader.

The most common failure here is a quiet one. The work is finished, the write-up is not, and it stays unfinished for months because writing does not feel like it counts. It counts considerably more than the last twenty percent of the code. The way out is to give yourself one sitting and publish something imperfect. The second failure is polishing away every failure until the portfolio reads like a brochure, at which point it says nothing. The failures are the differentiator. Keep them in.