Why a Portfolio Matters More Than Another Course Certificate
A hiring manager at a typical mid-size company gets about 250 applications per data analyst role, according to LinkedIn's 2024 Talent Trends report. About 4-6% of those applicants make it past the resume screen. The ones who do almost always have something extra on the resume — a portfolio, a GitHub profile, a published dashboard, or a write-up of a project they did on their own time. The reason is simple: a resume lists skills, a portfolio proves them. Anyone can claim 'proficient in SQL'. Far fewer can show a documented project where they wrote a query that found a real insight.
Here is what a portfolio is and is not. It is not a collection of every exercise you completed in every course. It is not a copy of your resume in PDF form. It is a small, curated set of 3 to 5 projects that each demonstrate one skill clearly and tell a short story about a real-world problem. Hiring managers do not have time to read ten projects; they will look at the one you lead with and skim the rest. Each project should be readable in 5-10 minutes, with the question, the data, the approach, the result, and the tools visible without scrolling.
The 3-5 project portfolio is also the right size because it is reviewable in 20-30 minutes, which is roughly the time a hiring manager allocates before deciding whether to bring you in for an interview. Smaller than that signals lack of depth; larger than that signals poor curation. Stick to the 3-5 number and you will land in the sweet spot of 'demonstrated skill without overwhelming the reviewer.'
When you are choosing which 3-5 projects to keep in your portfolio, apply the 'so what?' test to each one. If a hiring manager reads the headline and the answer is not obvious, cut it. If the project shows a skill but not a result, cut it. A portfolio project should answer 'so what?' in the first sentence: 'I analyzed customer churn and identified a $240K annual savings opportunity.' That is the format every project should follow.
The Four Project Types That Get Interviews
I have reviewed maybe 200 data analyst portfolios over the past few years, and the ones that get interviews cluster around four project types. If you build one project from each category, you will cover almost every question a hiring manager is likely to ask. Pick the topic you actually find interesting — a portfolio project you care about reads better than one you do for the sake of filling a slot. The four types below work because each one demonstrates a different core skill.
Pick a messy public dataset (a CSV from data.gov, a Kaggle dataset with known quality issues, or a sample from your current job if you can anonymize it). Show the raw data, document every issue you find (missing values, inconsistent formatting, duplicate records), write the cleaning steps in SQL or Python, and end with an exploration of the cleaned dataset: distributions, outliers, relationships. The skill signal: you can take messy real-world data and turn it into something analyzable. Most analysts spend half their time on this, and every hiring manager knows it.
Take a public dataset (NYC taxi trips, Spotify charts, hospital wait times) and find one non-obvious insight. The insight does not have to be world-changing — it just has to be something that is not obvious from a glance at the data. For example, 'Tuesday afternoons have 23% more cancellations than other weekday afternoons in the NYC taxi data' is non-obvious and shows you can interrogate data past the surface. The skill signal: you can ask a question the data can answer and explain the answer in plain language.
Build a small dashboard in Tableau Public, Power BI, Looker Studio, or Streamlit that lets the user explore a dataset interactively. Pick a domain you find interesting — sports analytics, music trends, public health — and let the user filter, sort, and drill down. A good dashboard tells a story with charts: the headline chart at the top, supporting charts below, and a written summary of the takeaways. The skill signal: you can communicate insights visually, which is the part of the job that requires no prompting from a manager.
Take a business question ('why are customers churning?', 'which marketing channel has the best ROI?') and walk through the full analysis: define the question, gather data, clean, analyze, recommend. The recommendation is the part most candidates skip, and it is the part that matters most. A hiring manager wants to know you can do more than analyze — you can suggest what to do with the analysis. The skill signal: you can take a vague business question and turn it into a concrete recommendation, which is what the job actually is.
Avoid the three project types that hiring managers see too often and skim past: Titanic survival prediction, Iris flower classification, and MNIST digit recognition. They show you completed a tutorial, not that you can analyze real data. Pick something less common — restaurant inspection scores in your city, library borrowing trends, public transit delays. The unusualness is what catches attention.
Where to Host Your Portfolio (and How to Make It Findable)
A portfolio that no one can find is the same as no portfolio at all. You need two things: a place to host the projects (a personal site, a GitHub profile, or both) and a way for hiring managers to get there from your resume. The good news is that most hosting is free, and the setup takes a weekend at most. Below are the three hosting patterns I see most often in successful portfolios, in order of effort from least to most.
Create a GitHub account with your real name (not 'codingwizard99'), pin your best 3-5 repositories to the top of your profile, and write a proper README for each project. The README should follow a standard structure: title, the question, the data source, the tools used, the approach, the result, and a 'how to run this locally' section. Hiring managers who click through to GitHub should be able to read the README and understand the project without running any code. This is the minimum viable portfolio.
Build a simple static site (GitHub Pages, Netlify, Vercel, or a low-cost portfolio platform) with one page per project. The site gives you a single URL to put on your resume, lets you include screenshots and short summaries, and lets a hiring manager browse without opening GitHub. Each project page should have: a 1-2 sentence summary, 1-3 screenshots of the output, the tools used, the GitHub link, and a 'read the full writeup' button. This is what serious candidates do.
Pick your strongest project and write a 1500-3000 word article about it: how you approached the question, what surprised you, what you would do differently next time. Medium has good SEO and gets found by other analysts — your writeup may end up ranking for a related search query. Include the GitHub link at the top and the chart screenshots throughout. This is the most effort but also the most differentiated — most data analyst candidates never write up their projects in long form.
Put your portfolio URL in the header of your resume, not the footer. Hiring managers skim, and a portfolio URL in the header is the first thing they look for after your name and target role. If your URL is in the footer with your address and phone number, most hiring managers will not bother to scroll. The header placement is a small detail that has outsized impact on click-through.
How to Write a Project Description That Sells
The biggest mistake I see in portfolios is that the projects are well-built but the descriptions are vague. A hiring manager reads 'this project analyzes customer data' and moves on. The same project with 'I analyzed 2 years of customer transaction data and identified 3 segments driving 80% of churn, leading to a $240K retention opportunity' is a different story entirely. The difference is in the format of the description, not the analysis itself. Below is the structure I recommend for every project writeup. Use it consistently and your portfolio will read like a professional analyst's work, not a course assignment.
A second reason descriptions matter: hiring managers often skim the description first and only click into the code if the description earns it. You have about 30 seconds of attention per project before the reviewer decides whether to dig in. If the description does not earn the click in those 30 seconds, the code never gets read — even if the code is excellent. The description is the gate; the project is the proof.
The first line of every project description should answer 'so what?' in plain language with a number. 'I reduced a 4-hour weekly reporting task to 15 minutes by automating the data pipeline with Python and SQL.' That is the headline. Everything below the headline supports it. A hiring manager who reads only the headline should learn something specific about your skill and impact. If your headline is 'an exploratory analysis of X', rewrite it — that is not a headline, that is a topic.
After the headline, write 2-4 short paragraphs covering: the data source (and any cleaning steps), the tools and languages used, the approach (how you framed the question, what techniques you applied), and the result in more detail. Keep it tight — 200-400 words total. The point is to show you understand the why behind the analysis, not just the how. Anyone can run code; fewer can explain why they chose that approach over alternatives.
Visuals matter more than text in a portfolio. Lead with the most important chart (the one that answers the headline question) and follow with 2-3 supporting charts. One code snippet — the part of the analysis that does the real work — is enough; you do not need to dump the full notebook. Pick the snippet that shows a technique the hiring manager would care about: a window function, a join with edge cases, a clean visualization. The code should be readable without explanation.
Read your project description out loud before you publish it. If you find yourself saying 'in this project I analyzed' or 'this analysis explores', cut the sentence and start over. Those are exactly the phrases that make a project read like a course assignment instead of a piece of analyst work. Replace them with 'I found that...' or 'I recommended...' — active verbs that put you, the analyst, in the story.
The Portfolio Checklist Before You Apply
Before you start sending out applications with your portfolio, run through this checklist. I have watched candidates lose out on interviews because of small oversights — broken links, projects with no README, screenshots that do not load. Most of these are 5-minute fixes. The checklist is ordered from 'must fix before applying' to 'nice to have if you have time'. Do the must-fix items first, and apply as soon as those are done. The nice-to-haves can wait.
Click every link in your portfolio and verify it loads. Open every GitHub repository and confirm the README renders properly. Test every dashboard URL and confirm it is not expired (Tableau Public free accounts expire if you do not log in for a long time — log in monthly to keep them alive). Hiring managers who hit a broken link assume the rest of your work is also broken, even when it is not.
Pull up your portfolio on your phone. About 30% of hiring managers and recruiters will look at your site on a phone first, according to a 2024 Workology survey. If the layout breaks or the text is unreadable on mobile, fix it before you apply. The fix is usually CSS — make images scale, set a responsive grid, and use a readable font size. Do not skip this just because you built the site on a desktop.
A short bio at the top of your portfolio site — 2-4 sentences covering your background, what you are looking for, and one or two non-work interests — humanizes the portfolio. Hiring managers remember the person behind the project, not just the project. The bio does not need to be fancy; it just needs to be a real human writing in first person. Skip the bio if you do not have time, but it is one of the easier differentiators.
Ask a more senior analyst friend or a Slack/Discord community (like the Locally Optimistic or r/dataanalysis community) to review one of your projects and give blunt feedback. The feedback will surface things you cannot see yourself — a confusing chart, an unclear takeaway, a missing piece of context. Even one round of peer review typically surfaces 3-5 improvements. Apply the fixes, then send the application.
Do not let 'perfect' be the enemy of 'applied'. A solid 3-project portfolio that is live and findable will get more interviews than an unfinished 8-project portfolio you are still tweaking. Ship the minimum viable portfolio and apply today. You can keep improving projects while you interview, and you will learn more from real feedback than from endless self-editing.
Five Portfolio Mistakes Hiring Managers Notice
After you have built the projects and hosted them, run through the common mistakes that make a hiring manager close the tab. None of these are technical errors — they are presentation errors. The good news: they are all easy to fix once you see them. The bad news: most candidates do not see them because they are too close to their own work. Treat your portfolio like a product you are selling, not a project you are shipping, and the mistakes become obvious.
If all 3-5 projects use the Titanic dataset or the same Kaggle competition data, the hiring manager concludes you have not done real analysis — you have done tutorials. Mix it up: one project on public transit, one on sports analytics, one on a domain-specific dataset from your current job (anonymized if needed). Variety shows breadth, and it shows you can pick up a new dataset and figure it out.
A project that says 'this is a logistic regression on X' is showing off a technique, not doing analysis. A project that says 'I used logistic regression to predict which customers are likely to churn, with 78% precision, leading to a recommended targeted retention campaign' is doing analysis. Always lead with the question and the result; mention the technique in the approach paragraph. The technique is the means, not the headline.
A typo in your project headline or a chart that does not load will cost you more interviews than a less impressive project done cleanly. Proofread every README, every headline, every project description. Run the charts through a tool like Hemingway or Grammarly if you are not a confident writer. Treat the portfolio like a writing sample, because to a hiring manager, it is one.
A hiring manager who loves your portfolio needs a way to reach you. Put your email address (or a contact form) at the top of every page. Link your LinkedIn and GitHub in a footer. The point is to remove any friction between 'this person looks great' and 'I want to email them right now'. If the hiring manager has to hunt for your email, half of them will not bother.
If your portfolio URL is not in the resume header, the hiring manager will not know it exists. I have reviewed resumes where the candidate had a great portfolio but did not list the URL — the hiring manager never knew to look. Put the URL in the header next to your name, format it as plain text (not a hyperlink), and double-check that it is clickable when the resume is saved as a PDF.
Send a thank-you note after every interview that references a specific project from your portfolio. 'Thanks for the conversation today — when you mentioned the customer segmentation question, I realized my portfolio has a project that goes deeper on that exact technique. Here is the link: [project URL].' That single follow-up converts interviews into offers at a much higher rate than a generic thank-you note, because it shows you were listening and gives the interviewer a reason to advocate for you internally.
