If you don’t have a real number for a resume bullet, don’t make one up. Describe the scope (how big and how important the thing was), the constraint (what made it hard), what you did, and the before and after. For many readers, especially in enterprise and consulting, that’s stronger evidence than a percentage nobody can check.
Who this is for: anyone whose work wasn’t measured, whose dashboards belonged to someone else, or who has been told that “every bullet needs a metric”.
Why “add numbers to every bullet” is bad advice
Advice based on numbers assumes you have them. Most people don’t. The data belonged to another team, nobody measured before and after, or the work was the kind that stops bad things from happening, which leaves nothing to count.
What follows is predictable: people estimate, round up and start writing “improved efficiency by 40%”. Experienced readers have seen thousands of these and give them little weight. In the interview, the first question is “how did you measure that?”, and an invented number falls apart there.
Numbers aren’t bad. A real metric with context is excellent evidence. But a number without context says little, and a fake number costs you trust.
What should a bullet say instead of a number?
A strong bullet answers what an interviewer actually wants to know:
- Scope: what was it, and how big or critical? A feature, a service, a system, the whole platform?
- Team: alone, part of a team of N, or leading N?
- Constraint: legacy code, a deadline, compliance, scale, a fixed budget?
- Your decision: what you chose and why, including the trade-off.
- Outcome: what was different afterwards, in plain words.
You don’t need all five in every bullet. Two or three is usually enough.
The formula
[Verb at your level] + [scope] + [technique or decision] + [outcome]
For example:
Rebuilt the invoice generation job for the billing system as an idempotent, retryable pipeline; month-end runs stopped needing manual reruns.
There’s no percentage, but it’s clear what you did, how big it was and why it mattered.
Before and after examples
These examples are hypothetical.
Backend engineer (mid-level)
Before:
Improved the reliability of the notification service by 50%.
(Where did the 50% come from?)
After:
Owned the notification service end to end; added retries with backoff and a dead-letter queue, which ended the duplicate and lost emails that support had been escalating every week.
Frontend engineer (junior)
Before:
Increased UI performance significantly.
After:
Implemented virtualised rendering for the order history table, which large accounts had reported freezing; covered it with tests and kept the existing API unchanged.
Engineering manager
Before:
Increased team productivity by 30%.
After:
Took over a five-person team that had missed three release dates in a row; introduced a fixed weekly release train and smaller pull requests, and the team shipped on schedule for the rest of the year.
Consultant
Before:
Delivered a project worth millions.
After:
Led the integration workstream for a national retailer’s new e-commerce platform, coordinating three vendor teams to a fixed launch date that the client had committed to publicly.
Which evidence holds up?
| Evidence | Example | Holds up in an interview? |
|---|---|---|
| Invented percentage | “Improved efficiency by 40%” | No |
| Real metric with context | A number you can explain, from data you saw | Yes |
| Honest count | “Roughly 20 services” (you counted) | Yes |
| Outcome in words | “With no customer-facing downtime” | Yes |
| Buzzword | “Drove synergies” | No |
What can you count honestly?
Even without a dashboard, you often know some real numbers:
- Size: team size, number of services, number of teams that used your work.
- Frequency: releases per week, how often an incident used to happen.
- Duration: “over eight months”, “within a two-week deadline”.
- Reach: “all European storefronts”, “every new hire’s onboarding”.
- Before and after states: “from manual to automated”, “from four steps to one”.
If you’re unsure about a number, use a range you can defend (“tens of services”), or leave it out.
Describing outcomes in words
Not every outcome is a metric. These phrases are honest and carry weight:
- “with no customer-facing downtime”
- “removed the weekly manual step”
- “unblocked the mobile team’s release”
- “became the default for new services”
- “passed the external audit without findings”
- “stopped the recurring incidents”
They also tend to be easier to talk about in an interview than a percentage.
It depends on level, role and company
By level
- Junior: what you built and how you made sure it worked. Numbers are rarely expected.
- Mid: what you owned and kept running.
- Senior: the system, the trade-off and who relied on it.
- Staff: reach across teams and direction. See senior vs staff engineer resume and the full engineering levels on a resume.
A bullet with no metrics, at four levels
Fixed the retry logic in the invoice generation job and added tests for the month-end edge cases.
What carries the level: what you built and how you made sure it worked.
Rebuilt the invoice generation job for the billing system as an idempotent, retryable pipeline; month-end runs stopped needing manual reruns.
What carries the level: ownership and an outcome in words.
Redesigned month-end processing so invoicing, payments and reporting could retry independently; led two engineers through the switch with no customer-facing downtime.
What carries the level: the system, the trade-off and the people you led.
Defined the idempotency and retry standard for batch jobs across the finance engineering teams; it became the default for new pipelines.
What carries the level: reach across teams: "became the default".
By role
ICs describe technique and decisions. Leads and managers describe what the team delivered and what changed in how it works.
By company type
- Big tech and growth companies expect numbers more often. Use the real ones you have and describe scope for the rest.
- Enterprises and consultancies often trust named scope and clear outcomes more than percentages.
- Startups care about what you shipped and what the business got from it, such as a launch, a customer or a risk removed.
The same facts, framed differently for each reader, is what we mean by tailoring a resume without lying.
What not to do
- Don’t estimate a number and present it as measured.
- Don’t take credit for team metrics as if they were yours alone. “Part of the team that…” is fine.
- Don’t swap a number for a buzzword. “Drove synergies” isn’t scope.
- Don’t stack adjectives (“highly complex, mission-critical, large-scale”). Pick one that’s true and name the thing.
A quick self-check for each bullet
Bullet self-check
0 of 4 done
If the answer to all four is yes, the bullet works, with or without a number.
FAQ
Is a resume without metrics weaker?
Not necessarily. Clear scope, decisions and outcomes are strong evidence. A fake or unexplained metric is weaker than an honest description.
What if a recruiter asks for numbers?
Give the real ones you have, such as team size, reach or timelines. If you didn't measure something, say how you knew it worked.
Can I use approximate numbers?
Only if you can explain where they came from. "Roughly 20 services" is fine if you counted them. "About 40% faster" based on a guess is not.
Do junior developers need metrics on their resume?
Rarely. For juniors, reviewers look at what you built, how you tested it and how fast you learn.