What a reviewer actually does
Someone hiring gives your project a minute, maybe two. They open the repository, read the top of the README, glance at one file, and decide whether to spend more time. Almost nobody runs your code.
So the portfolio's job is not to demonstrate that the code works. It is to show, quickly, that you made decisions in a situation where the answer was not published anywhere.
What does not work
Titanic survival. MNIST digits. A sentiment classifier on a movie review dataset. A chatbot wrapper over a public model with no evaluation. These are not bad projects — they are fine as practice. They are bad *evidence*, because ten thousand people submitted the same thing and none of the decisions were yours. The dataset was clean, the target was given, the metric was chosen for you.
A notebook with forty cells and no README is also not evidence. Nobody reads it.
What works
One to three projects, each solving a problem that a specific real person or group actually had. Sources of such problems, in order of how easy they are to reach:
- Your own repeated annoyance. Something you do by hand every week.
- A small organisation near you: a clinic, a school, a farmers' cooperative, a two-person shop, a student society. They all have data in spreadsheets and a question they cannot answer.
- A public dataset that is genuinely messy — municipal budgets, transport delays, rainfall, exam results — where cleaning it *is* the work.
The defining feature is mess. Mess is where judgement becomes visible.
Write it down like this
# Bus delay tracker — Lagos, route 57
What it does: tells the cooperative's drivers which departure
window is late most often, updated nightly.
Who uses it: 6 dispatchers, since March 2026.
The data problem: three of the eleven months had GPS pings
recorded in local time and eight in UTC. Nothing labelled
this. I found it because "delays" spiked exactly one hour.
What I decided and why:
- Dropped the first two weeks entirely (device swap, no
reliable timestamps) instead of interpolating.
- Median, not mean — two breakdowns skewed everything.
What it gets wrong: no data for public holidays. A dispatcher
caught this before I did.
Run it: make devThat page is worth more than the code beneath it. It shows you noticed something, chose between two defensible options, and were honest about a limitation.
Measure something
The single strongest signal in an AI-adjacent portfolio is that you evaluated your own work. Not "it produces good answers" — a table of thirty test cases you wrote by hand, what the system did on each, and how many it got wrong. Anyone can build something that works on the example they demoed. Almost no beginner shows what it does on the cases they did not choose.
Two practical rules
Deployed beats local, because a running link takes five seconds to check and a repository takes five minutes. A free hosting tier is enough.
Small and finished beats large and abandoned. A tool that does one thing for thirty people is stronger than an unfinished platform. If your project cannot be described in one sentence, cut it until it can.
Before you move on