How to put a real number on your data work
without inventing one.
A number is the fastest way to make a resume line believable, and the fastest way to lose a reader if it looks made up. Here is how to find figures you can defend.
Round numbers read as guesses
Most resume numbers are estimates, and readers can tell.
A reader who doubts one figure starts to doubt the rest. That is the real cost of a number that looks rounded: it puts every other line on your resume on trial.
It is not that you need bigger numbers. A smaller, exact one usually beats a large, round one.
Over 8 in 10
of the improvements claimed in 128 real Data Engineer resumes were round figures ending in 0 or 5, like “30% faster”. If they had been measured, you would expect only about 1 in 5.
Numbers you can defend, and where to find them
Pick the kind that fits the work. One good figure per project is enough.
Time
Runtime, latency, how fresh the data is when someone reads it.
Where to lookOrchestrator run history (Airflow, Dagster, ADF), warehouse query history, dashboard load times.
What it looks likeA nightly load that took 6 hours now takes 2 hours 10 minutes.
Scale
Rows or events per day, terabytes, number of tables, sources or users.
Where to lookTable metadata, storage metrics, pipeline logs. Scale is the easiest number to get right.
What it looks likeRoughly 1.2 TB a day across 40 source tables.
Cost
Bytes scanned, compute credits, the monthly bill for the thing you changed.
Where to lookThe cloud billing console and the warehouse usage views. Compare one month before with one month after.
What it looks likeStorage went from about $9,400 to $5,100 a month.
Reliability
Incidents, failed runs, manual fixes, how often the data arrived on time.
Where to lookAlert and pager history, the ticket queue, the on-call log.
What it looks likeManual re-runs fell from about 15 a month to 2.
Adoption
Who uses it, how often, and which decision it changed.
Where to lookBI usage stats and query logs. Failing that, ask the person who used it.
What it looks likeUsed weekly by four regional sales teams, replacing a spreadsheet they kept by hand.
Model quality
A metric measured against a baseline, on data the model never saw.
Where to lookEvaluation notebooks, experiment tracking, the A/B test readout.
What it looks likeWeekly demand forecast error fell from 18% to 12% against last year's method.
Baseline, period, method and scope
A figure with all four is very hard to argue with. A figure with none of them is a claim.
Baseline
Compared with what? A number with no starting point is not a result.
Period
Over what time? A week of query history is stronger than “it feels faster”.
Method
How did you measure it? A run history, an invoice or a held-out test set all count.
Scope
Which part of the system? Be exact about what you changed and what you did not.
Optimised SQL queries, improving performance by 50%.
Rewrote the 12 slowest dashboard queries to read a pre-aggregated table. Median load time fell from 48 seconds to 6 seconds over a week of query history.
An illustrative example.
Reduced cloud costs by 30%.
Moved 40 TB of cold logs to cheaper storage with lifecycle rules, taking the monthly storage bill from about $9,400 to $5,100 (March and May invoices).
An illustrative example.
Increased forecast accuracy by 20%.
Cut weekly demand forecast error (MAPE) from 18% to 12% against last year's method, measured on the final 8 weeks held out from training.
An illustrative example.
What to write instead of a guess
Not every change left a clean before and after. There is still something true you can say.
- Give the scale instead. “Roughly 1 TB a day” is true, checkable and impressive on its own.
- Give an honest range and say it is approximate: “about 3 to 4 hours down to under 1”.
- Use a proxy you can find, such as tickets raised, re-runs, or hours a stakeholder told you they saved.
- Ask someone who was there. An analyst, a product manager or a finance partner often still has the dashboard or the invoice.
- Describe the change in words when a figure is out of reach: from a manual monthly job to an automatic daily one.
What to leave out
These are the habits that make a number easy to doubt.
- An improvement percentage you cannot trace back to a run, a bill or a test.
- A percentage with no baseline. “Improved accuracy by 25%” invites the question “from what?”.
- False precision. A figure like 37.2% recalled from memory is easier to doubt than “about a third”.
- A team's result presented as yours alone. Say what your part was.
- A number that breaks confidentiality. Anonymise the client and keep the scale or a relative figure.
Catch the number while you still can
The hardest part is rarely the maths. It is that the before figure is gone a year later.
- Dashboards and query history. Some systems keep history only for a limited time, so note the before figure when you make the change.
- Invoices and the cloud billing console, one month either side of the change.
- The ticket or pull request for the change, which often holds the numbers you quoted at the time.
- Incident and postmortem documents, and the chat thread from the day.
- A short note to yourself: what it was before, what it is now, how you measured it.
Numbers are only half of a strong line. The other half is showing the decision behind them, which is covered in how to show ownership on a data resume.
Common questions
- Is it wrong to round a number?
- No. “About 1.2 TB a day” is honest precision. The problem is a round improvement claim, such as 30% or 40%, with nothing behind it. Round the scale, but do not round a result you never measured.
- What if the real number is confidential?
- Use a relative figure, such as a fourfold speed-up, or a range, and anonymise the client. Interviewers respect a candidate who protects confidentiality and still shows the size of the problem.
- What if I no longer have access to the data?
- Give what you remember with honest wording, such as “roughly” or “about”, and be ready to explain how you would have measured it. Never fill the gap with a figure you cannot stand behind, because interviewers often ask how you got it.
Write the number down the day you change it.
Capture what it was before, what it is now and how you measured it while it is fresh. graph asks the follow-up questions and shows you what is still missing.