How to write software engineer resume bullets when you have no metrics

You can write a strong software engineer resume without metrics. First check whether the numbers exist somewhere you have not looked, because engineering work is measured more often than people remember. Where no number exists, describe the scope of the work: what you built, how large it was, who depends on it, and what it replaced.

This post is for engineers who were told to "add numbers" and do not have any available.

Where can you find numbers for work you already shipped?

Many engineers never see revenue or conversion figures. That is normal. A technical reader can judge engineering numbers more directly anyway, and the tools you worked in recorded them.

• Frontend: bundle size from the build output, Largest Contentful Paint and other Core Web Vitals from Lighthouse or your monitoring tool, the number of screens or components you own, test coverage.
• Backend: p95 or p99 latency and requests per second from your dashboards, table sizes, queue depth, the number of services or endpoints, error rate before and after a change.
• DevOps and cloud: deploy frequency, pipeline duration, time to restore service after an incident, monthly cloud cost from the billing console, the number of environments or clusters.
• iOS and Android: crash-free rate from your crash reporter, cold start time, app size, the store rating, the number of releases per month.

Some sources work for any role. Your pull request history shows how many services you migrated or how many modules you converted. CI history shows build times before and after your change. The ticket tracker shows how many support requests a bug caused before you fixed it.

A bullet built from the ticket tracker alone looks like this:

- Fixed a time zone bug in the booking flow that had caused about 30 support tickets a month, the largest single source of tickets for the team

If you still work there, spend an hour collecting these now. If you have left, use only what you kept legitimately or what is public: your own performance review notes, the store rating history, the company's engineering blog, user counts from press releases.

How do you estimate a number honestly?

An estimate belongs on a resume when you can answer three questions about it in an interview: what was measured, what the value was before and after, and which part of the change was your work. If you can answer all three, the number is defensible even if it is approximate. If you cannot, it is invented precision. For something new there is no before value, so give the current value and say where it comes from.

Three habits keep an estimate honest. Give the before and after values, not only a percentage, because "from about 4 s to under 2 s" can be explained and "by 53%" is much harder to explain. Round to what you actually remember. Write "about" when it is an estimate.

Before:
- Improved API performance by 66.7%

After:
- Cut p95 latency of the search endpoint from about 900 ms to about 300 ms by replacing per-row queries with one batched query

The first version looks exact and says nothing about what was measured. The second is less precise and easier to believe, because a reader can see the measurement, the baseline and the cause.

Do not put a number on a result that belonged to a whole team as if it were yours. State the team result as context, then state your part:

Before:
- Reduced checkout latency by 40%

After:
- Part of the four-engineer effort that cut checkout p95 from about 800 ms to under 500 ms; wrote the Redis cache for the pricing calls

Not every line needs this treatment. Our senior backend engineer resume example has bullets with request volume and a latency reduction next to plain statements, such as an OAuth2 integration for partners, that carry no number.

How do you write a strong bullet with no number?

Describe scope. A number is one way to show the size of a piece of work, and it is not the only one. These facts do the same job and need no measurement:

• First or only. You built the first version, or you were the only engineer on it.
• From scratch, or inherited. Starting a service and taking over a ten-year-old one are different work. Say which.
• Migrations and deprecations. What you moved from, what you moved to, and whether the old system was shut down.
• Ownership. What you are on call for, what you review, what you decide.
• Who depends on it. Other teams, external partners, a named kind of user.
• Constraints. No maintenance window, a regulatory deadline, a legacy API you could not change.

A weak bullet names an activity. A scope bullet names the thing, its size and its end state.

Before:
- Worked on the notifications system using Node.js and Kafka

After:
- Sole backend engineer on the notifications service: designed the Kafka topic layout, wrote the delivery workers in Node.js, and retired the cron-based sender it replaced

A result can also be stated without a number. "Became the default template for new services", "removed the weekly manual release step" and "adopted by the mobile team" are outcomes a reader can picture and an interviewer can ask about.

Before and after rewrites for four roles

Each rewrite below uses only what the engineer would know without access to business data.

Frontend. The numbers came from the build output and a Lighthouse report.

Before:
- Improved the performance of the dashboard

