Recruiters skim a stack of look-alike resumes; a link to shipped, evaluated work is what stops the scroll. An AI portfolio is that link, and the big AI employers say some version of the same thing on their careers pages: they hire on demonstrated, shipped work. If you followed this series, the projects already exist. This playbook turns that pile of repos into interviews.

“Talk is cheap. Show me the code.”

Linus Torvalds

Last Updated: July 2026 | Tested on: Python 3.14.6 (standard library only) | Difficulty: Intermediate | Reading Time: 22 minutes

Think of a portfolio like the sample counter at a sweet shop. Nobody buys a full box of kaju katli on your word that it is good; they taste one piece first. Your repos are those samples. A hiring manager does not read your whole codebase, they taste one README, one demo, one eval number, and decide in seconds whether to keep going. So the job is not to build more, it is to plate what you already built so the taste comes through in the first bite. Everything below is about that plating: what to show, how to show it, and how to get it in front of the right people.

What an AI Portfolio Actually Proves

A portfolio is not a collection of tutorials you followed, and it is not a wall of half-finished repos. It is proof of one specific claim: given a fuzzy problem, you can ship something that works, measure whether it works, and defend the result. That is the exact thing an interview is trying to find out, so a good portfolio does the interviewer’s job for them before you ever get on a call. When a company says open-source contributions or a public portfolio are what make a candidate stand out, this is what they mean. They are tired of resumes that list frameworks. They want to see the thing running.

Here is the mindset shift that makes the rest of this post work. Nobody is going to read your code. They are going to scan your presentation of the code, and only dig in if the scan hooks them. So your portfolio is judged on two axes at once: the substance underneath, which you already have, and the packaging on top, which most people skip. Skip the packaging and even great work reads as noise. Get the packaging right and even modest work reads as someone who knows how professionals present their work. The steps below fix the packaging without faking the substance.

The Eight Projects You Already Shipped

If you built along with this series, your AI portfolio already covers most of what an AI or software team screens for. The trick is to see them not as eight tutorials but as evidence of specific competencies, and then check for gaps. Say a candidate named Anvi wants to make sure her portfolio has no obvious hole a recruiter could poke. She lists each project, tags it with what it proves, and runs a coverage check against the competencies teams actually screen for.

📄 portfolio_coverage.py: audit what your projects prove, and find the gaps first

# Audit the projects you already built in this series against the
# competencies hiring teams actually screen for. Find the gaps BEFORE
# a recruiter does. Each project maps to what it proves and to whom.
PROJECTS = {
    "OOP inventory system (186)":        ["clean_code", "testing"],
    "FastAPI service, shipped (204)":     ["ship_api", "clean_code", "deploy"],
    "Sales dashboard (121)":              ["data_analysis", "visualization"],
    "House-price ML system (152)":        ["classical_ml", "evaluation"],
    "Image classifier, deployed (221)":   ["deep_learning", "deploy", "evaluation"],
    "RAG assistant with evals (231)":     ["llm_rag", "evaluation", "ship_api"],
    "Agent with trajectories (237)":      ["agents", "evaluation"],
    "Capstone AI app (182)":              ["llm_rag", "ship_api", "deploy", "evaluation"],
}

# What a generalist AI/software team wants to see at least once.
WANTED = ["clean_code", "testing", "ship_api", "deploy", "data_analysis",
          "visualization", "classical_ml", "deep_learning", "llm_rag",
          "agents", "evaluation"]

covers = {skill: [] for skill in WANTED}
for project, skills in PROJECTS.items():
    for s in skills:
        covers[s].append(project)

print(f"{len(PROJECTS)} projects covering {len(WANTED)} screened competencies\n")
gaps = []
for skill in WANTED:
    hits = covers[skill]
    mark = "OK " if hits else "GAP"
    who = hits[0].split(" (")[0] if hits else "nothing yet"
    print(f"  [{mark}] {skill:<14} <- {len(hits)} project(s), e.g. {who}")
    if not hits:
        gaps.append(skill)

print()
if gaps:
    print("Fill these gaps next:", ", ".join(gaps))
else:
    print("Every screened competency is proven by at least one shipped project.")
    thin = [s for s in WANTED if len(covers[s]) == 1]
    print("Single-project (thin) evidence, worth a second example:", ", ".join(thin))

▶ Output

