Ian Klosowicz
Most portfolio dashboards don't get rejected because they're ugly. They get passed over because they signal, in a handful of specific ways, that the person who built them hasn't thought about data communication yet. Hiring managers aren't always conscious of the checklist they're running through, but the pattern recognition is fast. Within 60 seconds of opening your dashboard, they've formed an impression.
The good news: every mistake on this list is fixable before you submit a single application. None of them require advanced skills. They require knowing what they are.
This is the most common mistake and the one that does the most damage. A dashboard without a clear analytical question looks like a data display, not an analysis. And a data display doesn't show analytical thinking — it shows that you learned how to connect a dataset to a tool.
The question doesn't have to be printed at the top of the page, though that works. It has to be evident from the structure. Every chart, every KPI card, every filter should be in service of answering something specific. If a reviewer can look at your dashboard and not be able to articulate what business question it's solving, the question isn't there.
"Sales overview" isn't a question. "Which regions missed their Q3 targets and what drove the shortfall?" is a question. The second one tells a reviewer you thought analytically before you opened the tool. The first one tells them you had data and built charts.
Fix: Before you build anything, write the question in one sentence. Put it in the dashboard subtitle or the first text box on page 1. Every visual you add should be defensible as contributing to the answer.
A single number with no comparison means nothing. Total Revenue: $4.2M. Great. Is that up or down? Compared to what? Against what target? Over what time period?
KPI cards that show a raw number with no benchmark, trend, or variance read as decorative. They're the most visible element on most dashboards, and when they don't provide context, they undermine the whole project.
Strong KPI cards include at least one of:
Any one of those additions turns a number into information. Without at least one, the card is a label, not an insight.
This is one of the mistakes I see most often in early portfolios from people in the Analyst Hive community. The fix takes 10 minutes once you know what to add. But if you don't know it's missing, it stays missing through every application.
Chart type selection is where analytical understanding shows up most visibly. Using the wrong chart type for the data isn't just an aesthetic problem — it tells a reviewer you don't understand what the visual is communicating.
The most common wrong-chart situations in portfolio dashboards:
The test: if you can't explain in one sentence why you chose that chart type for that data, you probably chose it because the tutorial used it or because it was the default. Both of those answers come through in an interview.
A dashboard built on a single flat table isn't demonstrating data modeling skills. It's demonstrating that you can connect a spreadsheet to a visualization tool, which is a much lower bar.
Entry-level analyst roles involve working with data that comes from multiple sources, multiple tables, joined on common keys. If your portfolio project doesn't show that you understand this, you're missing one of the core competencies the role requires.
A proper portfolio data model has at minimum:
If your dataset is a single flat file, split it. Pull the unique products into a product dimension table. Pull the unique dates into a date table. Rejoin them. You now have a star schema and a data model worth showing.
I work in data engineering now — Snowflake, Coalesce, pipeline architecture. The gap between candidates who understand relational data modeling and those who don't is immediately visible and it matters for every role above the most basic data entry work. Show the model in your portfolio, even at a simple level.
Default Power BI blue or default Tableau orange across every visual signals that no design decisions were made. It doesn't have to be beautiful, but it should be intentional.
"Intentional" doesn't mean custom branding or a design portfolio. It means:
The single most effective formatting change most dashboards need: give the most important number on each page more visual weight than everything else. Make it bigger. Put it in a prominent position. Let the eye land on it first. That's design thinking applied to data communication, and it signals awareness that most junior candidates don't have.
Fitting 10 visuals on 1 page is a display of data, not a communication of insight. When everything is on the screen at once with equal visual weight, nothing is prioritized, and the viewer has to do the work of figuring out what matters. That's the analyst's job, not the viewer's.
The benchmark: each page should have 1 primary message. Everything on that page supports it. If you find yourself adding a 5th or 6th chart that doesn't directly support the page's main point, it belongs on a different page or it doesn't belong in the dashboard.
3 to 5 focused pages beats 1 overloaded page every time. The reviewer can follow a focused page in seconds. An overloaded page requires them to slow down, look harder, and do interpretive work. That friction costs you.
A dashboard with no slicers, no filters, and no cross-filtering between visuals reads like a static report. It may be accurate and well-designed, but it doesn't demonstrate that you understand one of the core differentiators between a BI dashboard and a PDF.
Interactivity doesn't have to be complex:
Any of those additions demonstrates that you know how dashboards are actually used in a business context — as interactive tools, not printed reports. Reviewers who use BI tools daily notice immediately when interactivity is absent.
Most of these mistakes come from rushing the tool, which is why how long Power BI really takes to learn is worth being honest about.
The Superstore dataset. The Titanic dataset. The Airbnb NYC dataset. The AdventureWorks database. These datasets have been used in so many tutorials that experienced reviewers recognize them on sight, and the recognition immediately frames the project as practice work rather than analytical work.
That framing isn't fatal, but it's a ceiling. A tutorial dataset project will rarely be the thing that gets someone hired. It demonstrates that you completed a tutorial. It doesn't demonstrate that you can identify a real question, find relevant data, and build something that answers it.
The fix: find a dataset from an industry you care about or have background in. Sports statistics, government open data, financial filings, healthcare public datasets, industry benchmarks — all of these are available, most of them are messier than tutorial data (which is actually good for showing data prep skills), and none of them have been seen 50 times by the reviewer opening your resume.
Picking a dataset you're genuinely interested in also makes the walkthrough easier. You'll naturally talk about why the question matters, because you actually care about the answer. That energy reads differently than "I used the dataset from the course."
If you want guidance on which datasets to use and how to frame a portfolio project around them, the Analyst Hive program covers this in Month 1 as part of the project build sequence. The goal is a finished project you can talk about confidently, not a tutorial you completed.
Avoiding these is only half of it; it also helps to have a clear picture of what a good dashboard looks like to the person reviewing it.
How do I know if my dashboard answers a real question?
Write the question down before you build anything. Then, when the dashboard is done, ask someone who hasn't seen it to tell you in one sentence what it's showing. If they can't, the question isn't visible enough in the design. The question should be answerable from the dashboard itself, without you explaining it. If it requires explanation, the dashboard isn't doing the communication work.
Do I need a date table in my Power BI model?
Yes, for any project involving time-based analysis. Power BI's time intelligence functions — TOTALYTD, SAMEPERIODLASTYEAR, and similar — require a proper date table with continuous dates marked as the date table in the model. Without it, your time intelligence measures will produce incorrect results or won't work at all. Building a date table is a standard part of any Power BI project and signals that you know the tool properly.
How many KPI cards should be on a dashboard page?
3 to 5 is the typical range for a summary or overview page. More than that and the cards start competing with each other. Each card should represent a metric that directly relates to the page's main question. If you have 8 KPI cards on a page, you probably have 3 to 4 metrics that matter and 4 to 5 that you added because the data was there. Cut the ones that don't directly answer the question.
Is it okay to use a tutorial dataset if I've done something original with it?
It's better than a straight copy of a tutorial, but it's still a ceiling. If you've taken the Superstore dataset and built a genuinely novel analysis with a specific business question, it's a step up from the tutorial output. But you'll still spend part of your walkthrough explaining that this is a practice dataset and that you did something different with it. That's time spent on defense. A dataset the reviewer hasn't seen puts you on offense from the first second.
What's the fastest way to fix a flat data model?
In Power Query (Power BI) or Tableau Prep, split your flat table into a fact table and at least one dimension table. Take the unique values from a categorical column — product names, customer IDs, region codes — and create a separate table from them with a unique ID column. Then join that table back to the fact table on the ID. In Power BI, set the relationship in Model view. In Tableau, set the join in the data source panel. The whole process takes 20 to 30 minutes and produces a materially stronger project.
Should I add a data model page to my dashboard?
For Power BI projects, yes — a screenshot or description of your model view in the walkthrough is useful, even if it's not a full dashboard page. It shows the reviewer you understand the structure behind the visuals. Some candidates add a final "methodology" page with a screenshot of the model, the data sources, and a brief description of any transformations. That's a strong move for an entry-level portfolio because it demonstrates awareness that most competitors won't have.
If you want to build a dashboard that clears the bar instead of signaling junior, the Analyst Hive program walks through project builds with these standards built in from the start. Daily tasks and a sequence designed around what hiring managers actually look for.
