How to quantify achievements on a tech resume.

Every resume guide on the internet tells you to "quantify your achievements." Great advice. Completely unhelpful when you're staring at a blank bullet point wondering how to put a number on six months of refactoring a monolith.

The problem isn't that engineers lack impact. It's that generic resume advice doesn't speak the language of engineering. "Increased sales by 20%" is easy to write when you're in sales. But how do you quantify building a distributed cache layer? Migrating 14 services to Kubernetes? Mentoring three junior engineers who all got promoted?

This guide solves that. Every example below is specific to a tech role, uses metrics that engineering managers actually look for, and follows a formula you can apply to your own work in five minutes.

Why numbers matter more in tech

Engineering managers are not reading your resume like a novel. They're scanning. They give each resume 15 to 30 seconds, and they're looking for impact signals — evidence that you shipped work that mattered. Numbers are the fastest way to signal impact because they answer two questions instantly: what was the scale? and what changed because of you?

In tech specifically, numbers matter more than in most fields for three reasons:

1. Everything is instrumented. Engineers work in environments that produce metrics constantly — latency dashboards, error rate monitors, deployment pipelines, A/B test results. A hiring manager knows these numbers exist. A resume without them feels like you either didn't measure your work or didn't have impact worth measuring.
2. Scale is a differentiator. "Built an API" means something very different at a startup with 100 users versus a company processing 50M requests per day. The number tells the hiring manager which one you are.
3. Leveling depends on scope. At most tech companies, the difference between L4 and L5 (or IC3 and IC4) is the blast radius of your work. Numbers prove scope. "Reduced costs" is L3. "Reduced annual infrastructure costs by $1.2M across 340 services" is L5.

The best tech resumes read like a highlight reel of dashboards. Each bullet is a before-and-after snapshot of something that got better because you were there.

The quantification formula

Every strong quantified bullet follows the same three-part structure:

Here's how each part works:

• Action verb: Start with a strong verb that describes how you contributed. "Redesigned," "Migrated," "Automated," "Reduced." (See our full list of 200+ action verbs grouped by meaning.)
• What you did: The specific technical work. Include enough context that someone outside your company can understand the scope — the system, the technology, the team size, the constraint.
• Measurable result: The number. A percentage improvement, a dollar figure, a time reduction, a scale metric. This is the part most engineers skip, and it's the part that matters most.

Example: Redesigned the checkout flow's client-side rendering pipeline using React Server Components, reducing Largest Contentful Paint from 3.8s to 1.2s and increasing mobile conversion rate by 14%.

The verb tells you the shape of the work. The middle clause tells you the technical sophistication. The numbers tell you it mattered.

Frontend engineer examples

Frontend metrics that hiring managers care about: Core Web Vitals (LCP, CLS, INP), bundle size, load time, conversion rate, accessibility scores, component reuse, and test coverage. Here are examples that use them well:

1. Optimized Largest Contentful Paint from 4.1s to 1.4s across 23 product pages by implementing image lazy loading, font subsetting, and critical CSS inlining — lifting the Lighthouse performance score from 47 to 94.
2. Reduced JavaScript bundle size by 62% (840KB to 320KB) through tree-shaking, dynamic imports, and replacing Moment.js with date-fns, cutting median page load time by 1.8 seconds.
3. Built a shared component library (48 components, 96% test coverage) adopted by 5 product teams, reducing frontend development time for new features by an estimated 30%.
4. Eliminated layout shift (CLS from 0.32 to 0.04) on the product listing page by reserving image dimensions and preloading web fonts, contributing to a 9% decrease in bounce rate.
5. Migrated a 120K-line AngularJS codebase to React over 6 months with zero production downtime, enabling the team to ship features 2x faster using modern tooling.
6. Implemented server-side rendering for the marketing site using Next.js, reducing Time to First Byte from 2.4s to 380ms and improving organic search traffic by 28% within 3 months.
7. Redesigned the mobile checkout flow with progressive form validation, reducing cart abandonment by 17% and increasing mobile revenue by $2.3M annually.
8. Achieved WCAG 2.1 AA compliance across 40+ pages, fixing 312 accessibility violations and expanding the addressable user base by an estimated 15%.

Backend engineer examples

Backend metrics that resonate: API latency (p50/p95/p99), throughput (RPS), error rate, uptime, query performance, and cost efficiency. Scale always matters here — include request volumes and data sizes.