8 projects covering 11 screened competencies

  [OK ] clean_code     <- 2 project(s), e.g. OOP inventory system
  [OK ] testing        <- 1 project(s), e.g. OOP inventory system
  [OK ] ship_api       <- 3 project(s), e.g. FastAPI service, shipped
  [OK ] deploy         <- 3 project(s), e.g. FastAPI service, shipped
  [OK ] data_analysis  <- 1 project(s), e.g. Sales dashboard
  [OK ] visualization  <- 1 project(s), e.g. Sales dashboard
  [OK ] classical_ml   <- 1 project(s), e.g. House-price ML system
  [OK ] deep_learning  <- 1 project(s), e.g. Image classifier, deployed
  [OK ] llm_rag        <- 2 project(s), e.g. RAG assistant with evals
  [OK ] agents         <- 1 project(s), e.g. Agent with trajectories
  [OK ] evaluation     <- 5 project(s), e.g. House-price ML system

Every screened competency is proven by at least one shipped project.
Single-project (thin) evidence, worth a second example: testing, data_analysis, visualization, classical_ml, deep_learning, agents

What happened here: Anvi's eight projects cover all eleven competencies, so there is no glaring hole. The interesting part is the last line: six of those competencies rest on a single project, which is thin. If a recruiter is hiring specifically for deep learning and your only evidence is one image classifier, a second example makes the signal far stronger. This is the difference between a portfolio that looks accidental and one that looks deliberate. You want at least one clearly polished project per role you are targeting, and this script tells you exactly where a second example would pay off. Notice this runs on your own list, so edit PROJECTS to match what you actually built and re-run it.

The README That Survives a 90-Second Scan

A recruiter or engineer opening a repo from your AI portfolio gives it about ninety seconds before they either keep reading or close the tab. In that window they are not reading code, they are scanning the README for a few specific things. Miss them and it does not matter how good the code is, because nobody scrolled far enough to find out. There are six things that scan looks for: a one-line pitch, the problem you solved, a demo they can see, real evaluation numbers, an architecture picture, and a way to run it themselves. Aviraj wrote a small scanner that scores a README against those six, so he can catch a weak one before he pins it.

📄 readme_scan.py: score your README the way a recruiter skims it

# A recruiter gives your repo a 90-second scan. This scores a README
# against the six things that scan looks for, so you fix the gaps
# before the tab gets closed. Heuristics only, no network, no model.
import re

README = """
# ClauseLens: Explain Any Contract Clause in Plain English

Small businesses sign contracts they do not understand. ClauseLens takes a
clause and returns its topic, a one-line explanation, and a risk flag.

![demo](docs/demo.gif)

## Results
On a 200-clause golden set: 91% topic accuracy, 0.88 macro F1,
median latency 240 ms per clause.

## Architecture
![architecture](docs/architecture.svg)
Clause -> FastAPI -> retrieval over clause bank -> LLM -> structured JSON.

## Run it yourself
git clone https://github.com/aditi/clauselens && cd clauselens
pip install -r requirements.txt
uvicorn app:api --reload
Open http://localhost:8000/docs and paste a clause.
"""

CHECKS = {
    "States the problem":   lambda t: bool(re.search(r"\b(problem|pain|struggle|do not understand|terrified)\b", t, re.I)),
    "Shows a demo":         lambda t: bool(re.search(r"\.(gif|mp4|webm)\b|youtu", t, re.I)),
    "Reports eval numbers": lambda t: bool(re.search(r"\b\d+(\.\d+)?\s?(%|percent|f1|ms|accuracy)", t, re.I)),
    "Has an architecture":  lambda t: bool(re.search(r"architecture|->|diagram", t, re.I)),
    "Run-it-yourself":      lambda t: bool(re.search(r"git clone|pip install|docker run|uvicorn", t, re.I)),
    "One-line pitch up top": lambda t: any(
        len(ln.strip()) > 20 and not ln.strip().startswith(("#", "!", "`"))
        for ln in t.strip().splitlines()[1:4]),
}

score = 0
print("90-second README scan\n")
for label, test in CHECKS.items():
    ok = test(README)
    score += ok
    print(f"  [{'PASS' if ok else 'MISS'}] {label}")

print(f"\nScore: {score}/{len(CHECKS)}")
print("A recruiter keeps reading at 5/6 or 6/6. Below that, the tab closes."
      if score >= 5 else "Fix the MISS lines before you pin this repo.")

▶ Output

90-second README scan

  [PASS] States the problem
  [PASS] Shows a demo
  [PASS] Reports eval numbers
  [PASS] Has an architecture
  [PASS] Run-it-yourself
  [PASS] One-line pitch up top