After:
- Split the dashboard bundle by route and lazy-loaded the charting library, taking the initial JavaScript from about 1.4 MB to 600 KB gzipped and Lighthouse LCP on the main view from about 4 s to about 2.5 s

Backend. A migration has no natural before and after measurement, so the bullet relies on scope and constraint.

Before:
- Responsible for database migration tasks

After:
- Led the move of the orders database from MySQL 5.7 to PostgreSQL without a maintenance window: wrote the dual-write layer, ran the backfill, verified row counts, and removed the old cluster after cutover

DevOps. The numbers came from CI history and the release log. The release frequency is a team result, so it is stated as one.

Before:
- Managed CI/CD pipelines and improved deployment processes

After:
- Moved the deploy pipeline from Jenkins to GitHub Actions with cached Docker layers, cutting a typical build from about 25 min to 9 min; the team went from weekly releases to several per day afterwards

iOS. The crash-free rate came from the crash reporter. The second bullet has no number at all.

Before:
- Fixed bugs and worked on app stability
- Wrote tests

After:
- Traced the most frequent crash to a race condition in the image cache and fixed it, raising the crash-free session rate from under 99% to 99.7%
- Wrote the app's first snapshot test suite, now required on every pull request

The senior iOS engineer resume example uses the same kinds of figures across a full page: crash-free rate, store rating and release cycle length.

What about work that has no measurable result?

Some work never produces a number: a project that was cancelled, a refactor, on-call duty, an internal tool nobody tracked. Describe what exists because of you and what state you left it in. Here is a whole role written that way, with no metric in it:

Ferrow Logistics, Rotterdam
Full Stack Engineer | Aug 2021 – Present
- Own the carrier-integration service in Node.js and TypeScript: nine carrier APIs behind one internal interface, used by the web and mobile teams
- Rewrote the label-printing module from callbacks to async/await with typed errors and added the contract tests it did not have
- Built the admin tool that support staff use to reissue shipments, replacing direct database edits by engineers
- Designed and built the returns API for a returns product that was cancelled before launch; the address-validation part was reused in checkout
- Primary on-call for integrations one week in four; wrote the runbooks for the five most common carrier failures

A cancelled project still shows design and delivery, so say plainly that it did not launch.

When does a number make a bullet worse?

A number hurts when it raises a question you cannot answer or measures the wrong thing.

• A percentage with no baseline. "Improved efficiency by 30%" gives the reader nothing to check. If you cannot name what was measured, remove the number and describe the change.
• Activity counts. Commits, lines of code, pull requests merged and tickets closed measure effort. Use your PR and ticket history to find out what you did, then report the result: "migrated 14 services", not "merged 212 pull requests".
• A figure that is too good. A 300% improvement or a 99% cost reduction invites doubt even when it is true. Give the absolute values so the reader can see why it is real.
• A team result presented as yours. If the company grew to two million users, that is context for your work, not your achievement. Write "for an app with about 2M users".

In the worst case the number takes the place of the work itself:

Before:
- Increased team productivity by 40% through improved tooling

After:
- Built a CLI that creates a new service with CI, logging and alerts already configured; adopted by all five backend teams

How many of your bullets need a number?

Not all of them. Under each role, aim for one or two bullets with a measured result and let the others describe scope. In our experience, a page where every line ends in a percentage is harder to believe than a page with a few clear measurements.

These are three of the five bullets under the current role in our mid-level DevOps engineer example. One has before and after values, one has a count and an absolute time, and one has no number:

Krestonix Technologies, Bangalore, India
DevOps Engineer | 2021 – Present
- Migrated 11 on-premise applications to AWS ECS, reducing monthly infrastructure spend from $38k to $27k
- Implemented automated blue/green deployments for three product lines, cutting downtime to under 2 minutes
- Set up centralized monitoring with Prometheus and Grafana and wrote the on-call runbooks for the platform team

Resume example

Mid-Level DevOps Engineer Resume Example

Before and after values, counts and plain scope side by side under one role.

View the full example

Each of the three can be explained in an interview. The first names what was measured and both values. The second gives a count and a limit. The third says what exists now and who uses it.

Readers often skim, so put the bullet you can defend in the most detail first under each role.