Present Your Evidence

A strong engineer nobody can find doesn't get interviews. And a findable engineer nobody can evaluate doesn't get callbacks. This lesson is about closing both gaps: making yourself discoverable — recruiters can find you — and demonstrable — when they find you, they can see the work in under three minutes.

The minimum concept: the evidence funnel

Think of the hiring pipeline as a funnel with four gates. At each gate, a different artifact does the work, and each gate filters out candidates before the next one is even considered:

Notice the asymmetry. The interview is the last gate — you only reach it if the first three did their job. Most candidates pour all their effort into interview prep and treat the first three gates as paperwork. That's backwards: the funnel is where interviews come from.

The funnel also tells you what "good" means at each gate:

Three artifacts. Three gates. This lesson rebuilds all three: your LinkedIn profile (the search gate), your GitHub profile (the evidence gate), and your 2-minute demo video (the "oh, this is real" gate). Each section follows the same arc: look at the weak version honestly, learn the minimum concept, build the strong version, and make it reusable.

1. LinkedIn: the search gate

LinkedIn is not a resume. A resume is a document someone reads when they've already decided you're interesting. LinkedIn is a search index — recruiters query it the way they'd query Google, and the profiles that surface are the ones that match the query's vocabulary.

This is the part most candidates get wrong. They optimize for impressing humans and forget they're being found by search first.

Headline: Software Engineer @ AcmeCorp
About: Results-driven software engineer with a passion for
building scalable solutions and leveraging cutting-edge
technologies. Proven track record of delivering high-quality
software in agile environments. Team player. Quick learner.

Featured: (empty)
Experience: Software Engineer, AcmeCorp — 2023–present
  "Responsible for developing and maintaining backend services."
Skills: Java, Python, SQL, Problem Solving, Teamwork

The headline rewrite formula

Your headline is the single most valuable piece of text in your job search. It's what appears in search results, what recruiters see before they click, and what LinkedIn's search algorithm weights heavily. The formula:

Before and after — same engineer, same skills, one headline that hides and one that finds. (Composites, as always.)

A few rules of thumb that keep headlines honest:

• Name the role you want, not just the role you have. If you're targeting FDE roles, say "Forward-Deployed Engineer" — not "Software Engineer" hoping they'll guess. (Assuming you can back it up with work — your CityOps milestones are the backup.)
• Proof beats adjectives. "Passionate about AI" is an adjective. "Shipped Ask CityOps RAG pilot with evals" is proof. One checkable claim outweighs a paragraph of adjectives.
• Keywords are for search, not for people. The parenthetical keyword list at the end isn't poetry — it's SEO. Use the vocabulary from the job postings you're targeting: LLM APIs, vector search, structured output, evals, RAG, FastAPI, Docker, CI/CD. If a recruiter searches "RAG evals" and your headline doesn't contain either word, you don't exist for that search.
• One artifact is enough. Don't list every project. The single strongest, most relevant project is the hook; the rest lives in Featured and GitHub.

The About section: a 3-sentence pitch

Most About sections are where good profiles go to die — five paragraphs of buzzwords nobody finishes. The fix is a constraint: three sentences. A recruiter who has given you ten seconds will read three sentences.

I build AI copilots that survive contact with real enterprise workflows.
For the CityOps program I shipped Ask CityOps: a RAG copilot over ~400
customer documents with structured-output citations, evals, and guardrails —
deployed behind enterprise proxies with health checks, secrets management,
and a rollback plan.
I'm looking for Forward-Deployed Engineer roles where the job is getting AI
systems working inside a customer's messy reality, not just in a notebook.

Why this shape works:

• Sentence 1 — the claim: who you are as an engineer, in your own terms. Not "passionate problem solver" — a specific engineering identity.
• Sentence 2 — the proof: one artifact, with concrete technical detail. "~400 customer documents," "structured-output citations," "deployed behind enterprise proxies" — each phrase is checkable and each maps to vocabulary from the Stage 4 and Stage 5 lessons: RAG End-to-End, Structured Output, Deploying Behind Enterprise Proxies. (These details are true only if the work is real — see the honesty note below.)
• Sentence 3 — the ask: the role you want, stated plainly. This does double duty: it tells recruiters what to pitch you, and it filters out irrelevant inbound.

The "Open to Work" question: tradeoffs, not rules

LinkedIn lets you signal you're looking — with a photo frame everyone can see, or privately to recruiters only. There are reasonable arguments on both sides, and the honest answer is that the effect depends on your situation:

The pragmatic read: if you're employed and your manager doesn't know you're looking, use the private signal and verify what's visible with a friend's account. If you're openly job-seeking, the public frame's visibility upside outweighs the downside for most roles — but it's your call, and anyone telling you it's "always" right or "always" a red flag is selling certainty they don't have.

2. GitHub: the evidence gate

If LinkedIn gets you found, GitHub is where a skeptical hiring manager decides whether the claims are real. Here's the minimum concept most candidates miss: reviewers don't read your code. They skim your evidence. A hiring manager with fifteen profiles to triage will spend maybe two minutes on your GitHub — and they'll spend it on your profile page, your pinned repos' READMEs, and your commit graph. The code itself gets read only after you've passed the screen, if at all.

So the design goal isn't "impressive code." It's "impressive skimmability": a profile that answers, in under a minute, the three questions a reviewer is actually asking:

1. Does this person finish things? (Pinned repos with complete READMEs, not abandoned stubs.)
2. Does this person work like an engineer? (Commit history with real messages, tests, CI — not one giant "final code" commit.)
3. Can this person explain the work? (READMEs written for a reader, with the problem, the approach, and how to run it.)

Profile anatomy: what the reviewer actually sees

Your GitHub profile page is a landing page. Treat it like one:

README-first repos: the 30-second test

The README is the most-read file in any repo — and the most-neglected by candidates. A strong README answers four questions in order, and a reviewer should be able to get all four in thirty seconds of scrolling:

# Ask CityOps — RAG copilot for customer support

> Answers customer questions from ~400 support documents, with
> citations to the source passages. Built as the Stage 4 milestone
> of the Path to FDE curriculum.

## What it does (the demo)
[2-minute demo video link]

## How to run it
pip install -r requirements.txt
uvicorn app.main:app

## How it's built
- Ingestion: document chunking + embeddings
  (see: Feeding the Machine, Embeddings & Vector Search)
- Retrieval: hybrid search over a vector index with exact filters
  for exact facts (see: RAG End-to-End)
- Generation: structured output with per-request citations
  (see: Structured Output)
- Quality: eval set with a versioned scoring rubric
  (see: Evals & Tracing)
- Safety: input validation + guardrails + audit logging
  (see: Guardrails, Approvals & Audit)

## What I'd do next
- Add per-tenant isolation before multi-customer rollout
- Expand the eval set with adversarial queries
- Cut p95 latency with cached embeddings for repeat queries

Notice what's doing the work here. The quote line at the top is the 5-second pitch. "How to run it" proves it actually runs — a repo nobody can run is a screenshot, not evidence. "How it's built" maps each subsystem to a real technique (and real lessons — link to RAG End-to-End, Evals & Tracing, Guardrails, Approvals & Audit from your own writeups if you published them). And "What I'd do next" is the section most candidates skip and reviewers remember — it shows judgment, which is exactly what the interview will probe.

Commit hygiene: the cheapest signal in your portfolio

Commit history is a behavioral transcript. "final", "fix", "asdf" as messages tell the reviewer you treat version control as a save button. The bar is low and the payoff is real:

• Write messages like a human will read them: Add per-request citation validation to the RAG pipeline beats update stuff. Imperative mood, one line, saying what and why.
• Small, logical commits: one feature or fix per commit. A reviewer browsing your history should be able to narrate the project's evolution — that's evidence of engineering thinking.
• Never commit secrets. API keys, tokens, credentials — if it's in your git history, it's leaked. Use .env files listed in .gitignore, which is exactly what the Secrets & Security Basics lesson teaches. A leaked key in a public portfolio repo is the fastest way to fail a security-conscious reviewer's screen.
• Show the boring professionalism: tests (Testing with pytest), a CI workflow (CI/CD with GitHub Actions), a working build. Green checkmarks on your commits are a reviewer skim-signal that the project is alive and maintained.

3. The 2-minute demo video: the "oh, this is real" gate

Here's the artifact most candidates never build, and it's the one with the highest leverage. A LinkedIn headline gets you found. A GitHub profile survives the skim. But a 2-minute demo video does something neither can: it puts working software on a screen in front of a hiring manager and lets them feel the quality of the work.

The minimum concept: the video is not a presentation, it's a screen recording with a narrator. No slides. No talking head explaining the architecture for ninety seconds. The viewer should see real software doing a real thing within the first thirty seconds, and hear you narrate it like a field engineer showing a customer what got built.

The script template: four beats, two minutes

