Building Your AI Portfolio

You've spent this course building — a RAG assistant, a multi-tool agent, a fine-tuned model — and the last three lessons taught you to talk about that work in interviews. This lesson closes the gap before the interview: making your work visible so that a recruiter, a hiring manager, or a future teammate can see what you can do without you in the room.

Here's the reality of hiring in 2026, and it's good news for you: recruiters ask for links, not resumes. They spend under ten seconds on a resume but engage far more with a GitHub repo that has runnable code or a live demo. A clickable demo earns dramatically more callbacks than code alone; quantified metrics earn several times more than vague descriptions. The market has shifted from "trust my claims" to "show me proof" — and you have proof: three systems you actually shipped.

The catch is that built ≠ visible. A brilliant project in a private repo with a one-line README and no demo is, to a recruiter, invisible. This lesson is about the packaging that turns work you've already done into callbacks:

• The recruiter's 10-second funnel — how your work actually gets scanned, and how to survive it.
• The anatomy of a README that makes a hiring manager keep reading.
• How to write a project bullet — outcome and a number, not a tool list.
• Where to deploy a live demo in an afternoon.
• The 15 mistakes that quietly sink portfolios — and the fix for each.

Why this matters. The difference between the candidate who gets the interview and the one who doesn't is often not skill — it's that one made their work easy to evaluate and the other didn't. Recruiters don't hire potential; they hire proof. Let's make your proof impossible to miss.

Before you optimize anything, understand how your work is actually consumed. It is not read carefully from top to bottom. It is scanned through a funnel, and each stage is a filter that drops most candidates:

resume link → GitHub repo → live demo → callback

• The resume gets ~7–10 seconds. The reader is hunting for a link and a number. No link, or a wall of tool names with no outcomes, and they move on.
• The GitHub repo gets a glance. They look at your pinned repos, the README of the top one, and whether the code looks runnable. A private repo, a dead link, or an empty README ends it here.
• The live demo is the conversion event. A clickable, working demo is the single strongest signal that you can ship — it's worth more than another bullet point.
• The callback goes to whoever made the first three stages effortless.

The lesson from the funnel: optimize for the scan, not the deep read. Your job is to make sure that in the first ten seconds, the reader sees (1) a working link, (2) a clear outcome, and (3) a number. Everything in this lesson serves that goal. You don't need more projects — you need your existing projects to survive the funnel.

The most common portfolio mistake is breadth over depth: ten half-finished tutorial clones, none deployed, none explained. It signals a tinkerer, not an engineer. The rule that hiring managers state over and over:

Two or three polished, deployed projects beat ten unfinished ones. One strong project beats five shallow ones.

You're in an enviable position: you already have exactly the right three. They map to the most in-demand skills in 2026 — retrieval, agents, and model adaptation:

Critically, these are not tutorial projects. You scoped them, made real decisions, hit real trade-offs, and produced real metrics. That's the dividing line: recruiters explicitly screen out "follow-along" projects on toy datasets and screen in self-directed, end-to-end systems. Your three are the second kind — now make each one undeniable with a README, a demo, and the numbers.

The README is the most important file in your portfolio — it's what a hiring manager reads in the GitHub-glance stage, and it's where most projects fail. A great one has a predictable anatomy. Write all eight sections, in this order:

1. Title & one-line overview — what it does, in a sentence a non-expert understands.
2. Problem statement — the real problem you're solving (not "a chatbot," but "answering questions over 10k internal docs without hallucinating").
3. Tech stack — the 3–5 core tools, not every package you touched.
4. Setup — the commands to run it locally. If a reviewer can't run it in two minutes, assume they won't.
5. Architecture diagram — one image of the request flow. A diagram signals system thinking instantly.
6. Key metrics & results — the numbers, with a baseline → after comparison.
7. Technical decisions — why you chose hybrid retrieval over dense-only, a cascade over one model. This is the section that proves judgment.
8. Live demo link — at the top and here. Make it unmissable.
9. Failures & iterations — what didn't work and what you changed. Counterintuitively, this builds trust — it shows a real engineering process, not a lucky first try.

