How to write a data scientist resume
Updated 2026-09-02
A data scientist’s resume is measured in models that reached production and changed a number. A Kaggle rank, a [N]% accuracy, a publication list: to a hiring manager these are process. The manager reads for three things: which model made it into production, what decision it replaced, and how far the metric moved afterwards.
One word separates this page from the data analyst page and from the machine learning engineer page. An analyst’s evidence is a decision changed by analysis. An ML engineer’s evidence is latency, uptime, and the pipeline that retrains the model. A data scientist’s evidence sits between them: a model you built took over a decision that used to run on rules or judgment, and someone kept watching it after launch. “Built a churn model with [N]% accuracy” is missing exactly that second half.
Every example is in English because that is the language of the finished document. Every number is [N], because you are the one who has to defend the figure in the interview. Below: section order, three summary levels, bullets grouped by what this role is judged on, rewrites, skills to keep and cut, ATS keywords, common mistakes, and the follow-up each claim invites.
What a finished one looks like
Below is a complete sample for a fictional person, rendered as a real page by the product's own sheet and scored by the same rules engine the editor uses — the number is computed, not typed in. Every figure a bullet owes is left as [N], which is why the score stops under the cap. That is not a flaw in the example; it is the product's rule, demonstrated.
Noor Siddiqui
Education
- Built a hierarchical demand forecast for a metropolitan transit network as the thesis project, beating the agency’s seasonal baseline by [N] points of error
- Won the department’s applied statistics thesis prize for that forecast, which the transit agency adopted into its quarterly service planning cycle
Experience
- Built the demand forecast that sets weekly driver incentives across [N] cities and [N] million rides a month, cutting forecast error by [N] points and incentive spend by [$N] a quarter
- Halved rider cancellations on surge trips by replacing the flat surge multiplier with an accept-probability model, launched after a [N]-city holdout held the gain for [N] weeks
- Designed the switchback experiment framework for marketplace pricing, so two-sided interference stopped inflating lift; [N] pricing changes shipped on its readouts in one year
- Owned the promo-abuse model that scores every new account, catching [N] thousand fraudulent signups in its first quarter at a false-positive rate the support team agreed to in advance
- Developed the claims severity model that replaced the actuarial lookup table for auto claims, cutting reserve error by [N]% across the open claims book
- Deployed a churn score to the renewals team as a weekly file with a one-page playbook, lifting retained premium by [$N] in the first renewal cycle
- Introduced uplift modelling for retention discounts, so offers went only to policyholders whose renewal the discount changed; cut offer spend by [N]% at an unchanged retention rate
- Established calibration and drift monitoring on the team’s [N] production models, catching a feature outage that had silently degraded the fraud score for [N] days
Projects
- Created an open-source rolling-origin backtesting harness for time-series forecasts, adopted by [N] teams and downloaded [N] thousand times
Additional Information
Section order: show the production model first
One column, standard headings, no architecture diagram and no ROC curve. The first scan is shorter than the time it takes to interpret a chart, and a parser does not try.
One ordering rule: models that reached production and moved a number come first. Candidates from academia lead with publications and degrees; a hiring manager at a multinational flips straight to Experience to find out where the models went.
- 1Summary
Three sentences: years and domain, one production model and the metric it moved, and the family of methods you reach for (forecasting, causal, ranking). The reader decides here whether you build models or run notebooks.
- 2Experience
Reverse chronological. One model or one experiment per bullet: what it replaced, where it runs, which number moved. Method names sit mid-sentence, never first.
- 3Projects / Publications (optional)
After Experience for PhDs and career changers. One or two papers relevant to the posting, with links. A Kaggle result only if it is top [N] and you can explain your part of the method.
- 4Skills
Grouped by purpose: modelling, experimentation and causal, production and monitoring, data and tools. List only what you could derive on a whiteboard or tune in an interview.
- 5Education
A master’s or PhD is the norm here, so three lines: degree and field, one relevant research output, and who picked that output up. Drop the GPA three years after graduating.
Summary examples by level
A summary announces where your models went. Within three lines there has to be one model in production and the number it moved.
Statistics M.Sc. with two data science internships, focused on models that reach production. Built the demand forecast now scheduling weekly stock for [N] stores of a grocery chain, cutting stock-outs by [N]% against the buyer’s manual forecast. Seeking a data scientist role where the person who builds a model also watches it after launch.
Entry-level evidence is one model somebody uses, plus the baseline it beat. The last sentence shows you know the work continues after launch.
Data scientist with [N] years across ride-hailing and insurance, specialising in forecasting, uplift modelling and experiment design. Owns [N] models in production, including the surge-pricing model that halved cancellations on surge trips and the promo-abuse model that recovered [$N] in its first quarter. Reads out experiments that finance signs off on without a second analysis.
The mid-career word is owns: the model stays yours after it ships. Two models, each paired with a number that moved, and every [N] is a question you can take.
Lead data scientist who decides which problems deserve a model: retired [N] models nobody acted on and pointed the team at the [N] decisions that moved margin by [N] points. Set the experimentation standard (pre-registration, power, switchbacks for marketplace tests) that [N] product teams run on. Measures the team by decisions changed, not by models trained.
Senior evidence is selection: models killed, a standard set. The closing line defines success for the role, and the whole interview will test it.
Bullets grouped by competency
A data scientist is judged on these six things. The skeleton never changes: verb, the model or experiment, the decision it replaced, [N] outcome.
Forecasting that changed a plan
· Built the hierarchical demand forecast that sets weekly driver incentives across [N] cities, cutting forecast error by [N] points and incentive spend by [$N] a quarter.
· Replaced the finance team’s spreadsheet revenue forecast with a gradient-boosted model backtested over [N] quarters, narrowing the guidance range given to the board by [N]%.
· Cut stock-outs at [N] stores by [N]% with a promotion-aware demand model, after showing that the incumbent forecast missed [N] of the year’s largest promotional weeks.
Experiment design and readout
· Designed the switchback experiment framework for marketplace pricing, so two-sided interference stopped inflating lift estimates; [N] pricing changes shipped on its readouts in one year.
· Stopped a launch that showed a [N]% lift by tracing it to a novelty effect gone by week three, then wrote the pre-registration template the team has used since.
· Introduced sequential testing with fixed error rates, cutting median experiment duration from [N] weeks to [N] without raising the false-positive rate above the pre-registered level.
Causal inference and uplift
· Built an uplift model for retention discounts, targeting only policyholders whose renewal the offer changed; cut discount spend by [N]% at an unchanged retention rate.
· Estimated the causal effect of same-day delivery on repeat purchase with a difference-in-differences design across [N] staggered city launches, reversing a plan to expand it.
· Replaced last-click attribution with an incrementality model calibrated on [N] geo holdouts, moving [$N] of paid budget out of channels that showed no lift.
Risk and fraud models
· Owned the promo-abuse model that scores every new account, catching [N] thousand fraudulent signups in its first quarter at a false-positive rate the support team could absorb.
· Developed the claims severity model that replaced the actuarial lookup table for auto claims, cutting reserve error by [N]% across the open claims book.
· Cut credit losses on the pay-later product by [N] points with a default model whose reject-inference step scored the applicants the old scorecard had never seen.
Production and monitoring
· Deployed a churn score to the renewals team as a weekly file with a one-page playbook, so agents called the [N] highest-risk accounts first; retained premium rose [$N] in the first cycle.
· Established calibration and drift monitoring on all [N] production models, catching a feature outage that had silently degraded the fraud score for [N] days.
· Retired [N] models whose scores nobody acted on, after auditing downstream usage, and moved the team’s time to the [N] that still changed a decision.
Turning a model into a decision
· Turned a lifetime-value model into a bidding rule the growth team runs without a data scientist, raising payback-adjusted return on ad spend by [N]%.
· Wrote the one-page decision memo behind every model launch, stating the baseline, the expected lift, and the metric that would trigger a rollback.
· Convinced the pricing committee to run a [N]-city holdout on the new surge model instead of launching nationally, which showed the cancellation gain held only in the largest cities.
Before and after
The same experience written weakly and then well. The shared defect: weak lines end on a model metric, strong lines end on a business number that moved.
Built a churn prediction model with [N]% accuracy using XGBoost.
Built the churn model behind the renewals team’s weekly call list, lifting retained premium by [$N] in its first cycle; the threshold was set against the cost of a missed call, not a benchmark.
Why it works · Defect: accuracy is the model’s metric, not the company’s. The rewrite says who used the model, how, and which number moved, and explains how the threshold was chosen.
Worked on machine learning projects for the marketing team.
Developed the uplift model that decides which customers receive a retention discount, cutting discount spend by [N]% at the same retention rate.
Why it works · Defect: “Worked on” proves attendance, and “projects” has neither a count nor a fate. The rewrite names one model, the decision it makes, and the number it protected.
Applied advanced statistical techniques to analyze large datasets.
Estimated the causal effect of free delivery on repeat purchase with a difference-in-differences design across [N] city launches, reversing a plan to expand the programme.
Why it works · Defect: “advanced” and “large” carry no quantity, and the technique has no name. The rewrite gives the method, the design, the data scope, and the decision it overturned.
Deployed models to production using Docker and Kubernetes.
Deployed the demand forecast into the weekly scheduling run for [N] cities, with drift alerts that caught a feature outage before the schedule shipped.
Why it works · Defect: this is a machine learning engineer’s sentence, and only the tools are in it. A data scientist’s production evidence is which decision the model plugged into and who was watching it.
Ran A/B tests and reported results to stakeholders.
Designed the switchback experiment for marketplace pricing after showing that user-level A/B tests overstated lift by [N] points; the pricing committee now launches only on switchback readouts.
Why it works · Defect: running tests and writing reports is process, with no judgment in it. The rewrite has a methodological problem you found, the design you replaced it with, and the decision process that changed.
Skills: what stays, what goes
Every skill listed is an interview question. Keep what you could derive on a whiteboard or tune live; delete the rest.
Worth the space
Python (pandas, scikit-learn, statsmodels) · SQL · Gradient boosting (XGBoost, LightGBM) · Time-series forecasting · PyTorch (only with a model in production)
A/B and switchback experiment design · Power analysis and sequential testing · Uplift modelling · Difference-in-differences, synthetic control
Model monitoring (drift, calibration) · MLflow · Airflow · Feature store (only if you have used one)
BigQuery · Snowflake · Spark (only if the data outgrew one machine) · Git
Cut these
- Machine learning / AI (as one line item) · That is a job title, not a skill. Write the method families and model types: forecasting, uplift, gradient boosting.
- Deep learning (with no model in production) · A coursework CNN does not survive the first follow-up. Without a production model, leave it out, or turn it into one Projects bullet that states the data and the result.
- Kaggle ranks (outside the top) · A rank is not a skill. A top-[N] finish you can explain goes on one line under Projects; everything else goes.
- Storytelling, business acumen · Adjectives. If your bullets state the decision each model changed, both are self-evident.
ATS keywords
The words that recur in job descriptions are the words the system matches. These are the terms commonly matched for this role, by category, spelled the way postings spell them.
Only claim terms your experience can defend. Write “causal inference” and you must be able to state your identifying assumption and where it could fail. Write “production” and you must be able to say who monitors the model and how often it retrains. A term you cannot hold is not a bonus; it is a mine you laid for yourself.
The evidence off the resume: papers, preprints, placings, one repo
Every other section on this page is about a sentence. This one is about what the sentence points at: an arXiv ID, a public leaderboard, a repository that opens. The reader clicks, and what opens has to match what you wrote.
- Which link gets clicked first, and in what order
For an industry data science role the reviewer usually clicks the repository in your header first, looking for one project they can follow, and only then pastes a paper title into a search box. On a research team the order reverses. Either way, keep the header to two links — one repository, one Google Scholar or arXiv author page — on the same line as your email. A third link does not get clicked; it only gives the reader another way to be disappointed.
- What one paper looks like on a resume: a single line, author position included
Write it as “Hierarchical demand forecasting under sparse promotions. [Venue], [Year]. arXiv:[ID] — second of four authors; built the model and the backtest.” The venue and the identifier make it checkable; the author position stops the reader guessing. Keep one or two papers relevant to the posting and let the Scholar link carry the rest. Nine titles with no links reads as a CV somebody forgot to turn into a resume.
- The honest way to write “under review”
Write “Under review at [Venue], submitted [Month Year]”, or “Manuscript under review” if you would rather not name it. Never write “accepted” or “to appear” without the acceptance email in hand, and do not use “forthcoming” to blur the two. If it is rejected, demote the line back to a preprint that week. The same “under review” riding along through three years of your resume is the kind of thing a careful reader notices, and it costs you the lines above it as well.
- Competition placings: the rank is public, the percentage needs a denominator
A Kaggle leaderboard is public and permanent, so write the version someone can look up: “Kaggle [competition] — placed [N] of [N] teams, username [handle].” A bare top-[N]% with no field size invites the reader to do the arithmetic and notice you were the fourth member of a four-person team. If it was a team, say so, then say which part was yours: the features, the validation split, the ensemble at the end. Explaining why your cross-validation did not overfit the public leaderboard is worth more than the medal.
- One repository, and it is the one with a README
Most data science profiles are a row of untitled notebooks, and that link is worse than no link. Pin one project whose README says where the data came from, how to run it, and what the result was, inside the first three lines. Then point at it precisely: “github.com/…/backtest-kit — rolling-origin backtesting harness for time-series forecasts”. If the account holds tutorial forks and a Titanic notebook, leave the header field blank. A blank field costs nothing; a link that opens on coursework drags the paragraph above it down with it.
- When the model belongs to the company and the code cannot leave
This is the normal case and every interviewer knows it. Do not screenshot an internal dashboard, and do not push work code to a personal account — that is a security incident, not a portfolio. Write the method and the decision instead: “Uplift model for retention discounts (proprietary; method and evaluation design available to discuss).” If you want something clickable, rebuild the same method on a public dataset and say plainly that it is a reimplementation.
- Open every link yourself before you send it
Paste each one into a private window and click. The Scholar profile may be set to private, the arXiv author page may spell your name a second way, the repository may still be private, the Kaggle account may be empty. The usual failure here is not dishonesty, it is a mismatch: the resume says published and the page says preprint; the line says personal project and the history holds one commit called “initial commit”. When the page and the line disagree, change the line.
Common mistakes on data scientist resumes
- 1Presenting model metrics as achievements
AUC, F1, and RMSE are the numbers you look at when choosing a model. A hiring manager looks at which business number they turned into. A bullet that ends at [N]% accuracy with nothing after it is an admission that the model never shipped.
- 2No way to tell which model reached production
A model in a notebook and a model in a schedule are two different resumes. Give every model a fate: the decision it plugs into, how often it retrains, who watches it. If it never shipped, call it a prototype and say what blocked it.
- 3Reading like a data analyst
When dashboards, SQL reports, and ad-hoc analysis fill half the page, the signal blurs. An analyst’s product is a decision; yours is the model that took the decision over. Shrink the analysis work to a line or two.
- 4Reading like a machine learning engineer
Docker, Kubernetes, latency, and serving are the keywords of the posting next door. A data scientist’s production evidence is which decision the model plugged into, not which cluster it runs on. Keep the tooling to one line and give the space to the number that moved.
- 5Submitting the academic CV unchanged
Papers sorted by year, method names first, not one business number anywhere. A multinational asks one question of research output: which real problem did this method solve? Keep one or two papers relevant to the posting and cut the rest.
- 6Counting experiments instead of judging them
“Ran [N] A/B tests” is throughput, not judgment. Write the false lift you stopped, the design you changed, the decision your readout altered.
The follow-up each claim invites
An interviewer reads a data scientist’s resume by picking one model and drilling three levels down: how it was validated, how it shipped, and who watched it afterwards.
Halved cancellations on surge trips with an accept-probability model.
What was the baseline? How was the holdout drawn, and for how long? What else changed in that period? Did the effect decay?
The baseline definition, the holdout design and duration, the list of concurrent changes, and the curve three months after launch. If you cannot speak to decay, “halved” will be read as a first-week number.
Cut forecast error by [N] points against the incumbent forecast.
Which error metric? How was the backtest split, and was there leakage? The error fell; what decision changed?
Why you chose that error metric, the rolling-origin backtest details, and what the lower error bought in business terms: fewer units over-ordered, less incentive spend.
Estimated the causal effect with a difference-in-differences design.
How did you check parallel trends? How were treated units chosen? If I say that is selection, what is your answer?
The pre-period trend plot, the assignment mechanism, the robustness checks you ran, and one confounder you admit you could not rule out. Credibility on causal claims comes from volunteering the limits.
Established drift monitoring on all production models.
Monitoring what: input distributions, prediction distributions, or realised outcomes? How many alerts fired? How many were real?
The monitored metrics and thresholds, the alert log, and one event the monitoring actually caught. Monitoring that has never fired reads as decoration.
Stopped a launch that showed a [N]% lift.
How did you find out the lift was false? Did the product team push back? What convinced them?
The analysis steps that exposed the problem, the counterargument you faced, and how you communicated the call. This question tests judgment and whether you can say no.
FAQ
My models all stopped at the notebook stage. Nothing shipped. What do I write?
Layer honestly. Call it a prototype and say how far it was validated: the backtest result, the gap against the incumbent method, and where it stalled. “Validated a churn model against the incumbent rule in a [N]-month backtest; deployment blocked by data-access approval” is far more credible than pretending it shipped.
Then find one thing that did change a decision, even without a model: an experiment readout, a forecast someone acted on. That is the unit this role is measured in.
I have a PhD and nothing but papers and research experience. How should the resume change?
Rewrite each piece of research as problem, method, result, and pair it with something checkable: code, a dataset, where it was cited or adopted. Keep one or two papers relevant to the posting, with the method name mid-sentence.
Put one project on real data aimed at a real decision under Projects, public data included. A multinational cares whether you can connect a method to a problem, not how many methods you have read.
Should I list a Kaggle rank?
A top-[N] finish where you can explain your part of the method: one line under Projects. Everything else goes. A rank is process; the interviewer will ask what you got right in that competition and where it would break on real data.
My models are confidential. I cannot write the numbers. What now?
Write relative changes and scope: error down [N] points, [N] cities covered. Amounts, customer counts, and feature details are not needed. The [N] in these examples works the same way: you fill in what is safe to disclose.
How does a data scientist resume differ from a machine learning engineer one? I am applying to both.
Write two versions of the same experience. For data scientist roles, bullets end on the business number that moved and the experiment readout. For ML engineer roles, they end on latency, throughput, service availability, and the retraining pipeline. Both are honest; only the subject changes. One resume that tries to be both usually reads as neither.
Write your models the way a metric remembers them
Describe the models you built, where each one runs, and what moved after launch, in plain language. The Tech lens rewrites them into English at the level on this page. The 0–100 score comes from a rules engine, so the same draft always scores the same. Every missing number stays a yellow [N] placeholder for you to fill, because you are the one who has to defend it.
Try 2 free draftsKeep reading
The same person’s cover letter
The letter cites only what this resume states, explained paragraph by paragraph, with the engine’s letter check beside it.
How to write a data scientist cover letter