The structure below is a template you can reuse for any project. Four beats, hard timestamps — if a beat runs long, cut words, not beats:

THE 2-MINUTE DEMO — script template
====================================
0:00–0:15  THE PROBLEM (15 seconds)
  State the customer problem in one or two sentences. No background,
  no market sizing. The viewer must understand WHY this exists
  before they see a single pixel of UI.

0:15–1:00  THE DEMO (45 seconds)
  Show the thing working, end to end, on screen. Narrate what you're
  doing as you do it. One realistic scenario — not a tour of every
  feature. If it takes more than 45 seconds, your scenario is too big.

1:00–1:30  WHAT YOU BUILT AND HOW (30 seconds)
  Name the key technical decisions, fast. "RAG over 400 support docs,
  hybrid retrieval, structured-output citations, evals on a labeled
  set." This is the resume in spoken form — vocabulary the hiring
  manager's checklist recognizes.

1:30–2:00  WHAT YOU'D DO NEXT (30 seconds)
  Two concrete next steps, showing judgment. "Per-tenant isolation
  before multi-customer rollout, and expanding the eval set with
  adversarial queries." Never end on "that's it" — end on trajectory.

PRODUCTION NOTES
  - Record your screen at 1080p, narration on a phone mic in a quiet room.
  - Pre-record. Do three takes; ship the best one.
  - Put the video link at the TOP of the repo README and in your
    LinkedIn Featured section. An undiscoverable demo is a private demo.
  - Captions on. Recruiters watch on mute more often than you'd think.

The worked example: an Ask CityOps demo

Here's the template filled in — an illustrative composite of how a learner's Ask CityOps demo (the Stage 4 milestone RAG copilot) could be scripted. Read it aloud; it should take about two minutes:

0:00–0:15  THE PROBLEM
"CityOps support agents answer the same questions every day by searching
through 400 PDFs by hand. Customers wait hours for answers that exist in
the docs. Ask CityOps is a copilot that answers from those documents —
with citations, so the agent can trust it."

0:15–1:00  THE DEMO
[Screen: the Ask CityOps chat interface. Narrator types:]
"What's our SLA for critical outages?"
[The copilot answers in seconds, with two cited passages highlighted
from the source documents.]
"Notice the citations — every claim links back to the exact passage.
Now watch what happens with a question the docs can't answer:"
[Types: "What's our refund policy for alien abductions?"]
"The copilot says it doesn't know, instead of inventing an answer.
That's the guardrail doing its job."

1:00–1:30  WHAT I BUILT AND HOW
"Under the hood: document ingestion with chunking and embeddings,
hybrid retrieval with exact filters for exact facts, structured output
so every response carries its citations, and an eval set with a versioned
scoring rubric so I can prove the answers got better as I iterated."

1:30–2:00  WHAT I'D DO NEXT
"Before real customers: per-tenant isolation so one customer's docs never
leak into another's answers, and adversarial queries in the eval set —
the failure mode I'm most worried about is confident wrong answers on
ambiguous questions. Link to the repo and the eval results are below."

Why this demo works: the problem is concrete and human; the viewer sees working software by second twenty; the "I don't know" moment is the strongest thirty seconds in the video — it demonstrates the guardrail, which is exactly the judgment a hiring manager is screening for; and the closing shows trajectory instead of trailing off.

Putting the funnel together

Now re-read the funnel from the top with all three artifacts in place:

A recruiter searches "RAG engineer LLM production evals." Your headline matches — you surface. She skims your profile for ten seconds: headline, three-sentence About, Featured section with the demo video. She clicks play. Two minutes later she's seen working software, citations, a guardrail refusing to hallucinate, and a builder talking about what's next. She opens GitHub: profile README points at the same demo, pinned repos have real READMEs, commits read like an engineer's log, CI is green. The evidence is consistent at every gate — same project, same vocabulary.

That's the whole game. Not a bigger portfolio. A consistent one. One strong project, presented three ways, each tuned for the gate it guards.

One last thing, and it's the part of the DNA this curriculum never skips: explain it to a human. Before you touch a single profile field, tell a friend — out loud, in sixty seconds — what you built, why it matters, and what role you want. If you stumble, your headline will stumble too. The three-sentence About section is just that pitch, written down.

Your evidence kit is now the foundation everything else in this stage builds on. The next lesson takes the same anchor project and turns it into the story you'll tell in interviews — because the funnel's last gate is a conversation, and by then the evidence has already done half the talking. When you're ready, continue from the Get Hired page.