Over the past few years, I’ve reviewed lots of resumes for friends and former coworkers. I’ve also reviewed resumes from strangers, like on Twitter, where I offered to do resume reviews. I’ve been told that my reviews are helpful, so I’m documenting my approach, which focuses on whether the resume is a good fit for the job that the candidate wants.

Software engineers can have their resume reviewed for free in a number of ways, such as by consulting Reddit, Discord and other forums, or by asking friends. From my observation, most online reviewers begin with the assumption that the candidate has provided all the necessary information. They then suggest tactics for strengthening that information. For example, they help candidates to rewrite each bullet point to fit frameworks like “Situation, Task, Action, Outcome.” They fix formatting, suggest rewrites, and highlight formatting inconsistencies. They’re really good at focusing on the tactics of writing a resume.

Tactics are fine. Everything I mentioned in the previous paragraph is important. But tactics are best supplemented with a good strategy. How do you know that your resume has the right information? You could describe work experience in an infinite number of ways. Demonstrate how your existing work experience makes you a good candidate for the job that you want.

Many reviewers ask, “How can you present this information in the best way possible?” I also ask, “How do you know that you included the right information?”

That might sound obvious, but it’s difficult to apply in practice. I know this from my own experience. When I review resumes, I ask candidates for the resume and job postings that interest them. In a vast majority of reviews, I demonstrate how candidates can include extra experience to more effectively show that they meet the criteria mentioned in the job description.

Resumes suck, but most jobs require one. Maximize the impact of your resume. Incorporate information from job postings, job descriptions, and any other relevant information, and use it all to produce a targeted resume.

A quick note: this is written for software engineers with previous work experience who want a new job in the field. If that doesn’t describe you, you might still find this useful but you should think about what’s different for your situation.

Here’s how I’d write my own resume if I had to write one today

The TL;DR of my strategy is to iterate from a generic resume to a specific one. Start with a baseline resume that reflects your experience to the best of your ability but is not tailored to a specific job. Then, find information about the jobs that you want. Take notes from the job postings. Rewrite your resume using the information in those notes.

And now, in more detail:

Step 1: Write a resume the way you normally would

Create a resume however you want. Modify an old resume or create a new one. I don’t care which. Don’t overthink it.

Personally, I modify my old resumes. They’re always written in LaTeX because when I was in college, I hoped that I would get street cred by ignoring decades of word processor innovations. I don’t know if this worked, but I’m too lazy to change my approach at this point. If I had to make a resume today, I’d dust off this file and modify it to reflect my most recent experience and remove irrelevant information. Then I’d relearn how to run LaTeX in The Year of Our Lord 2021.

Anyways, include all of the usual sections in your resume: name, contact information, experience, any relevant schooling, maybe relevant/interesting projects, maybe publication experience if you’re a researcher, maybe other things like security clearance if you have it and it’s relevant.

Your resume should resemble other resumes in your field. If resumes in your field tend to be compact, then your resume should be compact.

Spell check and proofread it. Be prepared to have a conversation about every fact on your resume. Just like you shouldn’t build a house on an unstable foundation, you shouldn’t mention something on your resume if you can’t back it up.

Step 2: Collect three or four relevant job postings that intrigue you

Find job postings that appeal to you. If you want to work for a specific company, find the available listings in the “Jobs” or “Careers” section of its website. Otherwise, look for companies offering the role you want.

It’s OK if you don’t know what job you want yet. Look for listings that appeal to you. Spend some time researching different companies and fields until you have identified a few job postings that stand out to you.

It’s important to collect more than one job posting. If you’re starting with a job posting from a specific company that you’re interested in working for, supplement it with similar postings from that company, or other postings from similar companies. Why? You don’t want to assume that any single job posting is complete. You will be mining these postings for data, and a single posting might omit something relevant to the job. But the more postings that you examine, the less likely that an important qualification will go unmentioned in any of them.

Step 3: Create a spreadsheet and aggregate data from the job postings

Make a table in a spreadsheet with 3-5 columns. The columns should represent different, and mostly non-overlapping, competency areas. Then, read through the job postings sentence-by-sentence, and add information from the job postings to these columns.

I typically create categories like these:

TECHNICAL SKILLS: Any hard skills that are explicitly named. Programming languages, operating systems, third-party libraries, applications, etc. “Experience with Python in Unix operating systems a plus” or keyword soup kind of things.

DELIVERY: Anything related to execution. The types of projects that you’ve designed, implemented, or delivered. Whether you’re going to be on a pager rotation. The size and scope of the tasks that you’re expected to complete. The types of financial, product, or technical outcomes that you’re expected to achieve (or have already achieved).

LEADERSHIP: This can take a lot of different forms. Information in this category might call out specific leadership roles, like tech lead, project lead, or management. They may want you to be proactive about suggesting product or process improvements. They may want you to mentor more junior engineers. If you haven’t been in the industry for long, it’s okay to skip this category, or merge it with COMMUNICATION.

COMMUNICATION: Anything related to interacting with other people. There are a wide range of skills that could fit here. It could be project management practices, how you work day-to-day with teams, expected response times for answering support tickets, ability to be a point-person for your team or for external stakeholders.

Tailor these categories to your specific field. If you are applying for research jobs, then you’ll probably have a RESEARCH category. The category names don’t matter too much. You only need a few that capture different concepts.

