96

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
  • 1
    And this: workplace.stackexchange.com/a/136895/93518 (disclaimer:Me! Me, again) – Justin Sep 10 at 10:54
  • 1
    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 at 14:49
  • 32
    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. – Gabe Sechan Sep 10 at 19:26
  • 2
    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. – Jacob Raihle Sep 11 at 16:41
116

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.


Notes:

  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). – Chan-Ho Suh Sep 10 at 12:34
  • 17
    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 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. – Gabe Sechan Sep 10 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. – Chan-Ho Suh Sep 11 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. – niceEarthling Sep 11 at 19:27
63

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). – Gregory Currie Sep 10 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. – TheLuckless Sep 10 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 at 18:35
16

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 at 1:27
12

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.

  • 4
    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 at 1:19
8

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 at 12:18
  • 4
    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). – Andrei Suvorkov Sep 10 at 12:27
  • 2
    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. – AmiralPatate Sep 10 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! – Robin Bennett Sep 10 at 14:50
2

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. – Andrei Suvorkov Sep 11 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 at 1:16
2

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.

1

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 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. – K. Gkinis Sep 10 at 15:53
  • That would only help with managers who would give an automatic raise if the company valuation rises. – FooTheBar Sep 11 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 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. – Robin Bennett Sep 12 at 7:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.