The AI engineer portfolio projects that actually get you hired.

Every AI engineering candidate has the same eight repos. A Titanic notebook. A sentiment classifier on the IMDB set. A chatbot wrapping an OpenAI call. A “RAG app” that loads three PDFs into Chroma and never gets evaluated. The problem is not that these are bad projects. It is that they are indistinguishable, and a recruiter looking at forty portfolios in an afternoon is not reading code. They are pattern-matching for reasons to stop reading.

I have been on the other side of this while building the work on this site, and the failure mode is consistent. It is almost never a lack of ability. It is that nothing in the repo proves the ability.

A portfolio is not a list of things you built. It is a set of claims, and every claim needs something committed to the repo that backs it.

Portfolios get skipped for the same three reasons, in roughly this order.

1. Nothing proves it ran

The single most common gap. There is a model.pkl and a notebook with outputs cleared, and no way for a reader to tell whether the numbers in the README were measured or remembered. No tests, no CI, no committed benchmark output, no screenshots of a running service.

The fix is unglamorous and takes an afternoon: a GitHub Actions workflow that runs your test suite on every push, and a benchmark script whose output you commit as a file. Now the green check next to your latest commit is doing the arguing for you.

2. Breadth instead of depth

Eight shallow projects read as eight abandoned projects. They also produce an interview you cannot win: the interviewer picks one, asks “why did you chunk at 512 tokens?”, and there is no answer because the number came from a tutorial.

Two or three projects, each with a design document explaining what you tried and rejected, gives you something to talk about for the full hour. Depth is also the only thing that is expensive to fake, which is exactly why it signals.

3. The projects do not match the job

A diffusion-model reimplementation is impressive and completely irrelevant to a Forward-Deployed Engineer role, where the actual job is integrating a model into someone else’s messy systems under a deadline. Candidates routinely build for the job title they find exciting rather than the one they are applying to.

These three titles get treated as interchangeable and are not. The distinction matters because it changes which project is worth six weeks of your evenings.

Forward-Deployed Engineer

Screening for: can you make a model useful inside a customer’s constraints. The signal is integration work, graceful degradation, and knowing when a human has to approve something.

• An approval-gated agent: it drafts an action, a human confirms, it executes, and every step is logged and reversible.
• A customer data integration service that ingests three genuinely different schemas and reconciles them, with the reconciliation failures surfaced rather than swallowed.

AI/ML Engineer

Screening for: do you know whether your system works. In 2026 the honest differentiator is evaluation, not model choice, because everyone has access to the same models.

• A retrieval system with a real eval harness: a labelled question set, retrieval metrics separated from generation metrics, and a regression gate in CI.
• A retraining pipeline with drift detection, where the interesting artefact is the decision rule for when to retrain, not the training loop.

Data Engineer

Screening for: correctness at volume, and what you do when the upstream data is wrong.

• A streaming pipeline with explicit late-arrival and duplicate handling, plus a backfill path.
• A warehouse model with tested transformations and an API on top, where the tests assert business invariants and not just row counts.

Independent of domain, these are what a reader is actually scanning for in the ninety seconds they give you.

1. A README written for someone who will never run the code. What it does, one architecture diagram, the headline numbers, how to run it. Not a wall of setup instructions.
2. A design document. Two pages: what you chose, what you rejected, and the measurement that decided it. This is the single highest-signal file in most repos, and almost nobody writes one.
3. Tests and a green CI badge. Even a thin suite. The point is the evidence that it runs, on a machine that is not yours.
4. Numbers with provenance. “p99 0.11 ms” means nothing alone; “p99 0.11 ms, benchmark output committed at bench/results/2026-05-serving.txt” means everything.
5. Commit history that looks like work. Forty commits over six weeks with real messages reads as a project. One commit named final version reads as a download.

Publish only numbers you can defend for ten minutes. One hard question you cannot answer undoes every number that came before it.

Work backwards from the job posting, not forwards from your interests. Pull five real postings for the role you want, list every responsibility that appears in three or more of them, and choose projects that produce evidence for the top two. That list is usually shorter and more boring than expected: deployment, evaluation, data quality, and being able to explain a tradeoff.

Then give each project a scope you can finish. A project abandoned at 70% is worth less than nothing, because the repo is public and the abandonment is visible. Six to eight weeks per project, two or three projects, is a realistic six months.

None of this requires paid compute. Free tiers cover inference, GPU time for fine-tuning, a Postgres instance and a permanent ARM VM, which is enough for every project listed above. I wrote up the exact stack and where each tier breaks separately.

And if the repo has to stay private, that is workable too, but it needs a deliberate substitute for the code a reader cannot see. That is its own problem.