talent November 12, 2019

Understanding quantified achievements on engineering resumes

How you should read numbers in a developers resume and what this kind of information says about a candidate.
Avatar for Ryan Donovan
Content Marketer

Resume best practices are always shifting. What sections do you include? Do you put skills on there? Should you include all my jobs, including when you worked as a busboy in high school? This recent question, on StackExchange site the Workplace, highlights a more recent example: “Should I quantify my contributions on my resume?”

User niceEarthling, who asked the question, has heard that “most resume advice suggests to quantity your achievements,” but finds examples that they can’t match. The question for recruiters is if numbers can help them select a candidate? If so, what should you be looking for?

Should a candidate bother?

Plenty of the answers to this question said not to bother. User Player One said: 

“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 a member of a team, a given engineer may not be able to affect company results through their work. And when you’re hiring, you’re probably not looking for somebody to save the company X millions of dollars. You need someone who can write Python code. Let the product folks figure out how to save money. 

However, as you will likely be hiring for a position within a team, look for information that communicates how the candidate works in a team. Number of team members, direct reports, and other clues to local organization structure can indicate the difference between a smooth fit and a prima donna. 

User voigt, in another question, points out the actual impact doesn’t always code from the code they write. “The success of the project itself is rarely a product of good or bad coding or generally speaking good or bad software development practices. There are too many factors that have nothing to do with the technicalities that influence the outcome heavily.”

But even a failed project can show off what skills a candidate has. And what you’re hiring for are the skills. Our own CTO, David Fullerton, weighed in on what makes a candidate stand out:

“Details matter in a resume. Don’t just tell me generally what your company did, give me specific examples of what you worked on. I always look for specifics on a resume: what projects or features did you ship, what areas of the code did you own, what technologies were you the team expert in? If your contributions can be quantified, that’s great, but don’t fall into the trap of taking credit for your whole team’s work. I want to know about you, not your team.”

Quantity Can Show Off Quality

That said, there are some cases where numbers can provide value on a resume. Forcing candidates to measure the qualitative impact can select for engineers whose primary skill is self-promotion or screen out engineers who did good work on bad projects. But some numbers, deployed judiciously, can speak to quality of an engineers work. Our CTO explains:  

“Numbers can give an indication of the impact of your work. If you shipped a feature that moved a significant metric, that can be a great detail to include. Numbers can also give a sense of the scale of the engineering work you did. If you were handling a large number of requests or processing a lot of data, it can be useful to include some of those numbers.”

Those numbers only matter in relation to other numbers. If you fixed bugs that saved $5 million in lost revenue, that’s more significant at a $20 million company than at a $20 billion one. And, like Player One said above, most engineers work in teams, so these numbers may reflect a group effort instead of an individual one. 

But there’re additional benefits that quantifying work leads to. In the second linked question, user dwizum lays them out:

“It shows that the employee understands that the software they’re developing has an impact. It doesn’t really matter if the software caused a million in savings or ten cents, but the employee is showing that they understand the impact and can even quantify it. Employees who understand the impact of their work are typically more motivated to do quality work.

It gives a starting point for soft skills questions. A sentence like “Solved X problem and got Y result’ is practically a canned answer for a question like, ‘Tell me about a time when you did…’ Interviewers like ‘storytelling’ questions because it gets the candidate talking in a more conversational nature, and it shows that they can think about a large or complex problem and explain it to a stranger. Having a resume with ‘seeds’ for these sorts of questions is great, because as an interviewer, I can ask, ‘Talk a little bit about what you did on project X’ or whatever. Often, the content of these questions isn’t as important as just listening to the candidate explain something.”

Resumes that include or exclude quantitative information aren’t immediately better than the other. It takes a careful eye to determine what that information says about the candidate and whether that candidate can actually succeed in the position you’re looking to fill. 

How to Communicate with Developers
Podcast logo The Stack Overflow Podcast is a weekly conversation about working in software development, learning to code, and the art and culture of computer programming.