Ian Klosowicz
The difference between a portfolio that gets calls and one that doesn't usually isn't about the number of projects. It isn't about which tool you used. It's about whether the work answers a real question, whether the candidate can clearly explain what they built, and whether the projects look like something a working analyst would produce rather than something they built to check a box.
Those 3 things are decided before you send a single application. This post breaks down what actually separates the 2 portfolios and how to make sure yours is on the right side of that line.
Most resume reviews at the entry level are fast. A hiring manager or recruiter opens your resume and within 60 seconds has already formed a working impression. When they click your portfolio link, the same thing happens. The first page of a dashboard, the first section of a SQL project, the first few lines of a README -- that's where the impression forms.
In that 60 seconds, they're not running a technical evaluation. They're answering 2 questions:
Portfolios that get calls clear both. Portfolios that don't usually fail the first one -- the work looks like practice, not production. The signal is subtle but consistent: tutorial dataset, generic question, default formatting, no visible analytical intent. Reviewers have seen hundreds of portfolios and the pattern recognition is fast.
Clearing the first filter doesn't require a polished design or advanced techniques. It requires that the work looks like it was done with purpose. A specific question. A real dataset. Decisions that were made for a reason.
The most common portfolio mistake isn't building the wrong type of project. It's building the right type of project at the wrong quality level and putting it on the resume anyway.
A SQL project that demonstrates basic SELECT statements and one JOIN isn't a portfolio project. It's a tutorial completion. A dashboard built on the Superstore dataset with default colors and 6 KPI cards that show raw numbers with no context isn't a portfolio project either. Both go on the resume because the candidate ran out of time, got anxious about applying, and decided something was better than nothing.
Something is not always better than nothing. A weak project that an interviewer clicks on and closes in 20 seconds creates a negative impression that a blank line on the resume doesn't. It signals that the candidate doesn't know what good looks like. That's a harder problem to explain away than simply not having a project yet.
The quality bar is specific and reachable. A project clears it when:
That bar doesn't require advanced skills. It requires building with intent rather than building to complete.
This is the core distinction. Two candidates build a Power BI dashboard on the same dataset. One builds a dashboard that displays the data. The other builds a dashboard that answers a question about the data. The second one gets the call. The first one doesn't.
A tool demonstration shows that you learned the tool. It might include impressive visuals, multiple chart types, and clean formatting. What it doesn't show is what you were trying to figure out and whether the analysis got you there.
Analytical thinking is visible in the structure. It's in the question stated on the first page. It's in the chart title that says what the finding is, not just what the variable is. It's in the KPI card that includes a comparison to the prior period, not just the current number. It's in the SQL query that uses a CTE to cleanly separate logic rather than nesting 4 subqueries because that's what the tutorial did.
The portfolio that gets calls shows evidence of thinking. Not just evidence of doing.
I didn't have a formal analytics portfolio when I got my first data role. I had 3 project links on my resume -- 2 Tableau dashboards and 1 Power BI project. No landing page, no portfolio site, no README. But each project answered something specific, the data model was real, and I could walk through every chart without looking at notes. That was enough because the thinking was visible in the work itself.
A portfolio that gets calls isn't just about the projects themselves. It's about how those projects are framed on the resume that links to them.
The most common mistake: listing a project by its title and tool, with no description of what it did or what question it answered. "Power BI Sales Dashboard" tells a reviewer nothing useful. It doesn't tell them what question the dashboard answers, what data it uses, what they'll find when they click the link, or why you built it.
A stronger framing treats each project like a bullet point that earns its place. It names the analytical question, states what you found, and links the work directly. Two or 3 lines per project is enough. The goal is to give the reviewer a reason to click the link, not a reason to skip it.
Project links also need to work. This sounds obvious. A surprising number of portfolios have broken links, projects that require software to open, or dashboards that time out. Test every link before submitting an application. If a reviewer can't open your work in 10 seconds, they move on.
The portfolio that gets calls earns an interview. The interview is where portfolios that looked strong on paper often fall apart.
"Walk me through your project" is the most common portfolio question in analyst interviews. Most candidates who built something solid haven't practiced the walkthrough. They know the work but they've never said it out loud. The result is a rambling explanation that undersells the analysis, skips the data model, and ends without a clear conclusion.
A strong walkthrough takes 90 seconds and covers 4 things:
That structure signals analytical maturity. It shows the reviewer that you think about your projects as communication artifacts, not just technical exercises. Practice it out loud, not in your head. 3 or 4 run-throughs before any interview is the minimum.
I bombed my first several interviews partly because I hadn't done this. I knew the work. I hadn't rehearsed explaining it under mild pressure to someone I was trying to impress. Those are different things. The rehearsal matters.
The portfolio that gets calls usually has fewer projects than the one that doesn't.
The instinct to add more projects is understandable. More projects feels like more evidence. In practice, 4 weak projects signal less capability than 1 strong one. A reviewer who opens 4 projects and finds nothing impressive in any of them has seen a pattern, not an exception. A reviewer who opens 1 project and finds something solid has seen a candidate who knows what good looks like and can produce it.
The target for entry-level analyst portfolios: 2 to 3 projects, each of which you can talk about in depth, each of which answers a specific question, and at least 1 of which demonstrates SQL and at least 1 of which demonstrates a BI tool. That combination covers the core technical requirements and leaves room for the walkthrough to do its job.
Adding a 4th or 5th project makes sense only after the first 2 or 3 are genuinely strong. Breadth built on weak foundations doesn't help.
The Analyst Hive program is structured around building 3 portfolio projects in Month 1, with each one designed around a real question and a real data model, not tutorial exercises. The goal is 3 projects you can defend, not 6 you can barely describe.
Pulled together, the portfolio that generates interviews has these characteristics:
None of that requires advanced skills. All of it requires deliberate decisions about what to build, how to present it, and how to talk about it. The portfolios that don't get calls usually fail on the second and third of those, not the first.
How many projects do I need in my data analyst portfolio?
2 to 3 strong ones. At minimum: 1 SQL project and 1 BI dashboard, both answering specific questions on non-tutorial datasets. A 3rd project adds value if it demonstrates a different skill or targets a different type of role. More than 3 is fine if all of them are strong, but quantity doesn't substitute for quality. A reviewer who opens 5 weak projects forms a worse impression than a reviewer who opens 2 solid ones.
Do I need a portfolio website?
No. Individual project links directly on your resume work. Tableau Public hosts dashboards publicly by default. SQL projects go on GitHub. Power BI projects can be shared via Power BI Service or a GitHub-hosted .pbix file. A portfolio website is a nice-to-have for differentiation, but the absence of one never costs a candidate an interview. Broken links do.
What makes a SQL project good enough to put on a resume?
It should demonstrate joins across at least 2 tables, aggregations with GROUP BY, and ideally a CTE or window function. The query should be answering a specific business question, not just displaying the data. Host it on GitHub with a brief README that explains what the question is, what the data source is, and what the query found. A reviewer who opens your GitHub should understand the project within 30 seconds without reading the full query.
Should I include personal projects or only professional ones?
Personal projects are standard for entry-level portfolios. Most candidates don't have professional analytics work to show yet, which is exactly why the portfolio exists. A personal project built on public data, with a real question and solid execution, is evaluated the same way a professional project would be. The question is whether it answers something specific and whether the work is defensible -- not whether it came from a job.
How do I pick a dataset for my portfolio project?
Pick something from an industry or domain you can speak to. If you've worked in retail, use retail data. If you're interested in sports analytics, use sports data. If you have a healthcare background, use public health data. The benefit isn't just that you'll find a dataset the reviewer hasn't seen -- it's that you'll naturally talk about why the question matters, because you have context. That context comes through in interviews. Kaggle, government open data portals, and sports reference sites all have quality datasets most candidates aren't using.
Can I use a work project in my portfolio?
Only if the data is fully anonymized or mocked and you're confident your employer has no objection. Using real client or internal data in a public portfolio is a risk most people shouldn't take. A better approach: rebuild the analysis structure on public data that approximates what you worked with. You can describe the real-world context in the interview without exposing proprietary data in your portfolio.
If you want to build the 2 to 3 projects that actually generate interviews -- with the question, the data model, and the walkthrough all figured out -- the Analyst Hive program structures exactly that in Month 1. Daily tasks, built around getting hired.
