Bsrgvty

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.

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.

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.

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.

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).

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.