The two highest-leverage sections are Metrics and Technical Decisions — they're what separate "ran a notebook" from "engineered a system." And put the live-demo link and a one-line metric at the very top, because of the funnel: the reader may never scroll. A model-card-style note on data sources and limitations is a nice senior touch.

On your resume, your portfolio site, and the top of each README, every project gets a one-line bullet. This single sentence decides whether the reader clicks. Most candidates write a tool list; you'll write an outcome with a number. The formula:

[Action] → [technical approach] → [quantified result]

And the senior upgrade — a two-layer sentence: plain-language outcome first, technical detail second, so both a recruiter and an engineer get what they need.

Watch the transformation:

• ❌ "Built a RAG chatbot using Python, LangChain, and a vector database." (a tool list — says nothing about impact)
• ✅ "Answers questions over 10k internal docs; adding a reranker lifted context precision 0.74 → 0.89 on a 200-case golden set, and I abstain on low retrieval score to cut hallucinations to ~0. Live demo on HF Spaces."

The strong version does five things, and these are exactly what a recruiter scans for:

1. A quantified number (0.74 → 0.89) — with a baseline, not a number in isolation.
2. The outcome, not the tools — what it does, led from the front.
3. Proof it shipped — "live demo on HF Spaces."
4. Ownership — "I abstain," not a vague "we."
5. No buzzwords — no "leveraged advanced AI techniques."

You have these numbers from the eval lessons — the reranker precision lift, the fine-tune matching a frontier model at ~20× lower cost, the agent's task-success gain. Your bullets aren't marketing; they're measured results. The interactive lets you rewrite each one and watch the five checks turn green.

Anyone can wire together a tutorial. What a hiring manager is really screening for is engineering judgment — and two artifacts demonstrate it faster than anything else: an architecture diagram and a technical-decisions section. These are what move you from "can follow a guide" to "can design a system."

The architecture diagram. One clean image of the request flow — for your RAG assistant: query → embed → hybrid retrieve → rerank → prompt → generate → guardrail. It takes ten minutes in Excalidraw or draw.io and instantly signals system thinking. A reviewer understands your project's shape from the diagram before reading a word of code.

The technical-decisions section (lightweight ADRs — architecture decision records). For each non-obvious choice, write one line: the decision, the alternative, and why — framed as a trade-off. Examples straight from your capstones:

• "Chose hybrid (BM25 + dense) over pure vector because exact product codes matter; it added ~40ms but lifted recall on keyword queries."
• "Cascade routing (cheap model → escalate) over a single frontier model — ~3× cheaper for a negligible quality drop on our eval."
• "Agent writes go through a human-approval gate because the action is irreversible."

This is the same skill as the system-design interview (L16) and the same habit as every lesson: name the trade-off. Writing it down in the repo does double duty — it makes the project legible to a reviewer and it rehearses your interview answers. A project that explains its decisions reads as senior; one that just works reads as lucky.

The live demo is the highest-ROI thing you can add, because it's the funnel's conversion event — and for an LLM app, it's genuinely an afternoon of work. You don't need a custom frontend; a simple Gradio or Streamlit UI over your existing code is enough. Pick by fit:

A few production habits that double as interview talking points:

• Pin requirements.txt to exact versions and test in a fresh environment — "works on my machine" doesn't count.
• Never commit API keys — read them from environment variables / secrets. A leaked key in git history is an instant red flag (and a real security incident).
• Handle errors gracefully in the demo — show what happens on a bad query. Resilience signals production experience.
• Put the demo URL in the repo's "About" field and at the top of the README.

One deployed demo per capstone and you've cleared the single biggest filter in the funnel. For the fine-tuned model, deploying the served endpoint (from L14) is itself the demo — and a strong one.

Once each project is solid, package the whole portfolio so the funnel starts well. Two surfaces matter.

Your GitHub profile is your real homepage as an engineer:

• Pin your 3 capstone repos to the top — this is the first thing a recruiter sees.
• Add a profile README (a repo named after your username) with a one-line role ("AI Engineer — RAG, agents, fine-tuning"), your three projects with their headline metrics, and links.
• Clean commit history and a .gitignore (no __pycache__, no .env). It signals professionalism at a glance.
• A specific bio, not "aspiring data scientist." Specificity reads as competence.

A portfolio site is optional but valued. A simple GitHub Pages or Vercel page with your three projects — each as a card with the screenshot, the one-line bullet, the metric, and Demo / Code links — gives you one URL to put on every application and your LinkedIn. Use STAR framing per project (situation → task → action → result), the same structure as your behavioral stories from L15.

The throughline: a recruiter should be able to go resume → your GitHub → a pinned repo → a live demo without ever hitting friction. Every link works, every README opens with a demo and a number. That frictionless path is the portfolio.

A repo sits still and waits to be found. A writeup travels — and it's the fourth thing every strong project should have (alongside the README, the demo, and the technical-decisions section). A short post about how you built it does three jobs a repo can't:

• It reaches people who'd never browse your GitHub. A LinkedIn post or a blog entry shows up in feeds and search; some of your best opportunities come inbound from a writeup, not from applications.
• It proves you can communicate — the exact skill the behavioral and design rounds test. Explaining a system clearly in writing is a strong signal on its own.
• It's a rehearsal for your interview stories — you're writing the STAR narrative (L15) and the trade-offs (L16) before you ever say them out loud.

Keep it simple and concrete. A good build-story post is 5 short beats: (1) the problem and why it mattered, (2) the approach and architecture, (3) the hardest decision and the trade-off you made, (4) the result with a number, and (5) a link to the demo + repo. Two or three of these — one per capstone — and you have a body of public work that argues for you while you sleep.

You don't need to be a 'content creator.' One honest, specific paragraph about a real problem you solved beats a hundred reposts. Show the work and the number; the writing only has to be clear, not clever.

Most portfolio failures aren't about weak projects — they're about presentation mistakes that are easy to fix once you know them. The big ones, each with its fix:

• Tool lists with no outcome ("used Python, TensorFlow") → lead with impact, tools second.
• No metrics / metrics with no baseline ("improved accuracy") → baseline → after + context ("F1 0.62 → 0.84 on a 2%-positive imbalanced set").
• Dead or private links → test every link in incognito; make repos public; remove links you can't share.
• Buzzwords without substance ("leveraged cutting-edge AI") → concrete technique ("hybrid BM25 + dense retrieval").
• No business/problem context → state the problem first, then the solution.
• Vague "we" on team work → name your specific role and decisions.
• No deployment status → say "deployed on HF Spaces" or "prototype" — be explicit.
• Overly technical, no plain-language → two layers: outcome in plain English first, then the tech.
• Generic, untailored → reorder projects to lead with the most relevant one for each role.
• Overselling accuracy ("99.2%!") → always give the baseline and the class balance.

Notice the pattern: almost every fix is the same move you've practiced all section — replace a vague claim with a specific, measured one. A portfolio is just your trade-off-and-a-number habit, written down. Run the checklist in the interactive and your three projects clear every one of these.

This studio turns the whole lesson into a checklist you can drive against your real projects.

• Three tabs for your three capstones — each shows a live readiness %.
• Check off the README sections you've written and the deploy facts recruiters scan for (public repo, live demo, real problem).
• Rewrite the project bullet in the composer — it's analyzed live against the five recruiter checks (number, outcome-not-tools, shipped, ownership, no buzzwords). A weak bullet is pre-loaded; peek the strong rewrite to see the target.
• Watch the recruiter's 10-second view flip from "keep going" to "would click" as the DEMO/METRICS/REPO badges turn green.
• Drive all three projects toward 100% and clear the what's-missing list.

The point in your hands: you don't need new projects — you need your existing ones to survive the ten-second scan. A complete README, a live demo, and a bullet with a number is the difference between a callback and a pass.

