I am updating my resume, and I'm wondering how to quantify my contributions to a startup where I worked for ~2.5 years.

Most resume advice suggests to quantity your achievements, ie: "Boosted customer retention by 25%", "Contributed to a 12x page speed increase". Unfortunately, I didn't measure many of my achievements. I also don't think the company allowed much time to measure our impact.

I do have some facts, for example: I started as the 9th employee, and the 5th engineer, and we had ~10 customers. By the time I left, there were ~50 employees, ~15 engineers, and ~70 customers.

I am highlighting my achievements at the top of my resume, in the summary section. Is it okay for me to say

More than doubled active user growth at startup XYZ

? Of course I didn't do this single-handedly, but I'm not sure how else to highlight my hard work in a quantitative manner.

How do software engineers typically quantify their achievements? How bad is it to offer hand-wavy calculations?

  • 1
    Related: workplace.stackexchange.com/questions/136901/…
    – nvoigt
    Sep 10, 2019 at 9:51
  • 2
    I would be really interested to know which industry can support an almost 1:1 ratio of employees to customers. This doesn't seem scalable; is the startup still operational?
    – MonkeyZeus
    Sep 10, 2019 at 14:49
  • 3
    Try MEDIC phrases: Maintained, Eliminated, Decrease, Increase, Create - they serve as good proxies for measures without the need of objective metrics. Example, “increased user engagement by doing X”, or “decreased downtime by tweaking architecture” etc. Works just as well.
    – PhD
    Sep 10, 2019 at 17:52
  • 46
    To any software engineer, a resume with stats like that smells like bullshit, and is more likely to get you rejected than hired. Concentrate on what you built, skills you used, and technical accomplishments. If you're going to give numbers, give it on technical things that you actually did (cut latency in half), not "doubled growth" which an engineer has no direct effect on. Sep 10, 2019 at 19:26
  • 5
    I have interviewed people with this kind of CV and rejected them for being too "corporate bullshit"-minded, and appearing to be more competent at interviewing than actually working. I suggest not even bringing the numbers up unless you have something very concrete with clear causality. Sep 11, 2019 at 16:41

10 Answers 10


I quantified almost nothing in my CV. I just provided numbers when they were objectively available: date of birth, scores in school, etc. Other than that, I just wrote about the experience and the projects I worked for.

Usually, if you read carefully, the examples with "quantization" apply to jobs where numbers are "Gods" - and those are usually sales (or other related or similar activities).

I explained here the structure of my CV, just in case you need some inspiration.


  1. I do not imply that quantization must be avoided at all costs. If you have some relevant numbers, it is OK to show them. It is the "quantization at all costs" which I speak against.

  2. As stated in a comment, some tech companies seem to be big fans of numbers. However, in my personal opinion, most tech companies don't reject you from the start just because of that.

  3. Normally, if a company really wants numbers, they will specifically ask, either you directly, or through the public communication channels (e.g., on their web page).

  4. If you will ever encounter a large number of potential employers asking for numbers, then start thinking to make some updates to the CV. In my almost 20 years of employment, nobody ever asked me about "self-marketing" numbers during interviews.

A good hint from @PaulKaram in a comment

We say that most companies do not need quantization, but only the list of the required skills. The truth maybe is somewhere in between. Compare the following:

  1. I am proficient in using C, C++, Python, and Ruby
  2. I am proficient in using four programming / scripting languages: C, C++, Python, and Ruby

