Resume advice for engineers

Sprucing up your resume? As a people manager and before that, a technical lead, I've gone through piles of resumes and developed my own resume-screening process. Here's my approach, broken down into how I believe it translates into successful hires and how you can use it to improve your job-hunt.

Reduce length

Why it matters: The roles I've screened for have received lots of resumes, many of which were from candidates who would have probably excelled at the role. My goal isn't to select the best candidate from that group of good fits, it's to find anyone from that group. And because reading resumes consumes time and costs the company money, speed is essential. So the faster I can decide to discard or progress a resume, the better.

What you can do: As a candidate you can game this strategy by keeping your resume short and succinct. Help me easily and quickly assess your resume. Try to limit your resume to a single page, with a little spillover to a second page if you absolutely must. Think Cliffs Notes, not a novel.

Focus on your experience

Why it matters: I use a candidate's past experience to determine whether they're prepared for the demands of the role. On a resume it's the only thing I really pay attention to. By carving out this much room for experience you're giving yourself the space you need, to write what the reader needs.

What you can do: Squint at your resume. How much space do you use to communicate your work experience? Aim for 50-70%. Information such as education and skills are important, but I think they should be hanging on for dear life to stay on the page.

Give yourself room to shine

Why it matters: Time is finite and though technically the number of resumes is also finite, sometimes it doesn't feel that way! When someone's put effort into communicating their experience on their resume, I want to immerse myself in that content. But it can be difficult to do that if there's other information on the resume that I'd prefer to learn at a later time.

What you can do: Put on your editor's hat and consider removing information that doesn't convey experience. Some examples:

Phone number and street address. I won't call a candidate without arranging something with them first and street address is best shared with HR when someone's being added to payroll.
Skills and hobbies. Sometimes these relate to the role, and sometimes they don't. Some hiring managers like to see this info. Personally, I want to avoid bias so I try to focus my assessment of candidates based on how they work, not how they live their life outside of it.
Educational experience unrelated to the role.
Awards. These are tough for me to assess because I'm probably not familiar with the award criteria were or how the criteria were applied. So I tend to gloss over awards.
List of all languages and technologies a candidate is familiar with. I tend to assign importance to the ones that relate to the role or the ones I can tie back to the candidate's experience. The remainder are challenging to assess from seeing them on a resume, though it could be interesting to hear about them during the interview process.

Organize experience by roles

Why it matters: I scan resumes instead of reading them word by word. This saves me time. If I get a high-level impression that a candidate's experience maps to the role then I'll do a second, closer pass. But if I sense a poor fit then I can discard the resume and move on to the next without losing much time.

What you can do: I've found that as my eyes travel down the page, they tend to let the candidate's roles guide their journey. You can tell me the basic plot of your career story by organizing your experience by role. Multiple roles within a single company are fine. The point is that you can use roles as plot points to communicate your growth and give me a sense of where you're headed.

Tell a clear (and short) story

Why it matters: Beyond assessing a candidate for their fit with the role, I also assess them for fit with the team. This isn't "culture fit". I just want an idea of how their skills and experience might complement the team's. How might they fill the team's gaps? How might the team support the candidate in overcoming their own gaps? These are hypotheses that the interview process will validate. For example:

Aretha is a strong mid-level engineer with design experience, which we currently lack on the team. She designed and built a React component library from the ground up, so she probably understands how to compose components and work with designers. She described it as a prototype so she might excel when paired with Byun, who's familiar with the real-world challenges of building React front-ends.

What you can do: Choose your roles wisely, describe each one clearly, and understand the story you're telling about yourself. Check out my LinkedIn profile for an example of how I've applied this myself. Try to limit your story to five or six of your most recent roles – any more than that and you might end up trying to cram too much onto the page. Try cutting older roles, especially if they lose relevance to the role for which you're applying. See if the resulting story is stronger. Ask a friend to read your resume and tell you what their impression is in a few crisp sentences. Iterate until you hear the story you want to tell.

Convey impact

Why it matters: A role gives me the proper framing for a candidate's contributions. Taken together, roles signal a trajectory. But by themselves roles just tell me the scenes of a story, not the actions that took place. To understand what a candidate has accomplished, I look closer at each role to understand how the candidate made an impact.

What you can do: Describe each role with the key bits that show how the role mattered to either your employer or your career. You might be surprised to see a story naturally emerge. Do these bits have relevance to the role you're applying for? If not, consider cutting them. To get started, try to either quantify or qualify how your actions mattered.

Examples of quantified impact:

Reducing average CI execution time by 50%, saving $35,000 per month
Migrating a 300LOC codebase
Building a tool that supported team growth from 10 to 40 team members
Reducing regression rate by 30% per release (note that this might also have a qualified impact, perhaps by freeing up QA to invest in automated performance-testing tools)

Examples of qualified impact:

Driving an accessibility initiative that enabled new Federal business
Learning a specific new technique, language, or domain, such as multithreading, Python, or accessibility
Shipping a complex alerting feature (note that this might also have a quantified impact, for example maybe it was used by four other teams to enhance their own features)