Do these against your own projects — they're the real homework of this lesson.

1. Rewrite this bullet to pass all five recruiter checks: "Made an AI agent that can use tools and leverages advanced LLM techniques."

2. Your RAG repo README currently has only a title and setup steps. Which two sections would you add first, and why?

3. You have 30 minutes before sending an application. What's the single highest-ROI thing to fix?

4. A recruiter clicks your GitHub and sees ten repos, none pinned, mostly tutorial clones. What do you do?

5. Spot the mistakes: "Built a model with 99% accuracy using PyTorch."

Answers.

1. "A multi-tool agent (search + RAG + calculator over MCP) with a step budget and human approval on writes; I raised task success 61% → 88% across a 50-case suite. Deployed API, ~2s p95." — outcome, a baseline→after number, ownership, shipped, zero buzzwords.

2. Metrics & results and Technical decisions — they're the two sections that turn "ran a notebook" into "engineered a system," and they're what a hiring manager looks for to gauge depth. (Then add the live-demo link at the top.)

3. Deploy a demo (or, if one exists, make the repo public and put the demo link + a metric at the top of the README). The live demo is the funnel's conversion event — the highest-ROI single fix.

4. Pin your 3 strongest (the capstones), delete or archive the tutorial clones, and add a profile README with your role and headline metrics. Curate ruthlessly — one strong project beats five shallow ones, and clutter actively hurts.

5. No baseline (99% vs what — a majority-class guess?), no class balance (99% on an imbalanced set can be worthless), no problem/outcome, no deployment, and it's a tool-led sentence. Fix: "Flags fraudulent transactions on a 2%-positive set, lifting F1 from a 0.55 rules baseline to 0.84; deployed as a FastAPI service."

• "More projects = a stronger portfolio." → Depth beats breadth. Three polished, deployed projects beat ten unfinished ones; clutter signals a tinkerer.
• "My code speaks for itself." → To a recruiter scanning for ten seconds, un-deployed, un-explained code is invisible. The README and demo speak; the code is read later, if at all.
• "List every tool I used." → Lead with the outcome and a number; name 3–5 core tools you can discuss deeply. A long tool list reads as shallow.
• "A high accuracy number is impressive." → A number with no baseline or class balance is meaningless. Always show baseline → after + context.
• "A live demo is a nice-to-have." → It's the funnel's conversion event — the single strongest ship signal and the highest-ROI thing to add.
• "Hide the parts that didn't work." → A "failures & iterations" section builds trust — it shows a real engineering process.
• "Tutorial projects count." → Recruiters screen them out. Self-scoped, end-to-end, real-data projects (like your capstones) screen in.
• "The portfolio is separate from the interview." → It's the same habit — replace every vague claim with a specific, measured one. Your portfolio is your trade-off-and-a-number, written down.

• Recruiters open links, not resumes. Optimize for the 10-second funnel: resume link → GitHub repo → live demo → callback. Make every stage frictionless.
• Depth over breadth: your three capstones (RAG, agent, fine-tune) are the right three — they map to the most in-demand 2026 skills. Polish them; don't add toy projects.
• The README is the deliverable: problem → tech stack → setup → architecture diagram → metrics → technical decisions → demo link → failures. Put the demo + a metric at the top.
• Write the bullet as [action] → [approach] → [quantified result], two layers (plain outcome first), with a baseline → after number and ownership — not a tool list.
• Deploy a demo (HF Spaces / Streamlit / Modal) — the highest-ROI single fix; pin requirements, keep secrets in env vars, handle errors.
• Package the profile: pin the 3 repos, add a profile README with your role + metrics, clean commits, an optional STAR-framed portfolio site.
• Avoid the mistakes (tool lists, no baseline, dead links, buzzwords, vague "we," no deployment) — each fix is the same move: a specific, measured claim. Proof beats potential.
• Next — L19 (Your Capstone — Open-Ended Brief): put it all together — scope and build one more project, your way, end to end, and add it to the portfolio you just designed.