Now that you’ve made the categories, the actual work begins. Read through every sentence of each job posting and incorporate each piece of information from the sentence into at least one of the categories. If you encounter a line like “Experience with Go a plus,” then put “Go” under TECHNICAL SKILLS. You don’t need to record duplicate information. If two job postings mention Go, put it once. If two job postings mention working as a tech lead, put it once. Make sure that the information in each sentence is captured in your spreadsheet.

This can be time-consuming. It takes a while to process all of the sentences in the job postings. Thankfully, processing each subsequent posting will take less time once the first posting is finished. Job postings will have duplicate information. You only need to record the differences.

If something doesn’t fit into one of the categories, try to include it somewhere, even if you need a MISCELLANEOUS category. You don’t want blind spots in your resume. For example, senior+ engineers often overemphasize their technical skills and project experience, and underemphasize their soft skills.

Step 4: Modify your resume to address as many of the relevant competencies as possible

Look at each item that you recorded in the previous step. Look through your resume and ask yourself, “Does my resume address this? If not, can I add a new bullet point, or can I add relevant information to an existing bullet point?”

At this point, your resume might get longer as you add information to address criteria from the previous step. If this makes your resume longer, then rewrite the bullet points for brevity. Avoid making your resume significantly longer than when you started.

It’s okay if you don’t address every item in the categories that you produced. Again, you should feel confident in every item on your resume. Don’t add something if you can’t talk about it for 10 minutes in an interview. If a job asks for PHP experience and you’ve only written 50 lines of PHP in your life, leave it off your resume.

Step 5: Make the hiring manager want to hire you

People will look at each line of your resume and say, “So what?” To counter this, make sure that you explain the impact of your experience.

Think about the people making the hiring decision. This will differ per company. At a megacorp, the people hiring you might be a collective of managers or senior (or above) engineers. If you’re applying to work for medium-sized companies, the hiring manager will probably be in your management chain; either your manager or a boss of theirs. At a small startup, the founders might hire you themselves.

Make people want to work with you. The people at the megacorp want to prove that they consistently hire high performers. Your manager wants to know that you can function effectively in a team environment. A startup founder wants to know that you can ship.

Explaining your impact allows them to imagine how you would function on their team. Let’s look at an example that I made up:

A bullet point without impact: “Tech lead for a 3 developer team. Worked with design and product to implement customer-facing features in addition to tech lead duties.”

A bullet point with impact: “Tech lead for a 3 developer team. Worked with design and product to implement customer-facing features in addition to tech lead duties. Increased revenue $n million while maintaining a low defect rate.”

When you refer to a responsibility without describing the impact that you had, you’re just claiming that you did something. The impact helps you argue that you did it well. An engineer will think, “It sounds like they can ship code, and I can talk to them about why they had a low error rate.” A manager will think, “OK, they can function on a team.” A director will think, “OK, they help produce business results.” A founder will think, “OK, they get code out the door that gets results.” Either way, you’re telling them that you’re going to make them look good. “One additional strong developer! A team player! More money!”

Step 6 [optional]: Find a relevant career ladder

Find a career ladder that describes the job that you want. Then, look through your resume and see if you would hire yourself for the level that you want. If there are gaps, could you add any relevant experience to your resume to help fill these gaps?

This is optional, because it’s uncommon for career ladders to be published. But there are a few. For example, Etsy open sourced their career ladder. If you find a career ladder that covers your desired job, look at your resume through the lens of this ladder. Is your resume missing anything?

I understand that these ladders are mostly used for internal promotions, but hiring managers sometimes look at resumes and ask themselves questions like, “If this person were working for me, would I promote them to the job they’re interviewing for?” Don’t worry if you can’t find something. But if you can, use it.

Step 7: Proofread, spellcheck, and get feedback from real people

People reject resumes for the dumbest reasons you can imagine. There’s the apocryphal story/joke of the hiring manager who shuffled resumes, grabbed a handful, and threw them out, “because I don’t want to hire anyone that’s unlucky.” This is only untrue in the sense that these exact circumstances didn’t happen, but it’s depressingly easy to find forums where people say they would never hire someone, based on their resume, with arbitrary criteria that have literally nothing to do with job performance.

Strive to eliminate as many mistakes from your resume as possible. If you do literally nothing else, please run a spell check. Copy/paste your resume into Google Docs if your text editor doesn’t have a built-in spell checker. Spelling mistakes are easily avoidable, so you don’t have any excuse for allowing them to slip through. Don’t make someone second-guess you because you wrote your resume in Visual Studio Code without spell check.

Read your resume out loud. Ask people to review it. Look for inconsistencies, for example in the use of periods at the end of bulleted sentences, and in the formatting of dates.

Ask people to give you feedback; the more, the better.

Even if you disagree with your reviewers, ask yourself whether you could restate something to make it clearer, or improve your resume such that they wouldn’t have needed to give you feedback. If a reviewer raises an issue, then someone reading your resume at a company might think the same thing.

So, there you have it!

You can produce a resume that is tailored to the job that you want. Incorporate information from job postings and career ladders, explain your impact, and correct mistakes. It’s not difficult, but it requires some grinding. But it’s worth the time investment. It won’t magically get you a job, but it brings you closer to getting a hiring manager to consider your application and think, “We need someone like this.” You’ll be more likely to get to the next step.