Is statement 2 more "quantified" than statement 1, just because it makes the numbers explicit? Does statement 2 provide more information? For me, statement 2 is actually more difficult to read, because I need to throw away the "junk" information.

  • I largely agree with this, except to insert that the "quantization" approach is highly favored by some big tech companies like Amazon (particularly) and Google (supposedly, but to a lesser extent). Sep 10, 2019 at 12:34
  • 20
    On top of all that, consider that in many companies a software engineer (or most employees, really) wouldn't even have access to the financial information necessary to compile those sorts of numbers.
    – bta
    Sep 10, 2019 at 17:41
  • 7
    @Chan-HoSuh I worked for Amazon, and I've interviewed at Google. Neither gave a shit about numbers for an engineer. Maybe for other positions, but they're looking for really strong technical chops, not numbers. Sep 10, 2019 at 19:28
  • @GabeSechan Seems like you are addressing interviews, not resumes. When I interviewed at Amazon, each interviewer asked me about Amazon's principles and situations where I applied them. Several stated they would like data, more precise if possible. The recruiter had prepped me about this, but I probably didn't take that as seriously as I should have. At Google, the interviewers seemed more focused on problem-solving. However, interestingly, Gayle McDowell, who used to be on the Google hiring committee, does recommend STAR-like approach to resumes with KPIs for these companies. Sep 11, 2019 at 2:11
  • 2
    @GabeSechan Could it be that these big companies evaluate employees differently? I wonder if applicants that lacking in an engineering education are under more pressure to support their experience with hard numbers. Sep 11, 2019 at 19:27

