Building an Analyst Portfolio That Gets Interviews

Career changers in analytics have a portfolio problem that engineers don’t. An engineer can point at a shipped app and the reviewer knows what they’re looking at. An analyst can point at a Jupyter notebook with a Seaborn heatmap — and the reviewer has no idea whether that represents four hours of work or four weeks, whether the insight was real or reverse-engineered from the chart. This post is the shape of a portfolio that closes that gap.

What hiring managers actually look at

Hiring managers reviewing analyst portfolios spend about two minutes per candidate before they decide phone-screen-or-not. In that two minutes, they’re looking for three things, in order:

1. Can this person frame a question? (The README answers "what did you investigate and why.") This is the first and usually the last filter.
2. Can this person write SQL that a real team would let past code review? (Formatting, CTE use, comments, grain awareness.)
3. Can this person tell me what the answer means? (The writeup, not the chart.)

Charts get zero of the two minutes. Notebook output cells with long tracebacks get zero. A 14-plot dashboard with no commentary gets zero. What gets the minute is a well-written README with a clear question, one or two charts that answer it, and a short paragraph about what the charts imply about the business. That’s the whole package.

The three projects that carry a portfolio

You don’t need six projects. You need three, each one answering a different question about you. One-a-piece on skill depth, domain fit, and judgment under ambiguity.

Project 1: Depth project (proves you can write SQL)

A focused investigation of a single, specific question against a real-ish dataset. The goal is to show a hiring manager that you can write SQL with enough skill that they wouldn’t rewrite it in code review. Vintage-curve analysis, cohort retention, month-over-month variance decomposition — any of these are good picks. The topic matters less than the quality of the query and the writeup.

Project 2: Domain project (proves you fit the role)

Pick the industry you’re trying to break into and investigate a question a working analyst in that industry would get on a Tuesday. Marketing: "why did conversion drop in the second week of the campaign?" Healthcare: "which providers are outliers on length-of-stay after controlling for case mix?" Finance: "reconcile journal entries against GL balances for March 2024." This project is the one that makes a hiring manager believe you’ve read about their world, not just general analyst work.

Project 3: Judgment project (proves you think)

Take a dataset that’s intentionally flawed — a Kaggle set with known quality issues, or a public CSV with obvious dedup problems — and write up what you found, what you fixed, what you chose not to fix, and why. This is the project that proves you have the senior-analyst instinct of noticing what’s wrong with the data before you answer with it. It’s also the hardest to fake, which is why hiring managers weight it heavily.

The repo shape

One GitHub repo per project. Not one monorepo with three subfolders — three links on your resume makes each project its own discrete thing. Inside each repo:

• README.md — the question, the answer, the chart, the caveat. No "this was a fun project to explore." Lead with the finding.
• sql/ — numbered files (01_setup.sql, 02_cohorts.sql, 03_final.sql). Each one is a top-of-file comment explaining why this file exists.
• notebooks/ OR charts/ — pick one. Don’t ship both. Charts as PNGs with captions beats a notebook 100% of the time for hiring-manager skim.
• data/ — either a pointer to the public source OR a small sample CSV. Do not commit 50MB of parquet.
• Makefile or run.sh — one command that regenerates everything from scratch. This is the "can this person ship" signal. Makes you look senior immediately.

Writing the README that gets the interview

The README is the entire hiring signal. Structure it as four sections. No more, no less.

# [Project title — a finding, not a topic]

## The question
[One paragraph: what did you investigate, why is it worth investigating,
 and what would a good answer look like.]

## The answer
[2-3 sentences with the actual finding, with a number in it.]
[ONE chart. Captioned.]

## How I got there
[5-10 bullets walking through the query logic. Link to the SQL files.]

## What I’d do next
[2-3 bullets. This is where you signal "I know what I don’t know."]

The "what I’d do next" section is the one that surprises career changers. Including it makes you look junior-but-aware — exactly the right positioning. Leaving it out makes you look like you either think the project is done or don’t see the limits. Both are worse than honest "here’s what I’d investigate next if I had another week."

Three projects. Three repos. Three READMEs that tell three different stories about you. That’s the whole portfolio. It takes most career changers two focused weekends to build — and it’s the difference between "no response from the 40th cold application" and "three phone screens in the first week."