Score: 6/6
A recruiter keeps reading at 5/6 or 6/6. Below that, the tab closes.

What happened here: The scanner is dumb on purpose, just keyword and pattern checks, but it forces the discipline that matters. The demo line is the one people skip most and it is the most valuable: a ten-second GIF of the thing working beats three paragraphs of prose, because the reader gets to watch it do the job.

The eval numbers line is the second most skipped and the second most valuable, because it is what turns "I built a thing" into "I built a thing and I know how good it is." Paste your own README text into the README variable, run it, and fix every MISS before you pin the repo. A repo that scores 6 out of 6 is one a recruiter finishes reading.

GitHub Profile Hygiene and the Green-Squares Myth

Your GitHub profile page is your storefront window, and most people leave it a mess. The single highest-value thing you can do takes two minutes: pin the three or four repos that best cover the roles you want, so the first thing anyone sees is your strongest work, not whatever you pushed last. An unpinned profile shows your most recent repo first, which is often a throwaway experiment. Pinning is you choosing the first impression instead of leaving it to chance.

Now the myth. A wall of green contribution squares does not get you hired. Recruiters know the streak can be gamed, and nobody offers a job because you committed every day for a year. What the commit history actually does is act as evidence of process, and that is where the git and code-review habits from earlier in this series quietly pay off. A history that shows small, well-named commits, branches with pull requests, and a review conversation reads like someone who has worked on a team. A history that is one giant "final commit" with the whole project dumped in at once reads like someone who has not. Quality of history beats quantity of squares every time.

So the profile checklist is short and boring, which is why it works. Pin three or four repos that map to your target roles. Make sure each one has a short bio line and a clean README. Have at least one repo whose commit history shows real branches and a merged pull request, the kind you practised in the git branching and pull requests and code review posts. That is the whole storefront. It says, without a single word of self-promotion, that you know how software actually gets built.

Multipliers: Kaggle, Open Source, and Writing

Your own projects prove you can build. Three other things prove something your own repos cannot, and they act as multipliers on the same AI portfolio. A Kaggle entry proves you can frame a problem and measure yourself against strangers. An open-source pull request proves you can work inside someone else's codebase, which is most of what a real job is. A short writeup proves you can explain your work, which is what separates an engineer who gets promoted from one who does not. You do not need all three to be impressive, one solid example of each is plenty. Here is a realistic four-week plan a working person can actually finish on evenings and weekends.

Week four is where the resume gets written, and most people write it badly. "Worked on a machine learning project" tells a reader nothing. The fix is STAR framing: Situation, Task, Action, Result, with the result always ending in a number you measured. Aditi feeds her repo facts into a tiny generator that forces every bullet to end in a metric.

📄 star_bullet.py: turn a repo's facts into a resume bullet that ends in a number

# Recruiters skim resumes, not repos. This turns a repo's facts into a
# STAR-framed bullet: Situation, Task, Action, Result, with a number.
# Feed it repo metadata, get a line you can paste under a project heading.
from dataclasses import dataclass

@dataclass
class Repo:
    name: str
    situation: str    # why it existed
    action: str       # what you built, the concrete tech
    metric: str       # the measured result, a NUMBER
    scale: str        # requests, users, rows, docs handled

def star_bullet(r: Repo) -> str:
    return (f"Built {r.name}: {r.action} to {r.situation}, "
            f"reaching {r.metric} across {r.scale}.")

repos = [
    Repo("ClauseLens",
         "help small firms understand contracts",
         "a FastAPI + retrieval + LLM service with a 200-example eval set",
         "91% topic accuracy at 240 ms median latency",
         "1,200 clauses in beta"),
    Repo("house-price-ml",
         "estimate home prices for a listings site",
         "a gradient-boosted regression pipeline with feature logging",
         "mean absolute error under 8% of price",
         "50k historical sales"),
]

print("STAR-framed resume bullets, generated from repo metadata:\n")
for r in repos:
    print("- " + star_bullet(r))

print("\nRule: every bullet ends in a number. 'Worked on ML' says nothing;")
print("'MAE under 8% across 50k sales' says you measured and you shipped.")

▶ Output

STAR-framed resume bullets, generated from repo metadata:

- Built ClauseLens: a FastAPI + retrieval + LLM service with a 200-example eval set to help small firms understand contracts, reaching 91% topic accuracy at 240 ms median latency across 1,200 clauses in beta.
- Built house-price-ml: a gradient-boosted regression pipeline with feature logging to estimate home prices for a listings site, reaching mean absolute error under 8% of price across 50k historical sales.