Personally I think the "quantify everything" advice (which I've seen as well) is really bad advice for software engineers. We work in teams, we don't produce anything individually (unless you're the sole developer, in which case you can claim 100% of everything...).

Highlight the technologies you've worked with, the responsibilities you had at your previous roles, and how many years experience you have. Those are the criteria that will get you considered for an interview.

  • 1
    Yes, quantify everything doesn't really work when you're part of a team (and I would argue that's true for all professions). Sep 10, 2019 at 8:59
  • Trying to quantify things down into sales or user numbers doesn't really say much about abilities for software development. Breaking things down and highlighting problems solved [And how they possibly lead to those sales or user numbers] seems to tell a lot more in my mind. Sep 10, 2019 at 18:20
  • How would a software engineer even quantify customer retention? I mean how do you prove that was actually the thing that did it. I mean you can say customer retention went up when you were working there but we dont know if it was the programmer that caused it. On the otherhand if you do some marketting it is a valid metric to say that it increased while you were there even if theres no proof that was what caused it.
    – joojaa
    Sep 11, 2019 at 18:35

As someone who reads Software Developer Resumes routinely, quantify if you want or don't. It really doesn't matter as I ignore that part of the bullet point anyway because I know you wouldn't have put it on your resume if it's bad. Also it's likely inflated numbers anyway. The most important things for me are:

  • Familiarity with multiple programming languages and tools (Shows that you are willing to learn new things and don't view yourself as a (Insert Programming Language Here) developer only
  • Job Experience that shows you have the ability to take a barely/poorly documented user request and develop something that was what the user was really asking for.
  • And the reason you still end up with lousy coders is: You missed the critical step. You should try to find more rebels who tell you why the company has been doing it wrong. I love walking into a corporate office and cracking a beer watching over some shoulders while code monkeys slave away on tasks they know are stupid and beneath them. They tell me exactly how dumb what they're doing is. Tells me everything I need to know about that company. And those people, if they're smart, will quit. You need to identify the rebel streak, harness it, make the coder's natural obsession your friend.
    – joshstrike
    Oct 3, 2019 at 1:27

I think numbers are incredibly important, to help give a sense of the size and scope of the work you've done.

The rest of this answer is from a blog post of mine:

We know that numbers attract attention. When scanning your resume, the reader’s eye will be drawn to the numbers naturally.

Moreover, numbers make your story more interesting and give the reader a sense of the size of your accomplishments, or the troubles you’ve solved in the past.

Consider the difference between these two bullets:

  • Ran the help desk. Answered trouble tickets, responded to phone calls and tracked spare computer parts.

  • Ran the help desk for 200-seat office. Staff of 3 answered average of 50 phone calls and 27 trouble tickets per day. Maintained 200-unit inventory of spare computer parts worth $10,000.

These two bullets describe exactly the same responsibilities, but the addition of specific numbers draw the attention of the reader, and add the details that give a much fuller picture of your responsibilities.

Without the numbers, the reader might also logically assume that the reality is more like this:

  • Ran the "help desk" in a four-person real estate office. Answered questions a few times a week about Excel. Kept a spare PC in a closet in case something tanked.

Remember, your awesomeness is not self-evident, and part of your job in telling the story of your awesomeness is giving the numbers to support it.

  • 6
    You're right about sprinkling numbers to give a sense of scope. NO numbers is also a major red flag, so if this is totally about the semantics of a CV, I'm rethinking my answer below in that light. But too many numbers can also be a red flag of a different kind...
    – joshstrike
    Oct 3, 2019 at 1:19

As @virolino already pointed out, you don't have to quantify anything if you don't want or don't have something to.

I personally quantify my work so, that other people can see what exactly I did and more important which impact I made.

If you have worked about 2,5 years, you have done things, which you can quantify and list in CV. To give you a direction - try to list everything you have done in this company:

  1. I implemented CRM service
  2. I fixed a bug which slowed down a system
  3. I designed a new version of data transfer system
  4. I introduced a new ticket dashboard

Then you have to think how all these things helped your company. You can use something like this:

  1. It is easier to work with customers
  2. System has better performance
  3. More stable data transfer
  4. More comfortable work with tickets

And the last step is to define how much these things helped the company:

  1. brought 2x more customers by better CRM
  2. improved system performance by 2x times
  3. improved stability/plausibility of data by 4x times
  4. saved 10 man/hours per week by introducing better ticket dashboard

Of course you didn't do all this alone, but it is obvious. The point is to provide things, on which you have worked with a team and what you and your team have achieved.

  • 7
    "improved system performance by 2x times" So what? I have no idea why the system was slow before so it does not tell much about the applicant.
    – FooTheBar
    Sep 10, 2019 at 12:18
  • 5
    Imho doesn't matter what was wrong with system before, and if it is important, interviewer can ask for clarification in interview. Important is that you improved old system and saved money for the company. This is valuable. Anyway it is just an example(not the best one). Sep 10, 2019 at 12:27
  • 3
    As an engineer, I find the first bit to be extremely relevant, and the last to be rather meaningless. Knowing you did bug fixing helps me know you can fix bugs, which means analysis, coding, testing, i.e. you have specific skills. Knowing it works twice as good really only says something about the system of some other company. Sep 10, 2019 at 14:28
  • 2
    I had something similar on my CV, and one interviewer asked if I'd improved the system by leaving the company! Sep 10, 2019 at 14:50

Whether you quantify your contributions is not as important as indicating whether your projects were successful. Did the result meet the market favorably?

Your resume would best focus on your most important contributions to the success of projects, the technologies/tools incorporated and used, and your expertise using them.

I recently did a painful series of interviews (4-5 hour drive each way, grueling interview sessions) only to learn when I wasn't hired that my resume listed one technology which I barely used in a previous role was of great interest to them. Somehow they thought that meant I was a guru of said technology. When they found out I was a mere "appliance user", they were disappointed (probably from difficulty of finding a true expert in that realm).

  • 1
    Nobody will indicate that project was not successful, and moreover it is not employee's fault in most of the cases. Having experience with working on unsuccessful projects is also somewhat valuable experience. It shows that employee can work in stressful situation, when project has problems. Sep 11, 2019 at 5:31
  • 2
    What is this technology that's in such demand? @AndreiSuvorkov working on unsuccessful projects is the absolute best way to learn, and anyone who hasn't done so is lacking the most valuable experience of failing at least once. The people who have are the people who can guide you away from making the same mistakes.
    – joshstrike
    Oct 3, 2019 at 1:16

I wouldn't presume to tell you what you need to be noticed by a big HR department. But as an engineer who farms work to other engineers, while some quantitative information helps me understand the scope, pace and intensity of what you've worked on and therefore (presumably) what you'd be able to handle, I'm much more interested in why than how... and I'm more interested in how than how many. If you say you convinced your bosses to structure an API in a certain way because it would make it easier for vendors to integrate their system, that's much more impressive than if you told me how many vendors signed up.

My advice would be to cite your personal achievements, not the company's...but also, you should rightly view it as a personal achievement anytime you convinced someone to take a path they hadn't seen before, and it worked out well for everyone. The best coders - it sounds very 90s, but like Samurai, really - will think outside the box and present their Daimyo with an opportunity. The question of why you thought of that particular improvement speaks to both your intelligence and your loyalty. I believe those are still the qualities companies are seeking, and will always seek. If you present your intelligence with humility and you show curiosity and provide the reasons, they should see your value. If they don't, then either your value isn't that great, or it's their loss.

A coder who thinks for herself/himself about a problem is a diamond. Rough or not, those are the ones worth keeping. So focus on the problems you solved and don't worry about the numbers.


You should try to quantify the things that you think the recruiters want to know. Working as one of a team of 5 (or 15) is slightly useful, as it indicates the sort of working environment you're used to. It would be more useful if you could quantify your position relative to the others, maybe you were one of 5 senior engineers out of those 15 engineers.

You could also quantify the system you worked on, in whatever way is meaningful. If the start-up was sold, its value is significant. Otherwise the number of users, countries, transactions or the value of the widgets in the inventory give an idea of its size and importance, and thus give the recruiter the impression that you could be trusted to work on their system.

They probably aren't interested in the number of bugs fixed or lines of code written, but you could quantify a specialism by saying something like "implemented 80% of the stored procedures".

If you've got a long list of languages and technologies, it can be useful to quantify how many years you've been working with them, or how much of your time you spent in each area.

  • 3
    "If the start-up was sold, its value is significant". That would imply that a financing round with a higher valuation would improve my performance as engineer.
    – FooTheBar
    Sep 10, 2019 at 14:55
  • @FooBar while you are correct, I am assuming that hiring managers, regardless if they understand software engineering well enough, will have actionable numbers; These can help them arguing on why to hire you with higher management (which is much less likely to be technical). Depending on the hierarchy of the company and who makes the hiring decisions, it might help.
    – RaidenF
    Sep 10, 2019 at 15:53
  • That would only help with managers who would give an automatic raise if the company valuation rises.
    – FooTheBar
    Sep 11, 2019 at 9:50
  • 2
    @FooBar I'm with Robin on this one. Illogical or not, "worked at a start-up that grew x Million in value since joining" will probably get your foot in the door at many places. It's a psychological trick of association, which, for CVs, is probably pretty common.
    – Mars
    Sep 12, 2019 at 5:24
  • 1
    It's similar to working somewhere prestigious like Google. It doesn't automatically make you a better engineer but it means that successful people chose you to work for them, and implies that your engineering was at least partially responsible for their success. Sep 12, 2019 at 7:41

As a web engineer I would add metrics like

Improved Average Server Response time by 15%. Improved Google SEO to 90+ Improved DB queries on landing pages by 250ms.

Things like these. Numbers just set your CV apart.


When you're looking for a job, and you're putting together your CV it's a very good idea to quantify the impact of your work - if you can.

Sometimes you have no way to know what impact a project you delivered or took part in had on the company or the userbase. But recruiters and hiring managers like to see that engineers are aware of the impact of their work beyond the technical side.

Sure, most of the projects you've delivered you probably didn't deliver alone. But you don't have to take full credit, you can always make it clear you worked on it with a team of X people, and you were a junior/senior/lead developer on it. Nothing wrong with that.

If you can tell that the startup you worked for was acquired for X amount, definitely go for it.

If you can show that the project you delivered raised user retention by X%, you should definitely add that too.

Showing any achievement of this type is great. Not many engineers add this to their resume, but recruiters and hiring managers like it, so it'll give you an edge.

Btw I've picked up some cool insight as to how big tech companies filter applicants, and how to write a resume to get past that filter from this interview: https://codingsans.com/blog/software-engineer-resume

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .