Most early-career analysts have been told the same thing: build a portfolio. Put your work somewhere public. Show what you can do. The advice is right. The execution is almost universally bad.
The canonical portfolio is easy to recognize. A couple of notebooks built on a dataset that ships pre-cleaned with every data tutorial. A survival prediction model that has been built, incorrectly, by roughly two million people before you. A README that says "In this project, I explored..." followed by a list of libraries used. A chart that took four lines of code and is labeled "data visualization." The repo has three commits — all from the same afternoon.
This isn't what the person reviewing your application wants to see. It's what they're immunized against.
What signals competence to a hiring manager isn't volume of projects. It's evidence of judgment. Judgment about which problem to solve, how to frame it, what the data can and can't support, and whether you understand the limits of your own analysis. You can demonstrate all of that in a single well-documented project. You cannot fake it across ten weak ones.
A portfolio that works looks different. It starts with a question that isn't pre-answered — ideally one you actually cared about. It shows the messy middle: the data that didn't fit, the assumption you had to make and documented explicitly, the result that surprised you. It ends with something you'd actually defend in a meeting. Not a conclusion massaged to look impressive, but an honest read of what the data says and what it doesn't.
The documentation matters more than most people think. Not because hiring managers are reading every comment in your code. Because how you document tells them how you think. An analyst who writes "filter out nulls" with no further explanation thinks differently than one who writes "drop these nulls — confirmed with source team that they represent records excluded from scope, not missing data." That's one sentence. It's also the difference between someone who follows steps and someone who understands data.
The other mistake is treating a portfolio as a one-time artifact. Build it, link it, forget it. The analysts who get callbacks treat their work the way a writer treats a body of work — as something alive, not archived. They revisit old projects when they learn something new. They clean up the thing that's been bothering them. They update the README when the context changes.
You don't need ten projects. You need two or three that show you can do the work that actually happens in a data role: find a real question, work with imperfect data, be honest about uncertainty, and land on a clear conclusion.
Most portfolios don't fail because the work is wrong. They fail because they're not trying to say anything.