How to quantify engineering achievements on a resume

“Improved performance” and “improved performance by 40%, reducing average page load from 2.1s to 1.3s” are different claims. The first is an assertion. The second is a specific, checkable fact that a reviewer can picture, question, and remember after reading fifty other resumes that day. Quantifying achievements is not about inflating them; it is about making a true claim specific enough to be believed.

The number does not have to be about money

Engineering bullet points default to searching for a dollar figure or a percentage, and stall out when neither is obviously available. Most real technical impact fits one of several other shapes instead:

• Scale: requests per second handled, records processed, concurrent users supported
• Speed: latency reduced, build time cut, deploy frequency increased
• Reliability: error rate reduced, uptime improved, incidents per quarter reduced
• Reach: number of engineers who now use a tool you built, teams onboarded to a system you migrated
• Effort saved: manual steps eliminated, hours of repeated work removed per week

A bullet like “built an internal CLI adopted by 12 engineers across three teams, replacing a manual deployment checklist” has no dollar figure and is still a specific, strong claim.

Finding numbers after the fact

Most people did not track metrics while doing the work, and that is fine; the numbers usually still exist somewhere.

• Check monitoring dashboards, APM tools, or CI logs for before/after timing data, even months later.
• Look at pull request and commit history for scope: files changed, lines removed in a cleanup, number of tests added.
• Check issue trackers for how many bugs a change closed, or how many support tickets a fix eliminated.
• Ask a teammate or manager for their recollection of scale or adoption if you genuinely do not have access to the original data.
• For open-source or personal projects, GitHub itself has real numbers: stars, forks, merged pull requests, contributors, issue close rate.

If no number is recoverable and estimating would mean guessing, it is better to describe scope precisely in words (“rewrote the checkout flow shared across all client applications”) than to invent a percentage. A specific, honest description without a number still beats a vague, padded one.

Never invent a number

A fabricated metric is one of the fastest ways to lose credibility in an interview, because the natural next question is “how was that measured?” and there is no good answer to give when the number was made up. If you are not confident in a figure, round conservatively, describe it as approximate (“roughly halved”), or drop the number and lead with scope and outcome instead.

The structure that makes a number land

A number without context is easy to skim past. The strongest bullets pair three things: what you did, the number, and what it means in plain terms.

Rewrote the search indexing pipeline to run incrementally instead of
nightly, cutting average index staleness from 18 hours to under 10 minutes.

This names the action (rewrote to run incrementally), the number (18 hours to 10 minutes), and it is already obvious why that matters without an extra sentence explaining it. That is the target shape for a strong bullet: specific enough that the “so what” is self-evident.

For projects without a real audience yet

A personal or open-source project that has not been used by anyone else yet will not have adoption numbers, and that is fine, do not force one. Describe the technical decision and its result instead: what you optimized for, what the constraint was, and how you solved it. “Designed the schema to support sub-100ms queries at 10k+ records” is a real, checkable engineering claim with no user count involved.

Where this connects to the rest of the resume

Quantified bullets work best alongside a tight, relevant skills section and a projects section that already reads as evidence rather than a list; a strong number in a bullet with no supporting project or skill nearby stands out less than one backed by the rest of the page.

resumefromgit.com pulls real, verifiable numbers directly from a GitHub profile, stars, forks, contribution counts, repository activity, so at least part of your resume’s evidence starts from data rather than memory.