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.

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:

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.

Open your portfolio repo. Can you answer "what did this person investigate, what did they find, and why does it matter" without scrolling past the README fold? If not, the hiring manager can’t either, and they’re not going to work harder than you did.

The one-screen test

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.

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:

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."

caseSQL missions are great for learning the muscle of messy-data SQL, but they’re the sparring partner, not the fight. A hiring manager looking at your portfolio wants to see work on data _you_ picked, a question _you_ framed, and a finding _you_ stood behind. Use the missions to get good; then point at projects you owned end-to-end.

One mission is not a portfolio

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."

The analyst portfolio that converts cold applications into phone screens — three specific project types, a concrete repo shape, and the writeup template hiring managers read.

Building a Data Analyst Portfolio That Gets Interviews | caseSQL

Building an Analyst Portfolio That Gets Interviews

If you’re reading this as a nurse, a teacher, a bartender, an ops coordinator, an accountant, a bench scientist, or anything else that isn’t "software engineer": good news — the data analyst path is open to you, and has been for years. The credential gatekeeping you may have been warned about applies almost entirely to software engineering, not analytics. What actually matters for analytics hiring is a mix of SQL literacy, judgment under ambiguity, and the ability to explain a number to a non-technical stakeholder. None of those require a CS degree. Two of them are _easier_ to acquire if you already have another career under your belt.

You don’t need a CS degree to write SQL

SQL is declarative. You describe the result you want; the engine figures out how to get it. That sentence is the reason the language is learnable in weeks rather than years, and the reason analytics hiring doesn’t filter on the same signals software engineering does.

Compare that to a typical software role, where you’re expected to reason about memory, concurrency, testing frameworks, deployment pipelines, and a stack-specific language idiom. That stack is what the CS degree quietly teaches, and why bootcamp-to-SWE transitions take so long. None of it is in the analyst job description.

What’s actually in the analyst job description: write a query, understand the business context of the result, communicate the result to someone who doesn’t know SQL. If you came from a role that involved explaining complicated things to stakeholders — healthcare, education, operations, client services — you already have half the job. You just need the query-writing half.

I’ve been on the interview panel for analyst roles at three companies. The signal hiring managers weight most heavily isn’t clever SQL. It’s _trustworthy SQL_. Two questions run in the background of every interview:

That’s it. Everything else — window functions, dialect trivia, query optimization — is a distant second. Which means your job as a career changer is to build evidence of _judgment_, not syntax mastery. A portfolio that shows "I can write a medium-complexity query, and here are the assumptions I wrote down next to it" beats a portfolio of 50 LeetCode-style SQL puzzles, every time.

Ex-teachers and ex-clinicians do disproportionately well in analyst hiring once they have the SQL chops. The reason: both professions involve explaining something technical to a non-technical audience under time pressure. That muscle is exactly what "present this number to the VP of marketing" needs.

The underrated signal

Full disclosure: 90 days only works if you can sustain 8–10 hours per week of focused practice. If you can do more, it accelerates. If you can do less, just stretch the plan — the sequence matters more than the calendar.

**Weeks 1–3: Core SQL syntax.** SELECT, WHERE, GROUP BY, the six join types, subqueries, CTEs. Use one free resource all the way through rather than hopping — consistency compounds. By the end of week 3, you should be able to write a query that joins three tables, aggregates a numeric column, and filters the result, without looking things up.

**Weeks 4–6: Window functions and dirty data.** ROW_NUMBER, RANK, LAG, LEAD, running totals. Simultaneously, start practicing against a dataset that has real-world problems — NULLs, duplicates, bad dates. The caseSQL starter path is designed for exactly this window.

**Weeks 7–9: Open-ended problems.** Stop doing puzzle-style exercises. Start picking questions like "how is the business doing" and forcing yourself to write a full analysis — assumptions, query, result, one paragraph of commentary. Quality over quantity: one full analysis a day beats five puzzle solutions.

**Weeks 10–12: Portfolio and interview prep.** Pick 3 of your analyses and polish them into shareable form. Set up a GitHub repo, write a short README for each, put them in order. In parallel, start doing mock interviews — ideally with a working analyst friend, but even narrating your thought process out loud into a voice memo helps.

The single biggest unlock for career changers is realizing that a portfolio doesn’t require a data job to build. You need three things: a public dataset, a notebook or markdown file that shows your work, and a GitHub repo that hosts it. That’s it.

Good public datasets for analyst portfolios: NYC TLC trip data (taxis), the Citibike dataset, the Nashville housing dataset, the Brazilian Olist e-commerce dataset, any of the Kaggle marketing or retail datasets. Pick one. Spend two weeks on it. Produce a portfolio piece.

What makes a portfolio piece senior-looking, not junior-looking:

That structure is the best signal you can send that you think like an analyst, not like a student. Three of those in a public repo outperforms twenty LeetCode solutions in every screening conversation I’ve sat in.

Most analyst interviews have four stages: a phone screen (resume-walk + why-analytics), a SQL screen (live coding, 45–60 min), a case study (open-ended business question, take-home or 90-min on-site), and a behavioral round (collaboration, communication, handling ambiguity).

The SQL screen is the one people stress about, but it’s rarely the stage that kills candidates. The case study is. Case studies are where tutorial-SQL trained candidates fall apart — they can write the queries but can’t handle the ambiguity of the prompt.

Practice the case study explicitly. Give yourself a business prompt (search "data analyst case study interview" for sample datasets and prompts), set a 90-minute timer, and produce a deliverable: 1 summary slide, 2–3 supporting charts, 4–5 bullet points of insight. Do three of these before your first real interview and the format will stop feeling foreign.

The interview signal those three queries send together: you think about _arguments_ not just queries, you understand trend + efficiency + mix as the three legs of a growth story, and you know when to compare windows rather than just aggregating one. That’s the career-changer advantage — you already know how to tell a story to a non-technical audience, you’re just learning a new medium.

Things career changers worry about that don’t matter

I’ve coached a few dozen career changers through analytics job searches, and the same three non-problems eat up 80% of their anxiety. None of them are worth the time:

What matters instead: you can write a query against a real schema without peeking at a tutorial, you can talk about a number without jargon, and you have one polished portfolio piece that demonstrates both. That’s the bar.

Realistic timelines for a career change into analytics, assuming no prior data experience: 3–6 months of focused part-time practice to be interview-ready, 2–4 months of active job search after that. Full-time study compresses the first number; a lucky network warm intro compresses the second. Don’t quit your day job on week one.

The numbers on timing

You don’t need a computer science degree to become a data analyst. A concrete 90-day plan, portfolio strategy, and interview breakdown for career changers.

Career Change

Building an Analyst Portfolio That Gets Interviews

SQL for Career Changers: No CS Degree Required