Resume & portfolio

1 · The 6-second scan & impact bullets essential

Picture the moment your resume actually lives or dies. A recruiter has forty PDFs open and a role to fill by Friday. Yours gets somewhere between six and ten seconds of a human eye before they decide "phone screen" or "next." They are not reading — they are pattern-matching for evidence that you'll do the job. In that window, a resume full of "Responsible for the testing pipeline" and "Worked on backend services" reads as a list of chores someone assigned you. It answers "what were you allowed near?" — not the only question a hiring manager cares about: "what changed because you were there?"

Here's the reframe that fixes almost every weak bullet: a job description is a list of duties, but you are not applying to have duties — you're applying because you produced outcomes. So think of each bullet as a tiny before/after story. Before you: deploys failed one in three. After you: one in twenty. The bullet's whole job is to make that delta visible in one line. The analogy that sticks is a news headline: a headline never says "reporter was assigned to cover the fire" — it says "fire destroyed 40 homes; cause under investigation." Result first, mechanism second. Your bullets are headlines about your own work.

That gives us the shape the scorer below enforces — strong action verb → what you did → measurable impact → how. Each piece earns its place. The verb ("Cut," "Shipped," "Automated") signals ownership; "Responsible for" and "Helped with" are passive hedges that quietly tell the reader you were adjacent to the work, not driving it. The number is the single highest-leverage upgrade you can make: "improved performance" is a claim anyone can type, but "cut p95 latency from 800ms to 210ms" is a claim you can only make if it happened. Numbers convert assertions into evidence, and evidence is what survives the skim. The "how" (the "by adding a CI test gate with pytest" clause) is where your actual skills live — it's the part a technical interviewer will grab onto, so it doubles as bait for the conversation you want.

The common mistake isn't laziness — it's modesty combined with vagueness. Engineers undersell because the metric feels fuzzy ("I don't know it was exactly 30%"). The fix is not to invent a number but to estimate honestly and defensibly: "roughly halved our on-call pages" is fine if you can explain the reasoning when asked. A number you can defend beats a precise number you made up, and both beat no number at all. If you truly can't quantify impact, quantify scope instead — "across 4 microservices," "for a 12-person team," "handling 2M requests/day." Scale is itself a signal.

A recruiter skims; your bullets must show result + how, not duties. Formula: action verb → what → measurable impact → how. "Responsible for testing" is a duty; "Cut prod incidents 30% by adding a CI test gate" is impact.

bullet_score.pyimport re

def score_bullet(bullet):
    score, notes = 0, []
    if re.match(r"^(Built|Led|Cut|Shipped|Designed|Automated|Reduced|Improved|Launched)", bullet):
        score += 1
    else: notes.append("start with a strong action verb")
    if re.search(r"\d", bullet):            # has a number/metric
        score += 1
    else: notes.append("add a measurable result (%, time, count)")
    if re.search(r"\bby\b|using|with", bullet):   # explains HOW
        score += 1
    else: notes.append("say HOW you achieved it")
    return score, notes

for b in ["Responsible for the test suite",
          "Cut deploy failures 30% by adding a CI test gate with pytest"]:
    s, n = score_bullet(b)
    print(f"[{s}/3] {b}")
    for note in n: print("     -", note)

[0/3] Responsible for the test suite
     - start with a strong action verb
     - add a measurable result (%, time, count)
     - say HOW you achieved it
[3/3] Cut deploy failures 30% by adding a CI test gate with pytest

2 · Passing the ATS essential

You wrote a beautiful resume, applied to a role you're clearly qualified for, and heard nothing. No rejection, no screen — silence. It's demoralizing, and the instinct is to assume a person read it and passed. Often, no person ever did. Your resume hit an Applicant Tracking System (ATS) first: software that ingests, parses, and ranks applications so a recruiter can start from a shortlist instead of a mountain. Large companies use one because a single popular role can draw hundreds of applicants; a human simply cannot open them all. So before your content can impress anyone, your resume has to survive being read by a machine that has no judgment and no benefit of the doubt.

