Writing a Data Scientist resume that lands interviews

Why a DS resume needs its own playbook

A Data Scientist resume is not a software engineer resume with statistics swapped in. A recruiter at Stripe or Airbnb spends roughly 30 seconds scanning your one-pager, and an applicant tracking system spends zero — it scans for tokens. If a hiring manager cannot tell within those thirty seconds what models you shipped, what scale they ran at, and what business metric moved, your resume gets stacked next to 600 others and the screen never happens.

The trap is that DS roles span a wide stack — classical ML, deep learning, causal inference, recommender systems, LLM evaluation — and most candidates either dump every library they have ever imported (the keyword-spam approach) or write a vague "led data-driven projects" narrative that an ATS cannot parse. The resume that wins shows measurable impact (a metric that moved by a number), an explicit technical stack (Python, PyTorch, MLflow, Snowflake — named, not implied), the scale of deployment (10M+ daily predictions, not "production system"), and an end-to-end story from problem framing to monitored deploy.

This is the version of the post that assumes you want to land screens at companies that pay levels.fyi-grade compensation, not just get a callback.

The skeleton that survives ATS

Most US tech ATS pipelines (Greenhouse, Lever, Workday) parse PDFs into plain text and run keyword matching against the job description before a human ever opens the file. That means the structure has to be flat and the tokens have to be exact — "scikit-learn" and "sklearn" are different strings to a regex.

Use this top-to-bottom order:

1. Header — name, target title, email, LinkedIn, GitHub, city/timezone.
2. Summary — three to five lines, dense with nouns.
3. Skills — categorized, scannable, ATS-friendly.
4. Experience — reverse-chronological, bullets with metrics.
5. Projects — for junior/mid; optional for senior+.
6. Education — degree, school, graduation year, relevant coursework only if recent grad.
7. Additional — publications, talks, certifications worth naming.

A header example for a mid-level DS targeting US tech:

Jane Doe
Data Scientist · Mid-level · San Francisco, CA (open to remote)
jane@example.com · linkedin.com/in/janedoe · github.com/janedoe

The summary is where you lose or keep the recruiter. Bad: "Experienced data scientist passionate about machine learning and impactful projects." That sentence could describe 40,000 applicants. Good: "Data Scientist with 4 years building recommender and ranking models at consumer scale. Shipped a two-tower retrieval model serving 50M weekly active users with +12% click-through in a holdout A/B. Stack: Python, PyTorch, Spark, MLflow, Snowflake."

Notice what the good version does: it names the model family, the scale, the lift, and the stack in two sentences. An ATS sees PyTorch, Spark, MLflow, Snowflake, recommender, A/B. A human sees a concrete story.

Keyword table: what recruiters grep for

ATS keyword matching is the first filter at most US tech companies, and the keywords are not secret — they are the bolded skills in the job description. The table below is a starter set for Data Scientist roles in 2026. Include the ones you have actually used; do not stuff.

A few rules for using this table. First, mirror the job description's exact spelling. If the JD says "scikit-learn", do not write "sklearn" — write both, separated by a slash, or pick the one they used. Second, group skills by category in your resume, not as a flat comma-soup; recruiters scan categories faster than walls. Third, only list what you can defend in a 20-minute conversation. A senior DS at Meta will absolutely ask why you put JAX on there.

Bullet rewrite: before and after

The single highest-leverage edit you can make to a DS resume is rewriting weak bullets into metric-anchored ones. Below are real patterns I see almost every week, paired with the rewrite that lands screens.

The pattern: verb → artifact → scale → metric movement → stack. Strip adjectives. Strip "responsible for". Strip "helped with". You either shipped it or you did not. If you genuinely only contributed to part of a system, name your part — "owned the feature engineering and offline eval for the ranker" is honest and still strong.

Project metrics that move recruiters

Personal projects matter most for junior and early-mid candidates, and they matter in a specific way: a recruiter wants to see end-to-end ownership, not a Kaggle leaderboard rank. A notebook with 0.94 AUC on a static dataset is an experiment. A project becomes resume-grade when it has a deployed surface (an API, a Streamlit demo, a Discord bot), versioned data and models (DVC or MLflow), and a README that frames the problem in business terms.

Pair every project with two layers of metrics — model quality and business proxy.

