The Resume Tip That Changed My Career

#career #achievements #resume #jobs

Image by Lazardjin, available via CC BY-SA 4.0

Resume-writing is one of those things lots of developers dread. There's only so many times you can type the word "leveraged" before you start to feel like maybe your whole career was a big fakeout. I used to write resumes with the goal of sounding like a fancy professional, without any clear sense of what a hiring manager actually wanted to know or how to convey that.

And then I read Ask A Manager, specifically this post, and I saw the light.

Ask A Manager, better known as Allison Green, has been blogging about career advice since 2007. She's also got one of the best pieces of resume advice I've ever heard. She says that rather than focusing on your job responsibilities, you should talk about your achievements, because the former "tells them that you held a job with a job description, yes, but it doesn’t say anything about how good you were at that job, when the latter is the thing they want to know."

This advice might sound kind of like splitting hairs at first: what's the difference between saying what you were told to do versus what you actually did? Shouldn't those things line up perfectly? Not exactly. Two different people could do the same job in really different ways in different job sites, and might have different strengths and weaknesses. You want to showcase what makes you a particularly strong back-end developer, technical writer, QA professional, etc.

Green says that if you're struggling to understand the difference, you should picture someone else doing the work you did--a really bad temp, for example. While they might follow the letter of the job description, they probably wouldn't do your job the way that you did it. And the way you executed your job--the unique talents and skills you brought to it--will point you toward your accomplishments.

For example: I could write that as part of my job description I responded to comments on Dev articles. But when I describe it that way, a cat laying on a keyboard could do my job. It doesn't tell my employer anything about how I did it, or what makes me an ideal candidate to do it for them.

What I could say instead is that I garnered positive engagement from big name contributors, or generated x number of clicks, or gathered new followers at y rate. I could compare the success of my platform to other professionals in the field, or to my employer's metrics before I took over. If everyone else's resume lists job descriptions and I'm listing accomplishments, I stand out as someone who gets things done, rather than simply doing what they're told.

Talking about achievements also gives me an opportunity to showcase talents they're looking for. If the job description says they want someone efficient, I can list an achievement that shows my efficiency. It lets the employer picture what it would be like to have me on the team. If I say I cleared a backlog of old tickets, they can look longingly at their backlog of old tickets and visualize me breezing through them.

In a sea of qualified candidates, this kind of storytelling can help you stand out. Listing your accomplishments lets a hiring manager see you more clearly, and makes them more likely to want you working for them.

Have you tried this advice? What's your best piece of resume advice? Let's chat.

Top comments (2)

John Colagioia (he/him) • Jul 27 '21

I think about it more as general advice about getting a job instead of just the resume steps, but it fits in with the "talk about what you did, rather than what you were told to do" thoughts: You only ever get hired when you can convince the team that they can trust you to do the job.

A lot of the advice about phrasing (and quantifying) work history is a specific version of that. For different versions of a simple example...

"Responsible for development on flagship application" could mean anything. Maybe you did substantial work, but all you're saying is that you were told to be there and may not have.
"Fixed bugs on and added features to flagship application" acknowledges that you did real work, but it could refer to a few days of work.
"Fixed an average of W bugs per week and led development on feature X on application with Y users, which eliminated Z support calls" is maybe more detail than anybody is going to read, but it's crystal clear what you did.

Here's the optimization problem (for lack of a better term) that makes this harder than a formula: For everything that you've worked on, somewhere along this spectrum based partly on how old the job is in your history, along with estimated attention spans and what you actually did, there's a level of specificity that most clearly says "for the cost of my salary and benefits, this is what you can trust me to accomplish."