The mental model that demystifies this: think of the ATS as a very literal-minded intern with a highlighter and a checklist. It doesn't understand that "K8s" and "Kubernetes" are the same thing, or that your "container orchestration" experience obviously covers the "Kubernetes" the posting wants. It matches tokens — the actual words on the page against the actual words in the job description. That literalness cuts two ways, and understanding both is the whole skill. It means your words must echo the posting's words when the underlying skill is genuinely the same; and it means the machine can be gamed, which is precisely why the honest strategy matters.

The dishonest move — dumping the entire job description into white 1px text at the bottom of the page, or stuffing a keyword salad no human would write — is a trap for two reasons. First, modern ATS platforms flag suspiciously dense keyword repetition, and the score can go down. Second and more important: if the keyword gets you past the filter but you can't back it up, you've just spent a recruiter's time and a bad first impression to reach an interview you'll fail. The goal is not "beat the robot" — it's "make sure the robot doesn't hide a qualified human from the recruiter." Those are different aims, and only the second one survives contact with the actual interview.

So the discipline is mirror, don't manufacture. Read the posting, and where it names a skill you truly have, use its phrasing rather than your favorite synonym: if it says "CI/CD," don't rely on the reader inferring it from "Jenkins pipelines" — say both. The checker below turns this into a concrete gap list: it tells you which must-haves your resume mentions and which it's silent on. Treat the "missing" list as a two-column decision — for each gap, either it's something you genuinely have and forgot to name (add it, easy win), or it's a real skill gap (a signal to learn it, which is exactly what the rest of this course is for). What you never do is add the third option: claim it falsely.

Many resumes are auto-filtered before a human reads them. The ATS matches your resume's terms against the job description. Don't stuff — but do mirror the real skills you have using the words the posting uses.

ats_match.pydef keyword_match(resume, jd, must_haves):
    r = resume.lower()
    present = [k for k in must_haves if k.lower() in r]
    missing = [k for k in must_haves if k.lower() not in r]
    pct = round(100 * len(present) / len(must_haves))
    return pct, present, missing

resume = "Built LLM apps with Python and FastAPI. Wrote pytest suites. Deployed with Docker."
must = ["Python", "Docker", "pytest", "Kubernetes", "CI/CD", "FastAPI"]
pct, have, miss = keyword_match(resume, "", must)
print(f"match: {pct}%")
print("have:", have)
print("missing (add if TRUE for you):", miss)

match: 67%
have: ['Python', 'Docker', 'pytest', 'FastAPI']
missing (add if TRUE for you): ['Kubernetes', 'CI/CD']

3 · Turn course projects into portfolio proof intermediate

A resume makes claims; a portfolio settles them. Every candidate for an AI role writes "built RAG pipelines" on their resume — the words are free, and the interviewer knows it. What separates you from the stack of identical bullets is a link they can click that proves the claim: real code, running, in a repo that looks like an engineer built it and not a student who followed a tutorial once. This is why the portfolio matters more in AI/ML hiring than in almost any other field — the tooling is young, credentials are noisy, and "show me" is the fastest way for a manager to trust you.

Here's the distinction that trips people up: a portfolio is not "the projects you built," it's the projects packaged so a stranger can judge them in three minutes without asking you a single question. The analogy is a restaurant. You can be a brilliant cook, but if a diner walks in to a dark room, no menu, and food that takes an hour with no explanation, they leave. The dish (your code) is necessary but not sufficient — the lighting, the menu, the plating (README, demo, tests, clean history) are what let someone evaluate the dish at all. Most engineers pour 95% of their effort into the code and 5% into the packaging, then wonder why nobody's impressed. The ratio that actually converts is closer to 70/30.

What are the packaging signals a manager scans for? A clear README that answers three questions fast — what problem this solves, why you built it this way, and how to run it in one command — because a manager who can't run it in under five minutes won't try. A live demo or screenshots, because "it works on my machine" is exactly the phrase that ended a thousand projects; a deploy link (even a free-tier one) turns a claim into a fact. And the engineering signals that say "this person ships production code, not homework": tests, a CI badge, and a commit history that reads like incremental work rather than one 4,000-line "final commit." Those last signals are precisely why the DF, TQ, and CD tracks in this course exist — they're not busywork, they're the difference between a repo that reads as amateur and one that reads as hireable.

