How to add numbers to a developer resume when you don't have metrics

By , founder of ResumeForDev · Updated

Short answer

To quantify a software engineer resume without exact metrics, use scope (how many users, services, endpoints, teams or records your work touched), frequency (how often it runs or ships), before/after comparisons (time, steps, errors), and honest estimates marked with “~” that you can explain in an interview. Find the numbers in dashboards, pull requests, tickets, release notes and analytics, or ask a former teammate. Never invent a figure: interviewers ask about the numbers on your resume more than anything else.

Key points

  • Scope counts as a number: users, services, endpoints, rows, teams.
  • Frequency counts too: daily deploys, weekly reports, nightly jobs.
  • Estimates are fine if they're honest and marked: “~40%”, “roughly 2 hours”.
  • Not every bullet needs a number. Most should have one.

Six kinds of number every engineer has

Ways to quantify engineering work when you lack metrics
TypeQuestion to ask yourselfExample phrase
UsersWho used it, and how many?used by 12 support agents daily
ScaleHow much data or traffic did it handle?processing ~2M events a day
ScopeHow many things did it touch?across 9 microservices
TimeWhat got faster or shorter?cut deploys from 40 to 8 minutes
FrequencyHow often does it run or ship?runs nightly for all 300 stores
ReliabilityWhat failed less often?from weekly paging incidents to none in 3 months

Where to find the numbers

  • Monitoring: Datadog, Grafana, New Relic, CloudWatch, Sentry error counts.
  • Your own pull requests: benchmarks and before/after screenshots often live in PR descriptions.
  • Tickets and postmortems: incident frequency, time to resolve.
  • Product analytics: daily or monthly active users, conversion, feature adoption.
  • Release notes and changelogs: how many features, how often you shipped.
  • People: your old manager or teammate often remembers the result better than you.

How to estimate honestly

If you know the order of magnitude but not the exact figure, say so with “~”, “roughly” or a range. “Cut report generation from ~10 minutes to under 1” is honest and still specific. The test is simple: could you explain in an interview where the number came from?

Before and after

Before:Improved the performance of the internal reporting tool.

After:Moved the weekly finance report from a manual spreadsheet export to a scheduled SQL job, cutting ~3 hours of work a week for the 4-person finance team.

No dashboard needed: the time saved and the team size are both things the author knows.

When a bullet doesn't need a number

Some work is better described by what it enabled: the first CI pipeline on a team, the migration that unblocked a product launch, the on-call rota you designed. Name the system and the result clearly. A forced number (“improved collaboration by 30%”) is worse than none.

Frequently asked questions

Is it OK to estimate numbers on a resume?
Yes, if the estimate is honest, reasonably close, and you can explain how you arrived at it. Mark it with “~” or “roughly” when you're not sure of the exact figure.
What if my work was internal and had no users?
Internal tools still have users: other engineers, support agents, finance, operations. Count them, and describe the time or errors your tool saved them.
How many bullets should have numbers?
Most of them. ResumeForDev's score gives up to 25 of 100 points for impact and shows how many of your bullets carry a number, but it doesn't expect every single one to.

One page, every line yours.

Answer a few questions about what you built. ResumeForDev asks follow-ups, writes the bullets, and never adds a number you didn't give it. Your first resume is free.

Build my resume free