1. Reduced p99 API latency from 1,200ms to 180ms for the search endpoint (serving 4M queries/day) by implementing a Redis caching layer and optimizing the PostgreSQL query plan.
2. Designed and built a rate-limiting service handling 50K requests per second across 12 microservices, reducing abuse-related downtime incidents from 8 per quarter to zero.
3. Migrated the payment processing pipeline from a monolithic Rails app to 6 Go microservices, improving throughput from 200 to 1,400 transactions per second while maintaining PCI compliance.
4. Reduced database costs by 40% ($180K annually) by implementing read replicas, connection pooling, and query optimization across 34 slow queries identified via pg_stat_statements.
5. Built an event-driven notification system using Kafka and gRPC, processing 12M events daily with 99.97% delivery reliability and sub-200ms end-to-end latency.
6. Increased API uptime from 99.5% to 99.99% by implementing circuit breakers, graceful degradation, and automated failover across 3 availability zones.
7. Authored and enforced API design standards adopted by 8 backend teams, reducing integration bugs by 45% and cutting cross-team onboarding time from 3 weeks to 5 days.
8. Optimized a batch processing job from 6 hours to 22 minutes by parallelizing workloads across a 16-node Spark cluster, unblocking daily analytics reporting for the data team.

Data engineer examples

Data engineering is measured by pipeline reliability, data freshness, processing throughput, cost, and how well downstream teams can actually use the data. Show the scale of data you handle and the business impact of getting it right.

1. Built and maintained 24 Airflow DAGs processing 8TB of raw event data daily, achieving 99.6% pipeline SLA adherence over 12 months.
2. Reduced data warehouse costs by 55% ($420K annually) by migrating from on-demand Redshift queries to a partitioned, columnar storage model on S3 with Athena.
3. Designed a real-time streaming pipeline using Kafka and Flink that reduced data freshness from 24 hours (batch) to under 90 seconds, enabling the fraud team to block suspicious transactions in near real-time.
4. Automated data quality checks across 140 tables using Great Expectations, catching 23 schema-breaking upstream changes before they reached production dashboards.
5. Built a self-serve analytics platform (dbt + Looker) used by 60+ non-technical stakeholders, reducing ad-hoc data requests to the engineering team by 70%.
6. Migrated 14TB of historical data from Oracle to BigQuery with zero data loss, completing the project 3 weeks ahead of schedule and saving $280K in annual licensing fees.
7. Implemented incremental processing for the customer events pipeline, reducing daily compute costs from $1,200 to $340 and cutting pipeline runtime by 74%.

ML engineer examples

ML hiring managers look for model performance metrics (accuracy, precision, recall, AUC), inference speed, training efficiency, and — critically — business outcomes tied to model improvements. A model that's 3% more accurate is meaningless without the downstream impact.

1. Improved the product recommendation model's click-through rate from 3.2% to 5.8% by implementing a two-tower neural retrieval architecture, generating an estimated $4.1M in incremental annual revenue.
2. Reduced model inference latency from 340ms to 45ms by converting the fraud detection model from PyTorch to ONNX Runtime and implementing dynamic batching, enabling real-time scoring at checkout.
3. Built an automated ML pipeline (feature store, training, evaluation, deployment) using Kubeflow that reduced model iteration cycles from 2 weeks to 3 days.
4. Increased spam detection precision from 91% to 97.4% while maintaining 99.2% recall, reducing false positives that reached human reviewers by 68% and saving 1,200 moderation hours monthly.
5. Designed a feature store serving 200+ features to 8 ML models across 3 teams, reducing feature engineering duplication by 60% and ensuring training-serving consistency.
6. Reduced GPU training costs by 38% by implementing mixed-precision training and gradient accumulation, cutting the training time for the core ranking model from 18 hours to 7 hours on 4 A100 GPUs.
7. Deployed an A/B testing framework for ML models that ran 14 experiments in Q3, leading to 3 model upgrades that collectively improved user engagement by 11%.

DevOps / SRE examples

DevOps and SRE resumes live and die by reliability metrics: deployment frequency, change failure rate, MTTR, uptime, and incident counts. Cost optimization is a close second. Show that you made the system more reliable and the team more productive.

1. Increased deployment frequency from biweekly releases to 15+ deploys per day by building a CI/CD pipeline (GitHub Actions, ArgoCD, Helm) with automated canary analysis and rollback.
2. Reduced Mean Time to Recovery from 47 minutes to 8 minutes by implementing automated runbooks, PagerDuty escalation policies, and pre-built diagnostic dashboards in Grafana.
3. Maintained 99.99% uptime (52 minutes total downtime) across 40+ production services serving 8M daily active users over a 12-month period.
4. Cut monthly AWS spend by 32% ($94K/month) through Reserved Instance planning, right-sizing 120 EC2 instances, and implementing S3 lifecycle policies across 14 accounts.
5. Migrated 28 services to Kubernetes (EKS) over 4 months, reducing infrastructure provisioning time from 2 days to 15 minutes and enabling autoscaling that handled 3x traffic spikes during product launches.
6. Built an observability stack (Prometheus, Grafana, Loki, Tempo) that consolidated monitoring from 4 disconnected tools, reducing alert noise by 60% and increasing actionable alert rate to 92%.
7. Reduced container image build times from 12 minutes to 90 seconds using multi-stage builds, layer caching, and a shared base image strategy, saving the engineering team an estimated 380 hours annually in CI wait time.