The common mistake is quantity over legibility: forty half-finished tutorial clones on a GitHub profile actively hurt you, because a manager who sees clutter assumes clutter in your thinking. Three finished, documented, deployed projects beat thirty abandoned ones every time. Your capstones from this course are already at portfolio grade in substance — the work in this section is dragging them up to portfolio grade in presentation, which is the part that's actually seen.

Your capstones here (the doc-intelligence pipeline, RAG platform, tested/deployed app) are portfolio-grade. What makes them count: a clear README (what/why/how-to-run), a live demo or screenshots, and the engineering signals — tests, CI, a clean commit history (all the DF/TQ/CD sections).

4 · Advanced — a portfolio a hiring manager reads advanced

A hiring manager clicks your GitHub, sees 47 public repos, and closes the tab. Not because the work was bad — because they have no idea where to look, and a busy person facing an unsorted pile defaults to "next candidate." This is the failure mode of the eager engineer who thinks more visible work = more impressive. It's the opposite. An unfiltered profile forces the manager to do the curation you should have done for them, and they won't. The skill this section teaches is editing — deciding what the manager sees first, because whatever's on top is your portfolio in practice.

The mechanism GitHub gives you is pinned repositories — up to six slots at the top of your profile that you control. Treat them like the front window of a shop: you don't put your entire inventory in the window, you put the three things that make someone walk in. And the choice of which three isn't random — it should tell a story of range, because a manager isn't just asking "can this person code?" but "what kind of engineer are they, and would they be stuck on my team?" A profile of three near-identical projects answers the first question and fails the second.

The pattern that reads best is depth, breadth, initiative. One project that proves you can go deep — a RAG platform with real retrieval evaluation, not a weekend toy — says "I can own something hard end to end." One that proves breadth — a full app with tests, CI, and a live deploy — says "I understand the whole lifecycle, not just the fun middle part." And one that shows initiative — something you chose to build because it interested you or scratched your own itch — says "I'll bring ideas, not just execute tickets." Together those three sketch a complete engineer; any one alone leaves a doubt the manager has to resolve, and doubts resolve against you.

Each pinned repo then needs its README to lead with impact, the same headline discipline from §1, because the manager reads the README the way they read your resume — top-down, skimming for the payoff. Burying "this cut retrieval latency 60%" in paragraph four is like putting the punchline last in a joke told to someone already reaching for the door. The common mistake here is letting the portfolio grow instead of curating it: every finished project feels worth showing, so the profile bloats over time and the signal drowns. Great portfolios are pruned as deliberately as they're built — the readiness checker below is how you decide which projects have earned a pin.

Managers skim your GitHub like your resume. Pin 3 projects that show range: one that proves depth (the RAG platform), one that proves breadth (an end-to-end app with tests+deploy), one that shows initiative (something you chose). Each with a README that leads with impact.

portfolio_check.pydef portfolio_ready(project):
    checks = {
        "has_readme": project.get("readme", False),
        "has_tests": project.get("tests", False),
        "deployed_or_demo": project.get("demo", False),
        "clear_commits": project.get("clean_history", False),
    }
    ready = sum(checks.values())
    verdict = "portfolio-ready" if ready >= 3 else "needs work"
    return verdict, [k for k, v in checks.items() if not v]

v, gaps = portfolio_ready({"readme": True, "tests": True, "demo": False, "clean_history": True})
print(v, "| improve:", gaps)

portfolio-ready | improve: ['deployed_or_demo']

5 · Professional — tailor per role professional

You've got one polished resume and you're firing it at fifty postings, and the callback rate is quietly killing your motivation. The instinct feels efficient — write once, apply everywhere — but it's the resume equivalent of a cover letter that starts "Dear Sir or Madam." A generic resume is optimized for no role, which means it's slightly wrong for every role. The recruiter for an MLOps position and the recruiter for an applied-research position are scanning for different top-line signals, and the same fixed document can only lead with one of them.

The professional move is not to write fifty resumes — that's unsustainable and you'd burn out by application ten. It's to keep one master resume: a long, comprehensive document with every bullet, project, and metric you've ever earned, far more than fits on a page. The master is your source of truth; you never send it. For each real application you produce a tailored cut from it — a fifteen-minute edit, not a rewrite. Think of it like a photographer's contact sheet versus the three prints they hang: the master holds everything, and each role gets the selection that makes that role's manager lean in.

