The portfolio problem is not a shortage of ideas. It is that the projects most people build are the same four, built the same way, from the same tutorial — and a reviewer who has seen the Titanic dataset two hundred times learns nothing from seeing it again.
What makes a reviewer stop scrolling
Reviewers spend about ninety seconds on a repository. In that time they are looking for evidence that you made decisions, hit a problem, and handled it.
The projects that do this are rarely the most technically ambitious. They are the ones with a real input — messy documents, a live API, your own data — because real inputs produce real problems, and real problems produce something to talk about.
- A real data source rather than a clean benchmark dataset.
- A measurement, however crude, of whether it works.
- A README that says what you tried first and why you changed it.
- Something that broke, described honestly.
Four that are worth building
Not because they are novel, but because each one contains a genuine difficulty that teaches something interviews ask about.
- Document Q&A with citations over a corpus you actually use. The difficulty is grounding — making sure the answer comes from the cited passage rather than the model's memory.
- A tool-using agent that answers questions requiring two or three steps. The difficulty is what happens when a tool returns nothing useful.
- An evaluation harness for something you already built. The least glamorous option and the one that most distinguishes you, because almost nobody does it.
- A cost and latency dashboard for an LLM feature. Trivial to build, and it demonstrates the commercial awareness that separates engineers from enthusiasts.
Where to get data that is not a benchmark
The single change that most improves a portfolio project is swapping a clean benchmark dataset for something messy and real, because messy data is where the interesting decisions live. Clean data has had all of them made for you already.
Sources that work and cost nothing: your own documents, a public API with rate limits and inconsistent responses, government open data, the text of a codebase you know, a corpus of papers in a field you follow. Each of these arrives inconsistent, which is the point — handling that inconsistency is the work you will be asked about.
Do check licensing before publishing anything that includes the data itself, and avoid anything containing other people's personal information. A project that leaks data is a memorable interview for the wrong reason.
- Real input, inconsistent format, and a reason you care about it.
- Publish the code and the method, not necessarily the data.
- Never use anything containing personal information you did not have the right to hold.
Choosing one you will finish
The commonest failure is scope. A project that needs forty hours when you have ten becomes an abandoned repository, which is worse than no repository because reviewers do open them.
Estimate the hours honestly, then halve your ambition. A small finished thing with a good README beats an ambitious half-built one in every review I have ever been part of.
Projects that quietly work against you
Some projects are worse than nothing on a CV, and it is worth knowing which. A sentiment classifier on a standard dataset signals that you followed the most common tutorial in the field. A "ChatGPT clone" demonstrates that you can call an API. A Streamlit wrapper around a single model call with no retrieval, no evaluation and no failure handling is a UI exercise presented as an AI project.
None of these is shameful to have built — they are reasonable learning steps. The mistake is listing them as evidence of capability, because a reviewer who has seen them two hundred times reads them as an absence of anything better.
If a project is genuinely the best thing you have, the recovery is to extend it until it contains a real difficulty. Add an evaluation set to the classifier. Put retrieval behind the chat interface and measure whether the answers are grounded. The extension is usually a weekend and it changes what the project says about you.
How to talk about a project you did not finish
Most people have an abandoned project, and the instinct is to hide it. In an interview, an honest account of why something was abandoned is frequently more impressive than a completed tutorial, provided the reason was technical rather than motivational.
"I stopped because retrieval quality never got above about half and I could not tell whether the problem was the chunking or the embedding model" is a good answer. It shows you measured, you diagnosed, and you knew what you did not know. "I got busy" is not an answer, which is why the distinction is worth making before you are asked.
The README does most of the work
Most candidates spend their time on code and none on the README, which is backwards: the README is what gets read, and often all that gets read.
Cover the problem, the approach, what you measured, what failed, and what you would do differently with more time. That last section is the one that makes experienced reviewers take you seriously, because it demonstrates the judgement that comes after building something rather than during it.
Key takeaways
- 1.Real inputs produce real problems, and real problems are what interviews are about.
- 2.An evaluation harness is the least glamorous project and the most distinguishing.
- 3.Scope is the commonest failure. Halve your ambition and finish the thing.
- 4.The README gets read more than the code. Include what failed and what you would change.
Do it now, free
AI Project Idea Generator
Five ideas, each with an architecture, a realistic number of hours, and how you would evaluate it — because the difference between a portfolio project and a tutorial clone is usually evaluation.
No sign-up. The internship is free to join too, with real project briefs and reviewed submissions.