Engineering manager examples

Engineering manager resumes need a different kind of number: team size, delivery velocity, retention, hiring pipeline metrics, and organizational outcomes. The shift from IC to manager means your impact is measured through the people and processes you built. See our staff engineer resume example for the IC equivalent at the same level.

1. Grew the platform engineering team from 4 to 14 engineers over 18 months, maintaining a 90% offer acceptance rate and zero regretted attrition during the scaling period.
2. Improved sprint velocity by 35% across 3 squads by implementing async standups, reducing meeting load from 12 to 6 hours per engineer per week, and introducing quarterly OKRs.
3. Reduced time-to-hire from 62 days to 28 days by redesigning the interview loop (structured rubrics, take-home alternatives, same-week debriefs), conducting 140+ interviews personally.
4. Led the architecture migration from monolith to microservices across 2 teams (11 engineers), delivering 8 services over 9 months while maintaining feature velocity at 95% of pre-migration levels.
5. Achieved 95% direct-report retention over 2 years (18 of 19 engineers stayed), with 6 promotions to senior and 2 to staff level during that period.
6. Established an engineering onboarding program that reduced new-hire ramp time from 8 weeks to 3 weeks, measured by time to first meaningful PR merged.
7. Owned the reliability charter for the payments platform (processing $2.1B annually), improving uptime from 99.9% to 99.99% through incident review culture and an error budget framework.

Product manager examples

Product managers quantify through business outcomes: revenue, user growth, activation, retention, and NPS. The strongest PM bullets connect a specific product decision to a measurable business result.

1. Launched a self-serve onboarding flow that increased 7-day activation rate from 23% to 41%, contributing to $3.8M in incremental ARR within the first two quarters.
2. Defined and executed the pricing migration strategy for 12K enterprise accounts, achieving 94% retention through grandfathering and resulting in a 22% ARPU increase.
3. Grew the mobile user base from 180K to 1.2M MAU over 14 months by prioritizing mobile-first features based on usage data, running 26 A/B tests, and reducing mobile onboarding friction by 3 steps.
4. Improved Net Promoter Score from 31 to 58 over 4 quarters by establishing a customer feedback loop (Intercom surveys, support ticket analysis, monthly user interviews) and prioritizing the top 10 pain points.
5. Reduced churn from 6.2% to 3.8% monthly by identifying at-risk accounts through usage pattern analysis and launching a proactive outreach program with the CS team.
6. Led a cross-functional team of 8 (3 engineers, 2 designers, PM, analyst, QA) to ship a new reporting dashboard adopted by 78% of enterprise customers within 60 days of launch.
7. Managed a product roadmap spanning 4 engineering squads, delivering 31 features across 6 releases with an on-time delivery rate of 88%.

How to find numbers when you think you have none

This is the most common objection engineers have: "I don't have access to those metrics" or "my work wasn't measured that way." Usually, the numbers exist — you just haven't looked in the right places. Here's the retrospective technique for finding them.

Step 1: Check your tools

Before you claim you have no numbers, actually check. Most engineers have access to more data than they realize:

• APM dashboards (Datadog, New Relic, Dynatrace) — latency, error rates, throughput before and after your changes
• CI/CD metrics (GitHub Actions, Jenkins, CircleCI) — build times, deployment frequency, test pass rates
• Cloud billing (AWS Cost Explorer, GCP Billing) — before/after cost comparisons for infrastructure changes
• Analytics platforms (Amplitude, Mixpanel, Google Analytics) — user-facing metrics tied to features you built
• Project management tools (Jira, Linear) — ticket velocity, cycle time, sprint completion rates
• Git history — lines changed, PRs merged, repos contributed to (use with caution as a metric, but useful for scale context)

Step 2: Reconstruct from memory

If you left the company and can't access dashboards, reconstruct what you know:

• How many users did the product have? (Check Crunchbase, press releases, or your own memory of DAU/MAU discussions)
• How many services, endpoints, or databases were in the system you worked on?
• How large was the team? How many engineers, designers, PMs?
• How long did things take before your improvement? How long after?
• What was the deploy cadence? How many incidents per month?

