📖 Lecture — Telling Your Capstone's Story So It Wins Interviews

You have spent fourteen weeks building a real system: containers, cloud deployment, CI/CD, inference serving, fine-tuning, agents, RAG, security hardening, and cost controls. None of that engineering is visible to a hiring manager unless you package it so they can see it in under two minutes. This week is about that packaging — not decoration, but translation. A portfolio wins interviews through storytelling plus proof, not polish alone. The practical standard to hold yourself to: every project you list should be two clicks away from a reviewer's cursor — one click to a live demo, one click to the repo — backed by a README with a tool list and a one-line story of what you built and why it matters. Show process, not just the finished product. The strongest capstone writeups don't open with "here's my app." They open with the problem, walk through the architecture decisions you actually made (your ADRs from earlier weeks), report the SLOs you hit, and are honest about the trade-offs. A reviewer skimming a README learns more from "I chose async batching over synchronous calls to hit our p95 latency SLO, at the cost of slightly higher worst-case latency" than from a bullet list of frameworks used. This is the difference between a project that reads as a tutorial-follow-along and one that reads as engineering judgment. Make the demo effortless to consume. GitHub does not reliably inline-embed video, so the standard pattern is: record your demo with a free tool (Loom, OBS Studio, or QuickTime on Mac), then embed a linked thumbnail image in your README that opens the video when clicked. For your architecture walkthrough, reuse the Week 3 Mermaid C4 diagrams — Mermaid renders natively in GitHub markdown, so your system-context and container diagrams display with zero extra tooling, no exported PNGs to keep in sync, no broken image links. If your capstone has a compelling CLI or terminal-based workflow, asciinema records the session as a lightweight .cast file that plays back with a real terminal look; convert it to a GIF with agg or terminalizer so it plays directly inline in the README for viewers who won't click through to a video host. Structure matters as much as content. Use this shape as your default README skeleton:

Now, three misconceptions this lecture corrects directly. "Recruiters and hiring managers care most about mathematical elegance." They don't. A portfolio stuffed with proofs, theory, or algorithmic cleverness but silent on outcomes misses what hiring managers actually screen for: business impact. State what got better and by how much — latency, cost, accuracy, reliability — before you state how clever the technique was. "A slide or section title should describe what's in it." A title like "Model results" is wasted real estate. "Cuts false-positive rate by 30% at the same recall" tells the reader the takeaway without them having to read further, and it's the same discipline whether you're titling a slide or a README section. This also means you can never open with a solution to a problem you haven't stated yet — always frame the problem first. "Any dataset and a working repo link are enough to stand out." They aren't. Overused datasets (MNIST, Titanic, generic Kaggle sets) and a bare code link with no narrative make a portfolio blend into hundreds of others. The differentiator is always the wrapper: problem, approach, results, implications — told in your own words, backed by your own SLOs. By the end of this lecture you should be able to look at your own capstone repo and immediately identify what's missing: is the problem stated before the solution? Are your diagrams embedded, not just linked as raw files? Is there a number in your results section? If any answer is no, that's exactly what today's lab fixes.