Rule: every bullet ends in a number. 'Worked on ML' says nothing;
'MAE under 8% across 50k sales' says you measured and you shipped.

What happened here: The generator is trivial, but the structure it enforces is the whole point. Each bullet names the thing you built, the concrete tech, the problem it solved, and a measured result. That last part is what most portfolios never have, because most people never measured their own work. You did, in every project in this series that had a golden set or an eval score, which is exactly why those eval numbers were worth writing down at the time. Fill in your own repos and you have resume bullets a reviewer can believe, because each one points at a public repo where the number can be checked.

The Application Math Nobody Tells You

Here is the uncomfortable number that saves you months of frustration: only a small slice of postings, roughly two and a half percent at the time of writing, are genuinely entry-level. The rest ask for experience you do not have yet. If you fire off two hundred identical applications into that pond, most land on roles that were never going to call you back. The people whose AI portfolio gets interviews are not applying more, they are applying smarter: fewer roles, better fit, and a referral where they can get one. Anvay ran the actual funnel math to see how big that difference is.

📄 application_funnel.py: why fewer, targeted applications beat spraying

# The honest math of a job search. Only a small slice of postings are
# truly entry-level, and referrals convert far better than the front door.
# This compares spray-and-pray vs a targeted, referral-led search.
POSTINGS_SEEN = 400          # roles you could find in a month
ENTRY_LEVEL_SHARE = 0.025    # ~2.5% are genuinely entry-level / junior

entry_level = POSTINGS_SEEN * ENTRY_LEVEL_SHARE

def funnel(name, applied, cold_reply, referral_reply, referral_share, interview_given_reply):
    referred = applied * referral_share
    cold = applied - referred
    replies = cold * cold_reply + referred * referral_reply
    interviews = replies * interview_given_reply
    print(f"{name}")
    print(f"  applications:        {applied:.0f}")
    print(f"  of them referred:    {referred:.0f}  ({referral_share:.0%})")
    print(f"  replies:             {replies:.1f}")
    print(f"  first-round screens: {interviews:.1f}\n")
    return interviews

print(f"{POSTINGS_SEEN} postings seen, ~{ENTRY_LEVEL_SHARE:.1%} truly entry-level "
      f"=> {entry_level:.0f} real targets\n")

# Spray: 200 cold applications, no referrals, low reply rate.
a = funnel("Spray-and-pray (200 cold apps)",
           applied=200, cold_reply=0.03, referral_reply=0.50,
           referral_share=0.0, interview_given_reply=0.6)

# Targeted: 40 well-matched apps, half through a referral.
b = funnel("Targeted + referrals (40 matched apps)",
           applied=40, cold_reply=0.05, referral_reply=0.50,
           referral_share=0.5, interview_given_reply=0.6)

print(f"Targeted got {b:.1f} screens from 40 apps; spray got {a:.1f} from 200.")
print(f"That is {b/a:.1f}x the interviews for {40/200:.0%} of the effort.")
print("Fewer, better-fit applications with a referral beat volume every time.")

▶ Output

400 postings seen, ~2.5% truly entry-level => 10 real targets

Spray-and-pray (200 cold apps)
  applications:        200
  of them referred:    0  (0%)
  replies:             6.0
  first-round screens: 3.6

Targeted + referrals (40 matched apps)
  applications:        40
  of them referred:    20  (50%)
  replies:             11.0
  first-round screens: 6.6

Targeted got 6.6 screens from 40 apps; spray got 3.6 from 200.
That is 1.8x the interviews for 20% of the effort.
Fewer, better-fit applications with a referral beat volume every time.

What happened here: Forty targeted applications with a referral on half of them produced nearly twice the first-round screens of two hundred cold ones, at a fifth of the effort. The lever is the referral: a referred application replies at fifty percent in this model versus three to five percent for a cold one, which is why one warm introduction is worth dozens of blind submissions. These rates are illustrative, so change them to match your own field and market before you trust the exact numbers.

The shape does not change: pick roles you actually fit, get a human to pass your resume in, and stop measuring effort by application count. To pick those roles, it helps to map your projects to the jobs they open.

This series was designed around three tracks, and each project points at real roles. Here is the fit table: nine common entry points, the track that leads there, and the one project that opens the door.

Your Portfolio Playbook, End to End

Put every piece together and it is a loop, not a checklist you finish once. You audit what you have, package it, apply in a targeted way, and if the screens are not coming, you fill the named gap and go around again. The diagram below is the whole method in one picture.

