How to quantify your impact as a software engineer

Ask an engineer what they did last quarter and you’ll get a clear answer. Ask them to put it on a resume and it turns into “worked on the backend” or “contributed to the platform team.” All the substance drains out. This is the single most common reason strong engineers write weak resumes and forgettable LinkedIn profiles.

The fix is learning to translate your work into impact: what changed, by how much, and for whom. It’s a skill, and once you have it, every job application and profile update gets easier.

Why “worked on” is killing your resume

When you write that you worked on a service, you’re telling the reader you were present. That’s not the same as telling them you were useful. A hiring manager reading a stack of resumes is trying to predict what you’ll do for them, and a list of tasks gives them almost nothing to go on.

Impact gives them a prediction. “Reduced page load time by 40%” suggests you can find and fix performance problems. “Cut on-call pages by half after rewriting the alerting logic” suggests you make systems calmer to run. The reader extrapolates from outcomes, not from job descriptions.

The numbers you already have

Most engineers think they don’t have metrics. Usually they just haven’t looked. Your daily work is full of measurable things if you go hunting for them.

Performance is the obvious one. Latency, throughput, build times, query speed, memory usage, error rates. If you made something faster or lighter, there’s a before and after.

Scale is another. How many requests per second did the service handle? How many users, how much data, how many machines? “Built a pipeline processing 2TB of logs a day” lands harder than “built a logging pipeline.”

Then there’s the human side. Did your tooling save the team time? Did your refactor cut the number of bugs filed against a module? Did a feature you shipped move a number the business actually tracks, like signups or retention? Even rough figures are fine. “Roughly a third faster” is honest and still useful.

What to do when there’s no number

Sometimes the work genuinely doesn’t have a clean metric. A migration, an internal tool, a research spike. You can still show impact by describing scope and consequence instead of reaching for a fake percentage.

Scope means the size and difficulty of what you took on. “Led the migration of 40 services off a deprecated framework with zero downtime” has no percentage in it, and it’s still a strong line. The “zero downtime” part is the impact. So is “40 services,” because it tells the reader this wasn’t a toy.

Consequence means what became possible because of your work. Maybe your tool let the support team resolve tickets without engineering help. Maybe your refactor unblocked a feature the company had wanted for a year. Say that. The outcome doesn’t have to be a number to be real.

A pattern you can reuse

When you’re stuck staring at a task, walk it through three questions. What was the situation before you touched it? What did you do? What was different afterward?

Take a vague line like “improved the search feature.” Run it through the questions. Before: search took several seconds and users complained. What I did: rewrote the query and added an index. After: results came back in under 200 milliseconds and the complaints stopped. Now you have a real bullet: “Cut search response time from several seconds to under 200ms by rewriting the query and adding an index.”

You don’t need fancy wording. You need the before, the action, and the after. The wording can stay plain.

Keep yourself honest

A word of caution, because this is where some people overcorrect. Don’t invent numbers. If you claim a 40% improvement, assume a sharp interviewer will ask how you measured it, what the baseline was, and what tradeoffs came with it. Getting caught inflating a metric is worse than having no metric at all.

It’s fine to estimate, as long as you’d be comfortable explaining the estimate. “Approximately” and “roughly” are honest words. Use them when the data was fuzzy. The goal is a resume you can defend line by line in a room full of engineers, because eventually you’ll be in that room.

Carry it into LinkedIn and interviews

Once you’ve done this work for your resume, you’ve basically scripted your interviews too. The same before-action-after stories are what behavioral questions are fishing for when they ask you to describe a project. You’ve already got the structure and the numbers ready.

Your LinkedIn benefits the same way. The experience section there can hold more of these impact lines than a one-page resume allows, which makes your profile read like a record of someone who ships, not someone who shows up.

This kind of self-translation is hard to do for yourself, because you’re too close to the work to see what’s impressive about it. A second perspective helps a lot. Fonzi works with engineers to pull the real impact out of their experience and present it well, then connects them with vetted AI startups through its Match Day process. If you’ve been underselling what you’ve built, that’s a reasonable place to start fixing it.

FAQ

What if my work genuinely has no metrics?

Describe scope and consequence instead. The number of systems you touched, the difficulty of the problem, and what became possible afterward all show impact without a percentage.

How precise do my numbers need to be?

Precise enough to defend. Rough estimates are fine if you’d be comfortable explaining how you arrived at them. Inventing exact figures you can’t back up is the thing to avoid.

Where do I find metrics for past work?

Check dashboards, old tickets, performance monitoring, and any before-and-after data you have access to. If you’ve left the company, reconstruct it honestly from memory and label it as an estimate.

Should every bullet have a number?

No. Forcing a metric onto everything reads as padded. Use numbers where they’re real, and use scope or outcome language everywhere else.

Does quantifying impact help in interviews too?

Yes. The same before-action-after stories you write for your resume are what behavioral interview questions are looking for, so you end up rehearsed without trying.