Building a portfolio that gets interviews

A portfolio that gets interviews states a business question, shows how you worked, and ends with a decision a hiring manager can trust. Seven ready-made dashboards (screens of charts) with no question behind them are just decoration. This post shows how to build the first kind.

Say you send a hiring manager a link to your portfolio. They find seven charts built on the same practice store data everyone uses, no question stated anywhere, and a README (the project’s main description page) that says “passionate about insights.” They close the tab within seconds.

What a portfolio is for, and what it is not

A portfolio is a set of work samples that lets a stranger trust your judgment before they meet you. It is not a museum of every chart you have ever made, and it is not a wall of certificates. It is also not a clone of a video course project that ends with the instructor’s conclusions.

A good portfolio answers four silent questions that every hiring manager carries.

1. Can this person frame a business question?
2. Can they handle messy data without hiding the mess?
3. Can they choose a method and explain it at the right level of depth?
4. Can they recommend a decision, or a next test, with the risks named?

Your best work may be locked inside an employer. You still need public stand-ins, such as sanitized case studies, public datasets with realistic constraints, open-source contributions, blog posts with runnable code, or internal write-ups you are allowed to share. “I cannot show anything” is a common feeling, but it is rarely a complete strategy.

The portfolio path

Build each flagship project along the same four-step path, because that path matches how good analysis works on the job.

1. Pick a question shaped like a decision

A weak question reads “Explore the superstore dataset.” A strong one reads “Should this fictional retailer expand same-day delivery to mid-size cities, and what risk would that create for margin?” In the same way, “Churn analysis” is weak, while “Which two save interventions should customer success pilot first for month-2 churn, given limited team time?” is strong.

Write the question in one sentence at the top of the README. If you cannot, the project is still a vibe. Tie the question to a role you want, such as product, marketing, finance, or operations, because hiring managers hire for the problems they have.

2. Use real-ish data

“Real-ish” means the data has enough mess to force judgment. Look for missing values, changing definitions, delayed events, duplicates, or sampling bias. Perfectly clean CSV (a plain spreadsheet-style text file) toys teach syntax, but they do not teach trust.

These kinds of sources work well.

• Public government or research datasets with a clear grain, meaning it is clear what one row stands for.
• Company-approved anonymized extracts.
• Synthetic data you generate with documented assumptions, which you should label as synthetic.
• Open product analytics dumps or competition data, reframed around a business decision you invent carefully.

Document the source, the grain, the refresh schedule, and the known holes. That documentation is part of the skill demo. Link it to the quality habits you would use at work, and see the data quality series for the vocabulary.

3. Method: readable, not theatrical

Show SQL (the standard language for asking a database for data), Python, or a business intelligence workbook that another analyst can follow. Prefer boring clarity over clever one-liners. Comment the joins that are not obvious, and state why you chose a cohort chart instead of a pie. If you use a model, explain the baseline you beat and what would prove the result wrong.

The depth of the method should match the question. Do not run a neural net to rank three marketing channels with two years of monthly data. Do not rely only on a pivot table if the role expects window functions and care with experiments. Match the reality of the job description, and skip the flexing you see on social media.

4. Decision write-up

End with a short memo that a manager could paste into Slack. It should hold four things.

• A recommendation, or “do not decide yet; run this test.”
• One to three numbers that matter.
• The risks, and what would change your mind.
• An ask, such as a pilot, a budget, better tracking, or a meeting decision.

This is the part most portfolios skip. It is also the part that shows the senior signals from the first post in this series, which are decision quality and not chart polish.

How many projects, and what mix

Three strong projects beat twelve thin ones. For most analyst roles, a practical mix is shown below.

You can add an optional fourth project: a small public contribution, such as a docs fix, a dbt package example, or an open dashboard (a screen of charts that tracks key numbers) with real users, if it shows you can collaborate. Optional really does mean optional, and depth comes first.

Worked example: one project scored like a hiring manager

The candidate project is titled “Reducing early churn for a subscription box,” and it uses a hybrid of public and synthetic data.

Question: Which two interventions should the customer success (CS) team, the people who help existing customers, pilot to cut the cancel rate between month 1 and month 2, without adding more than 10 minutes of team time per at-risk account?

Data: Public-ish order and subscription tables, plus a synthetic contact log from the CS team that is labeled as synthetic. The grain is documented as one row per subscription-month. There is one known hole, which is that cancellations after a failed payment may be under-tagged.

Method: A cohort retention table, a simple risk score built from tenure, skip rate, and contact history, and a ranking of save offers by estimated impact times effort. SQL builds the cohorts, and Python builds a transparent scorecard and not a black box.

Decision write-up (abridged): Pilot two things. The first is proactive contact at the first skipped box for long-tenure customers. The second is a one-time box customization for month-1 accounts with two or more skips. Do not pilot stacked discounts first, because the margin risk is high and the historical save rate is unclear. The success metric is a lift in month-2 retention, with CS minutes tracked, and the write-up includes kill criteria.

