Tips for Better Resumes
As a hiring manager at a growing company, I’m often reviewing resumes. Maybe I will review yours. Michael Lopp wrote in “A Glimpse and a Hook”:
The terrifying reality regarding your resume is that for all the many hours you put into fine-tuning, you’ve got 30 seconds to make an impression on me. Maybe less.
It’s unfair, it’s imprecise, and there’s a good chance that I make horrible mistakes, but there’s a lot more of you than me, and while hiring phenomenal teams is the most important thing I do, I’m balancing that task with the fact that I need to build product and manage the endless stream of people walking into my office.
But here’s a glimpse. I’m going to walk through the exact mental process I use when I look at a resume. I don’t know if this is right or efficient, but after fifteen years and staring at thousands of resumes, this is the process.
With that same disclaimer in place, here are some things I look for.
My first filter is to look for impact. Many people describe their responsibilities, without linking that to their impact. Our role in engineering is to drive outcomes for the business, so if you are someone who can describe their impact, this a big plus. It suggests that you think about the impact of your work, and we’ll probably talk about your impact during any interview.
My second look is for leadership / initiative. Software engineering is full of ambiguity, and we need people who can drive impact despite ambiguity. Where have you seen an opportunity and brought yourself and others to take advantage of that opportunity? Leadership can take many forms, such as mentoring, leading a group such as a book club or student group, running a project, improving processes at work, etc. You don’t need to be a manager or have an official “lead” title in order to lead others.
I don’t pay much attention to lists of skills or technologies. I’m much more interested in your past performance as a general indicator of future performance, which we’ll probably discuss in a behavioral interview. So, write your resume to highlight your actual experience that we can talk about. Use these experiences to show the reader the technologies and skills you have used.
A statement like “Led the migration from Spring Boot microservices in k8s cluster to a modular monolith, resulting in 40% decrease in AWS costs and improved LTTV” shows familiarity with multiple technologies (plus leadership and impact) without a skills section.
A statement such as “Advocated to increase default test coverage resulting in X% improvement in branch coverage and Y% reduction in escaped defects” is much more helpful than an anemic “Responsible for writing unit tests.”
You should brag a little here: it’s your resume and some bragging is culturally expected (I’m in the US). Don’t lie or steal credit (obviously)— you never know who the hiring manager knows or what they’ll ask you about.
I do like seeing links to external material on a resume, if it supports the story you are trying to tell. If you link to a blog or a code host (e.g., GitHub) in your resume, chances are decent that I will take a look at it. What do you want me to conclude?
Most links I see are to mostly empty GitHub profiles. Leave those out. Here’s what I’d love to see links to:
- Good writing. Writing is a big part of modern remote collaboration and very hard to “test” for in an interview.
- Repos with good commit messages. This is a specific form of writing.
- Repos with unit tests. Shows you think about quality. None of this has to be about anything “hard”; doing simple things well is enough.
I believe this advice is generally applicable for all levels, from intern to senior leadership. A resume doesn’t have to be perfect but a focus on specifics and impact will probably increase your chances of getting in the door.
This post evolved from a thread on Mastodon.