A project bullet that hits all three layers looks like this: "Built end-to-end book recommender (PyTorch two-tower, FastAPI, Docker, deployed on Fly.io); offline NDCG@10 = 0.41, demo A/B against popularity baseline showed +22% click-through on n = 800 synthetic sessions; p95 latency 38 ms at 50 RPS." That is a junior resume bullet that signals senior-grade thinking.

A Kaggle silver medal is fine; a deployed project with a public URL is better.

Common pitfalls

The first pitfall is listing tools without projects to back them. A "Skills" section that names Kubernetes, Ray, Spark, Kafka, Airflow, MLflow, Feast, Iceberg, dbt is suspicious if Experience never mentions any of them with an artifact. Recruiters call this "buzzword bingo" and screeners will ask cold questions about three of them at random. The fix is to only list a tool if at least one bullet under Experience or Projects names something you built or shipped with it.

The second pitfall is adjectives instead of numbers. "Significantly improved model accuracy" is filler — every applicant claims significant improvement. Replace every adjective of size or quality with a number, even a rough one. If the gain was small, say so honestly: "modest +1.8% conversion at p = 0.04, shipped as Phase 1 of a longer rewrite". Hiring managers respect calibrated numbers more than inflated ones.

The third pitfall is the jupyter-only portfolio. If your GitHub is forty notebooks with no README.md, no requirements.txt, no Dockerfile, and no deployed endpoint, the reviewer assumes you have not shipped anything. The cheapest fix is one good project: one repo, one README that explains the problem and the result, one Makefile or docker compose up, one screenshot, one live demo URL. One done-well repo outweighs ten half-done notebooks.

The fourth pitfall is resume length. Junior DS resumes should be one page. Mid-level one to two. Senior and staff two pages, very rarely three. A three-page resume from a candidate with four years of experience signals poor prioritization, which is itself a senior-DS red flag. Cut the oldest experience, cut coursework if you graduated more than five years ago, cut the "Interests" section entirely.

The fifth pitfall is ignoring the ATS layer. Fancy two-column resumes in Canva or Figma look great to humans and parse like garbage to Workday. Stick with a single-column PDF exported from a LaTeX template or a Google Doc. Test it: copy-paste the PDF into a plain text editor. If the order is scrambled or skills get glued to the wrong company, the ATS is reading it the same way.

Related reading

• Data Engineer resume guide
• Writing a resume without analytics experience
• MLflow and DVC — data science interview
• Feature store — data science interview
• Cross-validation strategies — data science interview

If you want to drill the kind of DS interview questions that follow a strong resume — sklearn pipelines, PyTorch debugging, A/B test design, MLflow tracking — the NAILDD question bank is built around exactly this pattern.

FAQ

How many pages should a Data Scientist resume be?

One page for junior (0-2 years), one to two for mid-level (2-5 years), two pages for senior and staff. Three pages almost always signals you did not edit. Hiring managers at Google, Meta, and Stripe all use roughly the same heuristic — if it does not fit on two pages, you did not prioritize, which is itself a senior red flag.

Do I need a GitHub link?

Strongly recommended for junior and mid-level, optional for senior. The GitHub does not have to host everything — one pinned repository that is end-to-end (clean README, runnable code, deployed demo) outperforms twenty half-finished notebooks. Recruiters absolutely click through; an empty or messy GitHub is worse than none.

Should I include a Kaggle rank?

Include it if you have a medal (bronze and up) or a top-1% finish, especially on a competition relevant to the role. One line under Projects is enough. Do not center your resume on Kaggle alone — hiring managers know competition data rewards leaderboard-chasing that does not translate to production. A medal plus one deployed project is the sweet spot.

How do I write a resume with under one year of DS experience?

Lean hard on projects, publications, and adjacent experience. Reframe any prior analytics, software, or research work that touched ML as DS-flavored bullets — "built a churn model in SQL + Python and presented results to product" counts even if your title was Data Analyst. Add a Projects section with at least one deployed end-to-end build. Coursework gets more weight at this stage, especially in ML, statistics, or causal inference.

Should I list salary expectations on the resume?

In the US tech market, no — never on the resume. Salary gets negotiated after the loop, ideally after a verbal offer. The exception is a required salary field on an application form; in that case, research the band on levels.fyi and write the top of the band as a single number.

What about the "Skills" section if I have used a tool only once?

Would you survive a 15-minute screen on it? If yes, list it. If you used a tool in one university project two years ago and have not touched it since, leave it off. A short, defensible Skills section beats a long one that gets you caught in a screen.