Three edits do most of the work. First, reorder so the bullets matching the posting's stated priorities sit at the top of each section — the six-second scan lands there, so that's where your most relevant evidence must be. Second, rewrite the summary line to name the role you're applying for and the one or two things that role most values; a summary that says "AI engineer specializing in production RAG systems" for a RAG role beats a generic "software engineer" every time. Third, mirror the must-have keywords the posting uses (the §2 discipline), so both the ATS and the human see their own language reflected back.

The common objection is "fifteen minutes times forty applications is ten hours" — and the answer is that it's the wrong forty. Tailoring forces you to actually read each posting, which means you self-select out of roles that aren't a fit and pour effort into the ten that are. A smaller number of tailored applications reliably out-converts a flood of generic ones, so the tailoring isn't extra work — it's the filter that stops you wasting effort on roles you were never getting anyway.

One generic resume underperforms. Keep a master resume, then tailor a version per role: reorder bullets to match the JD's priorities, adjust the summary, mirror the must-have keywords. 15 minutes per application dramatically lifts callback rates.

6 · Tech-lead — your narrative & brand tech-lead

Here's what surprises engineers the first time they interview for a senior or lead role: the skills-checklist stops working. At junior levels, hiring is largely a competence question — can you code, do you know the stack, can you pass the coding screen. You optimize your resume by adding — more skills, more projects, more keywords. Then you reach the senior tier and the same additive strategy stalls, because the question quietly changed. Nobody doubts you can code by now. What they're trying to figure out is: what are you known for, what's your judgment like, and what happens to a team and a system when you're in the room?

That question can't be answered by a longer skills list — it's answered by a narrative. A narrative is a coherent through-line: "I'm the person who makes flaky ML systems reliable," or "I take research prototypes and get them to production scale." It's not a title and it's not a technology; it's the pattern a manager can summarize in one sentence after meeting you. The analogy is the difference between an actor's résumé and their reputation. A résumé lists roles; a reputation is "the actor you cast when you need X." Senior hiring runs on reputation, and your public footprint is how a stranger perceives that reputation before you've said a word.

This is where the additive instinct actively hurts you. A senior engineer with 47 unfocused repos and a skills section listing every framework they've touched reads as unfocused — the opposite of the clear point of view a lead is supposed to have. The move is subtraction and depth: a focused GitHub that circles one or two themes, a handful of writeups (a blog post, a README deep-dive, a conference talk, a meaningful OSS contribution) that show your thinking, not just your output. One well-argued post about a hard tradeoff you navigated does more for a lead-level candidacy than ten more repos, because it demonstrates the thing the role is actually hiring for: judgment you can articulate.

The common trap at this level is confusing activity with brand — posting constantly, chasing followers, collecting stars. Brand isn't reach; it's legibility of judgment. The senior candidates who stand out aren't the loudest, they're the ones whose small public body of work makes a hiring manager think "this person has a considered point of view about how systems should be built." Everything below — from the way you frame decisions to the artifacts you choose to make public — is in service of making that judgment visible to someone who has thirty minutes and a job to fill.

At senior/lead level, hiring is about a narrative: what you're known for and where you're going. Beyond the resume — a focused GitHub, a few writeups (blog/README deep-dives), talks or OSS contributions. You're not listing skills; you're demonstrating judgment and impact at scale.

# Support Triage Agent

**One line:** classifies incoming support tickets and drafts grounded replies,
escalating low-confidence cases to a human.

**Why it matters:** tier-1 volume was drowning a 4-person team; this deflects
routine questions and routes the rest.

**What I built:** the classifier + confidence gate + RAG answer path + the eval
harness. (Retrieval infra was a shared library.)

**Results:** 38% deflection on a 500-ticket eval set; 0 hallucinated policy claims
(citations enforced); p95 latency 2.1s.

**Run it:** `docker compose up` then open localhost:8000 — seeded demo data included.

**Stack:** Python, FastAPI, Claude API, pgvector.  **Architecture:** see diagram below.

Knowledge check check yourself