Step 3: Use honest approximations

You don't need exact figures. Hiring managers expect approximations. These framings are all acceptable on a resume:

• "Reduced latency by ~40%" — the tilde signals an estimate
• "Serving 2M+ daily requests" — the plus sign covers imprecision
• "Cut build time by roughly half" — directional, honest, still compelling
• "Saved an estimated $200K annually" — the word "estimated" does the work

What you should never do is invent a number out of thin air. An engineering manager who asks "walk me through how you got to that 40% improvement" will know immediately if you made it up. Honest approximation is fine. Fabrication is a career risk.

Weak vs. strong: before/after rewrites

The best way to understand quantification is to see the same work described poorly and then well. Here are before/after pairs across roles.

Frontend engineer

Backend engineer

Data engineer

ML engineer

DevOps / SRE

Engineering manager

Product manager

Notice the pattern: the "before" bullets tell you someone had a job. The "after" bullets prove they were good at it. The difference is always specificity and measurement. For more role-specific resume formats, see our software engineer resume example and data scientist resume example.

Numbers to avoid

Not all numbers help. Some actively hurt your resume by making you look either dishonest or unsophisticated. Avoid these:

Vanity metrics

• "Wrote 50,000 lines of code." Lines of code is not a measure of productivity. Some of the best engineering work reduces line count.
• "Merged 200+ pull requests." Volume of PRs says nothing about quality or impact. A hiring manager might wonder why you needed that many.
• "Attended 150+ meetings." This is the opposite of an achievement.

False precision

• "Improved performance by 41.73%." Two decimal places suggest you pulled this from a very specific dashboard and will need to defend it in detail. Round to "~42%" or "over 40%."
• "Saved $1,247,892.14." Nobody calculates savings to the cent. "$1.2M" is more credible and easier to read.

Unattributable outcomes

• "Increased company revenue by 30%." Unless you were the CEO or the sole contributor to a product that generated all revenue, you cannot claim the company's top-line growth. Scope it to what you actually influenced: "Increased checkout conversion by 8%, contributing an estimated $2M in annual revenue."
• "Reduced bugs by 90%." Across what scope? All bugs in the company? Your team's bugs? This is too vague to be credible. "Reduced production incidents in the payments service from 12 to 2 per quarter" is specific enough to believe.

Meaningless scale

• "Managed a database with millions of rows." Millions of rows is small by modern standards. If the scale is genuinely impressive, use the actual number: "8.4 billion rows" or "14TB." If it's not impressive, focus on what you did with the data rather than how much there was.

The rule of thumb: if a number doesn't make a hiring manager's mental model of you more specific, cut it. Every metric on your resume should answer: so what? For more on choosing the right words to frame your metrics, see our action verbs guide, and make sure your formatting doesn't undermine your content with our ATS resume guide.

FAQ

What if my company doesn't share metrics with engineers?

Most companies have internal dashboards, even if leadership doesn't broadcast the numbers. Check your APM tools (Datadog, New Relic), CI/CD dashboards, analytics platforms (Amplitude, Mixpanel), or cloud billing consoles. If you truly can't access hard numbers, use directional estimates with honest framing: "Reduced page load time by roughly 40%" is fine. You can also measure your own work — run a before/after benchmark, count the PRs, or time the deployment pipeline yourself.

Should I quantify every single bullet point on my resume?

No. Aim for 60-70% of your bullets to include a number. If every line has a metric, it starts to feel mechanical and the important numbers lose their punch. Lead with your strongest quantified achievement for each role, then mix in context bullets that explain scope, complexity, or collaboration.

How specific should the numbers be — is rounding okay?

Rounding is expected and preferred. "~40%" or "over 2x" reads as honest. "41.7%" reads as either fabricated or pulled from a dashboard you'll be asked to explain in detail. Round to the nearest clean number unless the precision itself is the point (e.g., "99.99% uptime" for an SRE).

Can I use metrics from team projects, or only individual work?

You can absolutely use team-level outcomes — just be honest about your role. "Led a 4-person team that reduced API latency by 60%" is better than either claiming sole credit or hiding the result entirely. Use verbs that reflect your actual contribution: "led," "co-designed," "contributed to," "owned the migration that enabled."

What if my work was mostly maintenance or keeping things running?

Maintenance is measurable. "Maintained 99.95% uptime across 12 production services handling 2M daily requests." "Resolved 340+ production incidents with a median MTTR of 18 minutes." "Kept dependency debt below 5% across a 400K-line codebase." Reliability, consistency, and scale are all quantifiable — and hiring managers know that keeping systems running is often harder than building new ones.