Start at the top. Run the coverage audit on your own project list and pin the three or four repos that best cover the roles you want, with no thin gaps for your target track. Package each one so its README passes the ninety-second scan, and clean up the profile so pinned work and honest commit history greet every visitor. Add the multipliers when you can, one Kaggle entry, one open-source pull request, one short writeup, because each one proves something your solo repos cannot. Translate the repos into STAR bullets that end in numbers, then apply in a targeted way with a referral wherever possible.

Then watch the one signal that matters: are first-round screens coming in? If yes, you are in the interview funnel, and now your job is to defend the eval numbers your portfolio advertised. If no, do not just apply more. The weak signal is telling you something specific, usually that a target role wants evidence your portfolio is thin on. Fill that named gap with one more focused project or a stronger README, re-audit, and go around the loop again. The candidates who land offers are almost never the ones with the most repos. They are the ones who read the loop honestly and fixed the actual gap.

Building the Portfolio Site Itself, Fast

The projects matter far more than the wrapper around them, but you still need somewhere to show them. If your site runs on WordPress, one quick option is AnimFolio, a free plugin I built that spins up a portfolio in about a minute, with 15 ready-made formats to choose from. It handles the layout and animation so your time goes into the projects, not the plumbing.

You can try every format on the live demo. Pick the one that shows your work best, drop in your eight projects and their links, and you have a clean portfolio site the same afternoon you finish this lesson.

Common Mistakes

Best Practices

Frequently Asked Questions

Interview Questions on Building an AI Portfolio

How interviewers actually probe this topic: real scenarios, with answers you can say out loud.

Q: Walk me through one project in your portfolio.

Pick one and tell it as a story with a number at the end: the problem someone had, the smallest slice you built to solve it, one hard decision you made and why, and the eval result you measured. Then say what you would do next with more time. The signal an interviewer wants is that you framed a real problem, made a tradeoff on purpose, and measured whether it worked, rather than that you used a particular framework.

Q: Your portfolio has a Retrieval-Augmented Generation (RAG) project and an agent project. Why should I believe they work?

Because each ships with an evaluation set, not just a demo. Point to the golden set or trajectory evals in the repo, the score the system hit, and the failures the eval surfaced that you then fixed. Anyone can wire up a RAG demo that works on three cherry-picked questions; showing a repeatable eval number is how you prove it works on the ones you did not pick, which is exactly what the eval-focused posts in this series taught you to build.

Q: How do you decide what to build next for your portfolio?

I audit coverage against the roles I am targeting and build only where a gap shows. If every competency a role screens for already has a strong, evaluated project, more repos add noise, not signal. If a target role leans on something my portfolio only touches once, a second focused example there is worth more than a new project in an area I have already covered three times.

Q: You have no industry experience. Why should we interview you?

Because the portfolio is the experience, in miniature and in public. Each project is a fuzzy problem I turned into something shipped and measured, with the commit history to show I work the way a team does: small commits, branches, reviewed pull requests. I cannot claim years on the job, but I can show the exact skills the job needs, running, with numbers you can check. That is a lower-risk bet than a resume of frameworks nobody has seen me use.

Q: What is the difference between a good README and a bad one?

A good README survives a 90-second scan: a one-line pitch, the problem, a demo you can watch, real eval numbers, an architecture picture, and a run-it-yourself block. A bad one buries the point under setup instructions and assumes the reader will dig. The reader will not dig. The whole job of the README is to make the substance visible fast enough that a busy person chooses to keep reading.

What Comes Next

You now have the playbook that turns an AI portfolio into interviews: audit what your projects prove, package each one for a 90-second scan, clean up the profile, add multipliers where they help, translate repos into STAR bullets that end in numbers, and apply in a targeted way with referrals. None of this depends on a particular platform or a hiring trend of the moment. GitHub, Kaggle, and the rest are examples of where the work lives, but the underlying move never changes: make it easy for a busy person to see that you can ship, measure, and defend real work.

This is the last stop in the series, and it is the one that pays off all the others. Every project you built was quietly a portfolio piece; every eval number you wrote down was quietly a resume bullet. Go back through your repos with this post open, package them, and put them where the right people can find them. For the full path from your very first Python program to a portfolio that gets interviews, head back to the Python + AI/ML tutorial series home and pick your track.

Related Tutorials

Further reading: for the full reference, see the official Python documentation.

Related Posts

Previous: AI Project in Python: Building a Complete AI Application

Series Home: Python + AI/ML Tutorial Series