The Eval Report That Passes the Screen

A hiring manager doesn't read your code first. They open the eval report. If it isn't there, or it's a screenshot of a demo working once, the tab closes and the next candidate opens.

This is the one artefact that separates "it works" from "hire this person," broken down section by section, with a filled example pulled straight from a real reference build, so you can see exactly what a reviewer is looking for and copy the structure for your own project.

Inside, you get:

The anatomy of a real eval report. Six sections, in the order a reviewer actually reads them: the golden set description, the scoring method, a before-and-after results table, a failure taxonomy with counts, cost and latency per request, and a changelog that ties every fix back to the failure it solved.

An annotated example, from the reference build. A support ticket triage system taken through the whole process, with call-outs explaining why each section is written the way it is, and what makes the difference between a report that reads like proof and one that reads like a guess.

How to build a golden set that holds up. Thirty cases minimum, deliberate edge cases, adversarial inputs designed to break the naive approach, and why you have to label it yourself instead of trusting labels you never checked.

Three ways to score, and when to use each. Exact match for anything with one correct answer, an LLM judge for open-ended output like a summary or a drafted reply, and a human spot check to ground-truth the other two, never as your only method.

A five-point checklist for whether your eval report is actually interview-ready, so you know before a hiring manager tells you.

Most self-taught AI portfolios stop at "it works." This is the difference between that and a project a hiring manager can actually trust.