For data and analytics candidates, the projects section is doing more work than almost any other resume zone. Recruiters and hiring managers in data roles spend disproportionate attention there — sometimes more than on the work history itself — because the projects section is where they can see how you actually think.

This post is about what hiring managers look for in that section, and what they consistently skip.

What hiring managers actually scan for

The first pass is keyword-heavy. Specific tools (SQL, Python, dbt, Snowflake, Looker, Tableau), specific methods (A/B testing, causal inference, time-series forecasting), specific platforms (BigQuery, Databricks, Airflow). These are the entry-ticket items — they confirm you've worked with the actual stack the company runs.

But keywords alone don't get you to the phone screen. The second pass — and the one that decides — is whether each project also names a business decision and an outcome. A bullet that says "performed A/B testing using Python" passes pattern matching but fails the read-through. A bullet that says "designed and analyzed onboarding A/B test (n=82k, p<0.01) that informed permanent ship and lifted activation 6%" passes both.

The split between the two lists isn't subtle. The "matched" column is what a parser sees and a recruiter skims for. The "missing" column is what the hiring manager actually reads. Both have to be there.

For the broader keyword discussion, see ats-keywords-vs-recruiter-keywords.

The bullet pattern that works

The pattern in the "opens doors" column is consistent: specific number + specific tool + specific outcome. Each bullet has at least two of the three; the strongest have all three.

Compare:

• Weak: "Performed data analysis using Python and SQL to extract insights from large datasets."
• Strong: "Built a churn model on 2.4M user-months — drove retention experiment that lifted day-30 by 4.1%."

The strong version takes the same project and adds three things: the dataset scale (2.4M user-months), the action it enabled (retention experiment), and the outcome (4.1% lift on a real metric). It's not longer; it's more specific. The vague version could be written by any analytics candidate; the specific version could only be written by you.

For the underlying quantification work, see quantifying-resume-without-metrics.

A specific anti-pattern: "experience with" or "familiar with" phrasing. "Familiar with TensorFlow" reads as a candidate who tried a tutorial. Either you've built something with it (in which case, describe the build) or you should leave it off. The "familiar with" line consumes resume real estate without adding signal.

The three-project structure

If you're going to invest in a projects section, three is the right number. Two reads as thin; five-plus reads as a list-of-tutorials. Three lets you cover the three dimensions hiring managers worry about for analytics hires.

Project 1 — Business-decision project. The headliner. Pick something where your analysis directly influenced a decision and you can attach a number to the outcome. "Recommended pricing change after elasticity analysis on 6 months of transaction data; new pricing rolled out and grew Q3 revenue 9%." Read in 4 seconds; demonstrates the highest-value thing analytics people do.

Project 2 — Technical-craft project. Pick something that shows depth in your strongest area. If you're an ML-leaning analyst, an end-to-end model with deployment notes. If you're a SQL-heavy analytics engineer, a dbt or data-platform project with runtime / cost metrics. If you're causal-inference focused, a diff-in-diff or synthetic-control design. This is the project the hiring manager will probe in the technical interview.

Project 3 — End-to-end ownership project. Something you took from problem-definition through final stakeholder presentation. This is the project that demonstrates judgment, scope, and communication — the things resume bullets struggle to convey directly. "Defined retention metric for $LAST_COMPANY's product team, built monthly cohort reporting, presented to leadership in QBRs — became standard input to roadmap." This bullet is doing more work than its words suggest.

Where the projects section goes on the page

For experienced analytics candidates (3+ years), the projects section sits below work experience and above education. Two or three projects, each with 2-3 bullets, fits well.

For candidates with thin or non-traditional backgrounds (bootcamp grads, career-changers, recent grads), the projects section can sit above work experience as the lead section. In this case it's doing more work — you might run four projects rather than three, and the bullets are tighter. The first project on the page becomes the headline the recruiter reads first.

For career-changers specifically, see career-change-resume.

What to skip

A few things candidates put in this section that almost never help:

• Tutorial projects. "Built a Titanic classifier" or "Iris dataset clustering" reads as having done one Kaggle weekend. If you must include early work, frame it as a learning artifact rather than a portfolio piece.
• Long lists of small projects. Five projects with one bullet each look weaker than three with three bullets each. Depth beats coverage.
• Reference architecture diagrams. Save these for the portfolio site if you have one. Resume bullets carry them poorly.
• Skills bars and proficiency dots. Most ATS systems strip them; most hiring managers ignore them. The skills section, if you have one, should be a clean comma-separated list.

For the resume-skills-section pattern, see resume-skills-section-structure.

What about open-source contributions?

If you've contributed meaningfully to data tooling (dbt-core, Airflow, Great Expectations, sklearn, etc.), put a short line in the projects section. Link the PR or the project page if your resume is going to a recruiter who'll click through. One line is enough — the link does the rest.

If your contributions are small (single typo fixes, README updates), leave them off. The bar is "would the maintainer recognize the contribution as substantive."

For the broader open-source positioning, see open-source-contributions-on-resume.

What this isn't

A few clarifications:

• It's not a portfolio. The resume projects section is a teaser, not the work itself. Link to a portfolio site, GitHub, or write-ups if hiring managers want depth.
• It's not the same for every data role. Analytics engineer, data scientist, ML engineer, BI analyst — each role weights the three projects differently. Adjust which one leads based on the JD.
• It's not a substitute for the work-history bullets. Strong projects can compensate for a thin or non-linear work history. They don't replace strong work history when you have one.

The short version: three projects, each with a specific number, a specific tool, and a specific outcome. One business-decision project to lead, one technical-craft project for depth, one end-to-end ownership project for judgment. The pattern that works isn't about volume — it's about specificity. Every bullet should be one a generic candidate could not have written.