Building an AI Portfolio That Gets You Interviews

A reviewer looking at a stack of portfolios sees the same four projects over and over: chat with a PDF, a wrapper around a chat API, a fine-tune on a public dataset, an agent that browses. None of them is a bad idea. All of them are indistinguishable, because the version in the tutorial made every interesting decision already.

Why most AI portfolios read the same

A project demonstrates judgement only where judgement was required. Following a tutorial removes precisely the parts a reviewer is looking for: what you chose, what you rejected, what you measured, and what you did when it did not work. The artefact looks similar either way, which is why reviewers stop reading the artefact and start reading the write-up.

So the differentiator is not the topic. It is whether the project contains a decision that could have gone the other way, and whether you can show the evidence that made you choose. A modest project with a real evaluation and an honest account of a failure beats an ambitious one that was never measured, every time, and it beats it in about thirty seconds of a reviewer’s attention.

Two is the right number of projects. Three if one is genuinely small. A long list of half-finished repositories is a negative signal because the thing a reviewer most wants to know — can this person finish something — is answered badly by it.

Four briefs

Each of these is written as a brief rather than an idea, because the constraints are the point. Pick the one whose domain you actually care about; the domain does not matter to a reviewer, and it matters enormously to whether you finish.

Brief 1 — The one that has to say “I do not know”

Build a question-answering service over a corpus you own or can legally use — your own notes, a public standards document, a municipality’s bylaws, the rules of a game. It must cite the passage supporting each claim, and it must refuse to answer when the corpus does not contain the answer.

The judgement being demonstrated is calibration. Getting a retrieval pipeline to answer is easy; getting it to abstain correctly requires you to think about what abstention costs and when it is right and to build an evaluation set that contains questions with no answer. Most candidates have never built one.

Brief 2 — The one with a schema and adversarial inputs

Take a messy real-world document type — invoices, lab results, job adverts, recipe pages — and produce validated structured records from it. The output must conform to a schema you designed, and the service must handle three categories of input you deliberately collected to break it: a document in the wrong language, a document missing a mandatory field, and a document that contains text trying to change the instructions.

That last category is the interesting one: it turns the project into a demonstration that you know what arrives with untrusted content. Very few portfolio projects show any awareness of it at all.

Brief 3 — The one that had a budget

Build anything that processes a batch of at least a few thousand items — classification, enrichment, summarisation, deduplication — under a stated cost ceiling that you set before starting. Publish the cost per item, how you got it down, and what quality you traded away to get there.

The judgement here is economic, and it is the rarest kind in a portfolio. A candidate who can say “the naive version cost 4.1 cents per document; batching plus a smaller model with a verifier brought it to 0.6, and the failure rate went from 2% to 3.5%, which was acceptable because failures land in a review queue” has demonstrated something no tutorial teaches. The reasoning behind that trade is a calculation, not a preference.

Brief 4 — The one that reproduces somebody’s claim

Take a published claim — a prompting technique, a retrieval improvement, a benchmark result on an open model — and try to reproduce it on a task of your own. Report what happened, including if it did not replicate.

This one is unusual, cheap, and disproportionately impressive, because it demonstrates the thing employers most struggle to hire for: the instinct to check. It also connects directly to the daily skill of knowing that a benchmark result does not transfer to your task. A negative result, honestly reported with the method visible, is a stronger portfolio piece than a positive one, and almost nobody submits one.

The acceptance criteria that do the work

Whichever brief you take, these are the criteria that convert it from a demo into evidence. A reviewer can check all of them in ten minutes, which is roughly what your project will get.

[ ] A frozen evaluation set exists, in the repo, with at least
    50 cases, including cases the system is expected to fail
    or refuse.
[ ] One number summarises quality, its definition is written
    down, and the number is reported honestly (not the best
    run — the current one).
[ ] The evaluation runs with one command and prints that number.
[ ] At least one decision is documented as a comparison:
    two options, the measurement, the choice, the reason.
[ ] Cost per unit of work is stated, with how it was computed.
[ ] Failure behaviour is defined: what happens on a timeout,
    a rate limit, and an invalid response.
[ ] The README says what the system does NOT do, and one thing
    that is currently wrong with it.
[ ] It runs from a clean clone with documented setup, and the
    setup does not require the reviewer to have your API key.

The last two lines matter more than they look. A README that admits a limitation reads as competence rather than weakness — it is what a post-implementation review looks like — and a project that will not start is a project that was not reviewed.

The write-up is half the project

Assume the reviewer will read one page and skim the code. That page should be structured as an argument, not a feature list:

• The problem, in two sentences, including who would care.
• The interesting decision. Name it explicitly: “the hard part was X”. Show the two options and the evidence.
• The number, with its definition and its evaluation set size. If the number is unimpressive, say so and say why you think it is.
• What broke. One real failure, diagnosed. This is the single most persuasive paragraph in the whole document, because it is the one that cannot be produced by following a tutorial.
• What you would do next and why you stopped where you did. Stopping deliberately is a professional signal.

Keep an architecture diagram if there is genuinely a shape worth seeing. Delete the section listing the technologies used; the reviewer can read the imports and nobody was ever hired for a logo grid.

What to leave out

• A hosted demo that costs you money and will be down. A short screen recording in the README is more reliable and cannot be exhausted by a bot. If you do host it, put a spend cap in front of it — a public endpoint that calls a paid API is a bill waiting to happen, and discovering that in your portfolio is not the way.
• Anything with a private dataset the reviewer cannot see. It makes every claim unverifiable, which is the opposite of the goal.
• Benchmarks you ran once. A single run of a stochastic system is an anecdote. Either run it enough times to say something, or report it as an anecdote.
• Scale you did not need. A queue, a vector database cluster and a Kubernetes manifest around a project handling four hundred documents reads as inexperience, not ambition. So does a vector database where a file would have done.