Portfolio Projects for Data Analyst

You have finished another online certificate and your resume still looks the same as everyone else's. Reviewers skim past certificates in seconds, because a completed course tells them nothing about how you think. Projects do.

Three well-built projects beat a wall of badges every time. Not five, not ten. Three projects where you made the decisions, wrote the analysis, and can defend every choice.

What reviewers actually look for#

A hiring manager or a senior analyst reviewing your portfolio is hunting for four signals. Can you frame a question? Can you clean a messy dataset without supervision? Can you explain what the numbers mean to someone who does not code? Can you be honest about what the data cannot show?

They do not expect production-grade pipelines. They expect judgment. A small project where you spotted a data quality problem and handled it beats a huge dashboard built by following a video line by line.

Most reviewers spend under two minutes on a portfolio. They open the README, scan the charts, and check whether the conclusion matches the evidence. If the first screen is a wall of setup instructions, they close it.

Project one: a messy public dataset with a real question#

Pick a dataset with genuine dirt in it: nulls, inconsistent categories, duplicate records, columns typed as text that should be numbers. Government open data portals are full of these. Then ask a question that a real person would ask, like "Did the city's pothole repair backlog get worse after the budget cut?"

The work here is the cleaning. Document it. Show the before and after, show how many rows you dropped and why, show what you did with missing values. This is the part that separates analysts from people who can run a tutorial.

Worked example: how to write it up

Weak bullet on a resume: "Analyzed pothole repair data using Python and pandas."

Strong bullet: "Cleaned 48,000 rows of city pothole repair records, standardizing 14 inconsistent neighborhood labels and flagging 2,300 records with missing completion dates, then showed median repair time rose from 9 to 17 days after the FY budget cut."

The second one names the dataset size, the specific problem, the method, and the finding. That is what a reviewer wants in ten seconds.

Project two: a dashboard someone could actually use#

Build one dashboard around a decision, not around a chart gallery. A retail manager deciding where to cut inventory, a nonprofit deciding which outreach channel works, a clinic deciding when to staff up. Pick the decision first, then pick the three or four charts that support it.

Use Tableau Public, Power BI, or a simple Streamlit app. The tool matters far less than the layout. Put the headline number at the top, keep filters obvious, and label axes so a non-analyst can read them.

Publish it publicly with a share link. Then write a short README that states the decision it supports, the data source, the refresh cadence, and one thing the dashboard cannot tell you. That last line builds more trust than a polished color scheme.

Project three: an analysis you wrote for a human#

This is the project almost nobody does, and it is the one that gets people hired. Write a short memo, 600 to 900 words, that takes your findings and argues for a specific action. Charts in the middle, plain language around them, a recommendation at the end.

Analysts get paid to change decisions. A memo proves you can do the part after the SQL. If you can write it so a busy operations lead reads to the end and says "ok, do it," you have the skill that certificates never teach.

How to present them on GitHub#

Your repository is a storefront. The README is the window display.

• Name the repo after the project, not "data-analysis-project-2" or "bootcamp-week-7"
• Open the README with one sentence stating the question and one sentence stating the finding
• Put the three best charts near the top, right after those two sentences
• List the data source with a working link and the date you pulled it
• Show a short data dictionary so a reviewer knows what the columns mean
• Describe your cleaning steps in plain language, with counts
• Include a limitations section with at least two honest caveats
• Keep raw data out of the repo if it is large; link to the source instead
• Pin your three best repos and unpin the rest
• Make sure every notebook runs top to bottom without errors

Commit history matters more than people think. Small, frequent commits with clear messages show a working habit. One giant commit called "final" shows the opposite.

How to list them on a resume#

Do not create a separate "Portfolio Projects" section buried at the bottom. Fold the best project into your experience section, or create a short "Selected projects" section right under your summary.

Each entry needs three lines: the project name and context, one or two bullets with numbers and findings, and a link. Use a URL shortener or a clean text link so the resume stays readable in plain text and in an applicant tracking system. If you want to check how your resume parses before you send it, run it through a free ATS checker.

Quantify where you can. Row counts, hours saved, percentage change in a metric, number of stakeholders who used the dashboard. If you have no users yet, say "built for a simulated case" rather than inventing adoption numbers.

Mistakes that make projects look like tutorials#

The single biggest tell is a README that reads like a course assignment. "In this project we will explore the Titanic dataset" is a dead giveaway. So is a perfect dataset with no cleaning notes.

Other tells to fix:

• The question is generic ("explore the data") instead of specific
• Every chart is a default matplotlib plot with no titles or annotations
• There is no conclusion, just "further analysis could be done"
• The notebook has 40 cells of exploratory plots with no narrative
• The project name matches a well-known tutorial exactly
• The analysis finds nothing surprising and does not say so
• There is no mention of data quality problems, even though real data always has them

If you built along with a course, that is fine. Change the dataset, change the question, redo the analysis, and rewrite the README in your own voice. Then it is yours.

How to talk about them in interviews#

Expect the question "walk me through a project." Have a 90-second version ready, and a 5-minute version behind it. Lead with the question, not the tools.

Sample answer, 90 seconds

"I wanted to know whether the city's pothole repair backlog got worse after the FY budget cut, because I saw the council debate it without data. I pulled 48,000 repair records from the open data portal, and the first thing I found was that neighborhood names were inconsistent across years, so I built a mapping table to normalize 14 variants. After cleaning, median repair time went from 9 days to 17 days post-cut. The caveat I want to flag is that the data does not record when a complaint was filed, only when work started, so the true backlog is probably worse than what I measured. My recommendation in the memo was to add a complaint timestamp to the intake form."

Then stop talking. Let them ask the next question. Candidates who monologue for five minutes lose the room.

Have answers ready for three follow-ups: what you would do differently, what data you wish you had, and how you checked your work. Saying "I would add a seasonal control, because pothole repairs spike in spring and the budget cut happened in winter" shows analytical maturity.

What to do before you publish#

• Run every notebook from scratch on a clean kernel before you link to it
• Check every external link in your READMEs, twice
• Read each README out loud to catch jargon and filler
• Ask one non-technical friend to read your memo and tell you the recommendation
• Remove any project you cannot speak about for five minutes without notes
• Search live roles to see which tools and datasets are showing up in job posts near you

Three projects, done properly, will outperform ten half-finished ones. Spend the time on depth.

Free tools#

• jobrise.io/en/free-ats-checker/
• jobrise.io/en/free-jd-decoder/
• jobrise.io/en/jobs/
• jobrise.io/en/blog/

FAQ#

How many portfolio projects do I need as an entry level data analyst?

Three is enough if each one is complete and defensible. Reviewers would rather see three projects where you made real decisions than eight that look copied.

Should I use a personal website or just GitHub?

GitHub alone is fine for most data analyst roles. A simple site helps if you want to publish the memo project in readable form, but a messy site is worse than no site.

Can I use datasets from a bootcamp or course?

Yes, but change the question and rewrite the analysis in your own voice. If the README still reads like the course assignment, reviewers will treat it as one.

How current do my projects need to be?

Refresh the data at least once a year, and update the README date when you do. A project built on a five-year-old extract with no note about it reads as abandoned.

Do I need to publish the raw data in my repository?

No, and often you should not. Link to the source, note the pull date, and include a small sample or schema so a reviewer can verify the shape without downloading gigabytes.