A data portfolio that shows how you think, not just what you built

People who read portfolios are looking for evidence of judgement. Can you pick a question worth asking, handle messy data, make decisions and explain them, and tell the truth about what you found? A list of tutorials completed does not show that. A few projects that do, do.

Show a question, not a dataset

A portfolio piece that begins "I downloaded the Titanic data" tells the reader nothing new: they have seen a thousand. One that begins with a question, "Do cycling trips in my city get shorter on rainy days, and by how much?", already shows taste. It does not matter whether the question is big. It matters that someone could disagree with your answer.

Choose data you find interesting, from a source whose terms allow you to use it (open government data, public APIs, datasets with a clear licence), and say where it came from.

Show the decisions

The valuable part is the thinking between the raw data and the chart. For each project, write down:

• What was wrong with the data and what you did about it. Missing values, duplicates, odd outliers: how many, and why you treated them as you did.
• What you chose not to do. A model you tried and dropped, and why.
• What you checked. How you know the numbers are right: a reconciliation with a known total, a test on a sample.
• What you would do with more time or data.

Hiring managers read these parts first, because they cannot be faked by copying code.

Be honest about limits

Say what the analysis cannot show. A correlation is not a cause. A sample of 200 is a small sample. A model that scores well on the data it was trained on has proved little. Candidates who state their own limits are trusted more than those who claim certainty.

Make it easy to open and to repeat

• A README that opens with the answer. One paragraph: the question, the result and the method, then a way to run it.
• Reproducible. A list of dependencies, the exact steps, and a small script or notebook that runs from top to bottom on a clean machine. Try it yourself on a fresh copy.
• Clean code. Sensible names, small functions, no secrets, no dead code and no giant commented-out blocks.
• Something to look at. A chart or short report that someone can understand in a minute, without installing anything. A published page or an image in the README works.

How many, and which kinds

Three solid projects are plenty. Aim for variety that matches the work you want:

1. An analysis with a clear conclusion, written for a non-technical reader.
2. A data pipeline or a cleaning job, with checks and tests, showing you can handle data that is not tidy.
3. Something that has a user: a dashboard, a small tool, a report that someone else could use.

Quality beats quantity, and a finished small project beats an ambitious unfinished one.

What to leave out

• Copies of course exercises presented as your own work.
• Projects you cannot explain in detail.
• Claims of results you did not measure.
• Anything that includes personal data you have no right to publish.

A simple test

Give your best project to a friend who does not work with data. Ask them, after five minutes, what question it answers and what you found. If they can say, you have written it well. If not, rewrite the first paragraph until they can.