Most technical CVs read like a list of tickets closed. “Built the payments service, migrated the database, wrote tests.” All true, all forgettable, because none of it tells the reader how much it mattered. A number turns a task into a result, and results are what a hiring manager remembers when they compare you against ten other engineers who also built a payments service.
Find the numbers already in your work
You do not need to invent metrics. Engineering generates them constantly, you just have to notice them. Latency, throughput, error rate, build time, cost, and user counts all sit in dashboards you already look at.
- Performance: cut API response time from 800ms to 120ms, or raised throughput to 4,000 requests per second.
- Reliability: reduced production incidents by half, or moved uptime from 99.5 to 99.95 percent.
- Scale: served 2 million daily users, or processed 50GB of events an hour.
- Cost and speed: dropped cloud spend by 30 percent, or cut deploy time from 40 minutes to 6.
Pair the number with the change you made
A metric on its own is trivia. Tie it to a decision so the reader sees your judgment, not just the outcome. “Rewrote the batch job in Go, cutting nightly run time from 3 hours to 25 minutes” shows both what you chose and what it bought. When you genuinely cannot measure impact, quantify the scope instead: team size, codebase, or number of services you owned.
Keep it honest and specific
Round numbers read as guesses, so use the real figure when you have it. Never claim a company-wide result that was really one team’s, and be ready to explain any number in an interview, because a sharp engineer on the panel will ask how you got it.
When you are drafting, the bullet point writer reshapes flat tasks into measured outcomes, the keyword scanner checks you match the stack in the posting, and the resume checker flags bullets that still have no result. The action verbs guide helps you open each line with force.