Ian Klosowicz
2 to 3 projects. That's the answer for most entry-level data analyst candidates. Not 1, because that's a thin portfolio if the one project turns out to be weak in an interview. Not 6, because quantity without quality signals that you know something is missing but aren't sure what.
The real question isn't how many. It's what each one needs to demonstrate and whether the set covers the technical bar hiring managers are checking against. This post breaks down the target number, what each project needs to do, and when it makes sense to go above or below the range.
The 2 to 3 target exists for a specific reason: it's the minimum that covers the core technical surface area while remaining defensible in an interview.
1 project is fragile. If the interviewer asks about it and you stumble — if the dataset turns out to be something they've seen before, or if the question you answered turns out to be too surface-level — there's nothing else to fall back on. A second project gives you a second angle, a second data source, a second tool demonstration.
More than 3 starts working against you if the additional projects aren't strong. A reviewer who opens 5 projects and finds the same quality level in each one has learned that you've put in volume, not that you've put in depth. 3 projects you can defend confidently beats 6 you can barely describe.
The range also maps cleanly to the hiring bar. Entry-level analyst technical screens check 3 things: SQL, a BI tool, and the ability to discuss your analysis. 2 to 3 projects, structured correctly, demonstrates all 3 without padding.
The minimum viable portfolio for an entry-level data analyst has 2 projects:
Project 1: SQL. A query or set of queries that answers a specific business question. This should demonstrate joins across at least 2 tables, aggregations with GROUP BY, and ideally a window function or CTE. Hosted on GitHub with a README that explains the question, the data source, and the finding. This project answers the "can you write SQL" question directly.
Project 2: BI dashboard. A 3 to 5 page report built in Power BI or Tableau, on a non-tutorial dataset, with a proper data model (at least 1 fact table and 1 dimension table), at least 1 filter or slicer, and chart titles that state findings rather than variable names. This project answers the "can you build something a stakeholder could use" question.
Together, those 2 cover the core hiring bar. SQL plus BI is the combination that shows up in the majority of entry-level analyst job postings as a required or expected skill set. If you have both at a solid quality level, you're qualified to apply.
A 3rd project adds value when it demonstrates something the first 2 don't:
If the 3rd project would just be "another dashboard on another dataset," it doesn't add much. Only add it if it extends what the first 2 have already established.
1 project can be enough in a narrow set of circumstances:
You're in an active job search with a deadline and 1 genuinely strong project is ready. Applying with 1 solid project is better than waiting another 4 weeks to finish a second mediocre one. The strong project should cover both SQL and BI — for example, a dashboard where the data was pulled and prepped with SQL before loading into the BI tool, and both are visible in the project.
You have professional experience in a related field and the portfolio is supplementary. Someone with 5 years in finance analytics who is repositioning into a data analyst title doesn't need 3 entry-level projects. 1 strong one that demonstrates the tools they've been asked about is usually enough to support the resume.
Outside those situations, 1 project is thin. It gives you 1 chance to show the work, and if the interviewer doesn't find it compelling, there's nowhere to go.
There are legitimate reasons to build 4 or more projects:
You're targeting multiple role types. If you're applying to both standard business analyst roles and more technical product analyst roles, the technical roles may require Python. A 4th project in Python is additive if it's strong and if the roles you're targeting ask for it.
You want to demonstrate domain depth. 3 projects in healthcare analytics, all at a solid quality level, signal domain focus in a way that 3 projects in 3 unrelated industries doesn't. If you have a specific target sector, depth in that sector is a differentiator.
You're early in the job search and have time. If you've been applying for several months without traction, an additional strong project is one of the legitimate levers to pull. The question to ask first: is the traction problem the portfolio, or is it the resume framing, the application volume, or the SQL performance in technical screens? More projects don't fix the other problems.
You want to replace a weak existing project. If one of your 3 projects isn't strong, build a replacement rather than adding a 4th. 3 solid projects is always better than 4 that include 1 weak one.
The quality threshold for a project to be worth including is specific:
If a project clears all 5 of those, it's in. If it doesn't, it's not ready, and adding it to the resume before it is creates risk rather than reducing it.
I didn't have a traditional portfolio when I got hired. I had 3 project links sitting directly on my resume — 2 Tableau dashboards and 1 Power BI project. No portfolio website, no landing page, no README for 2 of them. What I had was the ability to walk through each project with confidence, because I'd built them with a real question in mind and knew every decision I'd made. The number was right. The quality was there. That was enough.
The most common version of this mistake: a candidate has 2 weak projects. Instead of improving them, they build a 3rd. Now they have 3 weak projects. The problem isn't the count.
When a portfolio isn't generating calls, the instinct is to add more. More projects, more tools, more certifications. Most of the time the right move is to go back to what's already there and make it stronger: rewrite the resume framing, upgrade the dashboard titles to state findings, add a second data source to a SQL project, practice the walkthrough until it's tight.
The 125,000 analysts who follow me on LinkedIn consistently report the same pattern when they do get interviews: the interviewer spent most of the time on 1 or 2 projects, not all of them. A portfolio that has 2 projects an interviewer genuinely wants to dig into is more valuable than 5 projects that produce surface-level questions and quick moves to the next topic.
The Analyst Hive program builds 3 projects in Month 1 — 1 SQL project, 1 BI dashboard, and 1 more advanced project that extends the first 2. The count is intentional. 3 at quality beats more at volume.
There's a version of the portfolio question that's really about delay. Candidates wait until they have the perfect portfolio before applying. The perfect portfolio never arrives because there's always another project to add or another improvement to make.
The right threshold for starting to apply: 1 strong project that covers SQL and BI, ideally 2. Not all 3. You can build the 3rd while you're applying. The job search itself gives you real feedback on what's working and what isn't, which is more valuable than another month of building in isolation.
Applying with a solid 2-project portfolio and upgrading to 3 mid-search is a better use of time than waiting to apply until all 3 are perfect. The market gives you signal that building alone can't replicate.
Is 1 project enough for a data analyst job?
In most cases, no. 1 project is fragile — if it doesn't land in the interview, there's nothing else to fall back on. The exception is a project that clearly demonstrates both SQL and BI skills in a single piece of work, or a candidate with significant relevant professional experience where the portfolio is supplementary. For most people starting from scratch, 2 is the minimum worth applying with.
Do all portfolio projects need to be dashboards?
No, and they shouldn't all be. A portfolio that's all dashboards covers BI but doesn't demonstrate SQL directly. A strong 2-project minimum includes 1 SQL project and 1 BI dashboard. If you add a 3rd, consider making it a different output type: a Python analysis in a Jupyter notebook, an Excel model, or a written analysis backed by SQL queries. Variety across the set demonstrates that you understand when to use which tool.
Should I build a portfolio website to house all my projects?
No, not as a prerequisite to applying. Individual project links on your resume — Tableau Public for dashboards, GitHub for SQL and Python, Power BI Service for Power BI — work fine. A portfolio website is a nice differentiator if you have time and the rest of your job search materials are already strong, but its absence has never cost anyone an interview. Broken project links have.
How do I know when a project is good enough to add to my resume?
Run it through 5 checks: it answers a specific question you can state in 1 sentence; the data isn't a universally recognized tutorial dataset; the model or query structure shows relational thinking; you can walk through it in 90 seconds without hesitating; and the resume framing leads with the question and the finding, not just the tool. If it clears all 5, it's in. If it doesn't clear even 1, it's not ready.
What if my projects are in different tools and I'm applying to a role that uses one specific tool?
Lead with the project in the tool the role uses. If you have a Power BI project and a Tableau project, and the role uses Power BI, put the Power BI project first on your resume. Mention in the cover letter or the interview that you're familiar with both and can ramp quickly on either. The specific tool matters less than the analytical thinking behind the project, but leading with the relevant one is the stronger play.
Can I list a group project in my portfolio?
Yes, with clear attribution. State what your specific contribution was: the SQL queries, the data model, the dashboard design, the analysis. Listing a group project without specifying your role creates risk in the interview when the follow-up questions surface gaps in what you actually built. If your piece of the project is strong on its own, feature that piece and mention it was part of a larger team effort.
If you want a structured plan for building the right 3 projects in the right order — SQL first, then BI, then one that extends both — the Analyst Hive program covers exactly that in Month 1. Daily tasks, built around what entry-level analysts actually need to get hired.