Now score it with a hiring-oriented rubric.

Here is a fuller self-score card you can keep in the repo.

Portfolio project scorecard (1-5)
Question is decision-shaped: _
Source and grain stated: _
Data problems acknowledged: _
Method matches question altitude: _
Code or workbook is navigable: _
Charts have takeaway titles: _
Recommendation + risks + ask: _
Could a stranger rerun the core pull: _

Red flags to fix before sharing:
- No question / only "EDA"
- Only screenshots, no logic
- Overclaims causality from observational data
- Confidential data leakage
- Identical to a public course notebook

If clarity and rigor are high, polish can be “clean enough.” If polish is high and the question is missing, rewrite the project before you restyle it.

Presentation logistics that reduce friction

• One hub link: use a personal site, a GitHub profile README, or a Notion index. Do not make recruiters hunt across five tools.
• Each project folder: put the README first, then the data dictionary, then the code, then the outputs.
• Time-to-value: put the decision memo above the fold, with the deep SQL below for the technical interviewer.
• Licenses and citations: credit your datasets, and do not paste proprietary schemas.
• Accessibility: readable charts use labels and not color alone, which follows the habits from the earlier post on inclusive data products. You are also demonstrating professional standards.

AI tools, courses, and integrity

Using AI to draft SQL or explain errors is normal at work. Portfolios made only of AI-generated prose and unrun code get caught in technical screens. A few rules of thumb keep you safe.

• You must be able to explain every join and filter live.
• Run the code, and show outputs that match.
• If AI helped, your judgment should still be visible in the problem framing and the caveats.
• Course projects are fine as starting points. Change the decision, the data constraints, and the write-up so that the thinking is yours.

For SQL quality habits that carry over into interviews, the site’s SQL series and the practical check in how to check AI-written SQL are useful companions. For a wider skill map, use Learn.

Employed analysts: internal portfolios

If you are not job hunting, still keep a private “promotion portfolio.” It holds the metric specs you own, incidents you prevented, documents that span several teams, before-and-after examples of clearer definitions, and decision memos. It follows the same path with a different audience. Public polish matters less here, and evidence of your scope, as the first post in this series described, matters more.

When you do go public, rewrite internal work as sanitized cases. Change the numbers, remove customer names, and get approval when it is required. Never “anonymize” by hope alone.

Common mistakes

• Dashboard galleries without questions: pretty is not a decision.
• Twelve thin projects: three deep ones interview better.
• Hiding the data mess: clean screenshots without an issue log look naive.
• Method theater. Complex models for simple decisions signal poor judgment.
• No recommendation. Analysis that ends at a chart forces the reader to do the work.
• Confidential leaks. This is an instant disqualifier and a real ethics failure.
• Unrunnable repos. Broken paths and missing packages waste an interviewer’s goodwill.
• Ignoring the role. A pure research notebook (a document that mixes code, results, and notes) for an operations analytics seat is a mismatch.

Quick recap

• Portfolios exist to show judgment under ambiguity, and not to display every chart.
• Build projects as a question, then real-ish data, then a method, then a decision write-up.
• Three deep projects with role fit beat a dashboard museum.
• Weight clarity and rigor far above polish.
• Document the mess, the grain, and the risks, and end with an ask.
• Protect confidential data, and make public work explainable live.

How to practice this week

1. List every public artifact you already have, and archive anything that has no question behind it.
2. Write three decision-shaped questions for roles you want, and pick one, because a project built around a decision shows how you think, not just what tools you know.
3. Choose a real-ish dataset, and write down the grain and the known holes before you plot anything.
4. Build the thinnest possible path to a decision memo, even if the charts are rough.
5. Score the draft with the clarity, rigor, and polish rubric, and fix the high-weight gaps first.
6. Ask one working analyst to skim it for 10 minutes and tell you what they still do not understand, because a fresh reader finds the gaps you can no longer see.
7. Publish the hub link only after the README stands on its own.

The next post in this series covers storytelling that earns senior trust, including a simple email skeleton for recommendations made under uncertainty.

Series notes

This is Part 2 of Analyst career path.

Sources

• GitHub Docs. “About READMEs” (baseline for making projects navigable). https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-readmes
• US Bureau of Labor Statistics. Occupational outlook materials for data/analytics-adjacent roles (context on skills employers list; not a portfolio recipe). https://www.bls.gov/ooh/
• Google. “re:Work” hiring resources (structured interviewing ideas that reward evidence over vibe). https://rework.withgoogle.com/
• Curious Elephant / common open dataset indexes such as Google Dataset Search for finding real-ish public data. https://datasetsearch.research.google.com/
• dbt Labs blog and docs on analytics engineering workflows (example of project structure that reads professionally). https://docs.getdbt.com/docs/introduction

Merch on Etsy

Open store →

You're On Mute Coffee Mug – Data Science Gift View on Etsy → Git Version Control Shirt View on Etsy → Naive Bayes Coffee Mug View on Etsy → Apache Hadoop T-Shirt View on Etsy →