You’re a software hiring manager! Yay! Or maybe you despise the idea, but either way it is now your job to sift through resumes until your eyes bleed. At this point in my career, I have been through hundreds upon hundreds of resumes as a hiring manager at multiple companies, and today I would like to share some of the things that I have learned while sorting through all of those resumes.  

How to Scan a Resume

To start with, the most important skill I have picked up in reviewing mountains of resumes is how to do a quick initial scan of a resume. The goal here is to eliminate the candidates that are a poor fit as quickly as possible, while not eliminating anyone who could be a valid contender on deeper inspection. In a quick scan of a resume we’re looking to eliminate the truly, deeply unqualified resumes.

Experience

When scanning a resume, I always start at the bottom. The first thing I want to know is whether the candidate meets the minimum level of experience I am looking for. In this phase, I usually give two years of leeway in case there is a candidate who has excelled and made better use of their years of experience than most. For example, if I am hiring for a position that requires 5+ years of experience, I will immediately eliminate anyone with less than three years of experience in the scanning phase. Be sure to account for gaps between jobs, don’t just subtract the oldest date from today’s date.

Job Jumping

While I’m scanning the dates at various jobs, I also pay attention to the duration at each position. This isn’t so important if the candidate only has a few years of experience overall, but if I have a candidate who has changed jobs multiple times a year for ten years, that is reason for removal from consideration. In a long career history, I want to see at least one job that a candidate held for 2+ years. I don’t care what the reasons are, if a candidate is jumping jobs that often, odds are good they will jump jobs again in short order.

Do-or-Die Keywords

Keyword searching in resumes is a dicey topic because keyword searches tend to eliminate viable candidates. I would suggest that you pick two or three do-or-die keywords, the things that you would never consider hiring without, and use those to eliminate resumes in this phase. For example, if I am hiring for a position that absolutely must have Kafka experience, and experience in no other tools will do, I would use the lack of that keyword in a resume as a disqualifier.  

The Deep Dive

By this point, with less than a minute invested into each resume, we should have eliminated a significant percentage of the original stack of resumes. In my experience the quick scan eliminates about half of all candidates, but YMMV. Now is the point where we invest some real time into each of the remaining resumes.

Spelling and Grammar

This is something that will matter to a different degree depending on the position you are hiring for, but here are a few things to consider:  

  • If you are hiring for a frontend UI position, spelling and grammar errors are immediate grounds for eliminating a resume. If a candidate can’t get their spelling and grammar right on a resume that they have had limitless time to prepare, they will not get the spelling and grammar correct for your product.
  • For a backend position, I might let a grammatical error or two slide, but poor spelling is generally unforgiveable because everyone has access to a spell checker. If they don’t pay that much attention to something as important as a resume, they will likely lack that attentiveness to the code.  

    Structure

      Code and writing are both products of the author’s mind and offer a window into that world. If a resume is excessively long and rambling, I would expect the author’s code to be similarly long and rambling. If a resume is poorly organized and lacks a clear hierarchy, I would expect poorly organized code. If there are dubious design decisions in a resume, I would expect dubious design decisions in UI written by the same author. Writing and coding are not exactly the same thing, but structure should be taken into consideration when forming an overall picture of a candidate.

The Last Two Jobs

Reading about a job that a candidate had five or ten years ago can provide some context about the character of a candidate, but almost all of the useful information will be in their most recent two positions. The information in those positions will tell you what the candidate is interested in now and it will tell you what they are well-practiced in now. When I hire a candidate, I want them to hit the ground running and be excited about what they are doing. What they were doing five years ago is not a very good indicator of that compared with what they have done in the past two to three years.

Keywords Revisited

In the scanning phase, we quickly eliminated resumes based on the lack of a few primary keywords. This time, we’re looking for how they actually used these important skills. For example, compare the following resume bullet points:

  1. Made UI components using React
  2. Developed a styleguide of 50+ React components

  The ambiguity of bullet point 1 tells me almost nothing. For all I know, this engineer dabbled in React for a few hours, so I’m not sold on this point alone. The specificity of bullet point 2 tells me something very important: this candidate has spent significant time using React in a production environment. Keywords are important, but context is everything.

Significant Achievements

Achievements outside of work can make a huge difference in my perception of a candidate, but they must be notable. Here are a few examples:  

  • Coauthored and published a book about [major framework]
  • Winner of the Hackathon at [major conference]
  • A top contributor to [notable open source project]  

    On the Fence

If you’re truly on the fence about a candidate, move on to the next resume. Come back to that resume when you are done with the rest, and you will likely have a new perspective on it. Next, ask for input from a coworker. If you have spent more than ten minutes trying to decide on a single resume, move ahead to a thirty minute phone screen because at that point you’re using up enough time that you should just make the investment. The phone interview should clear up the points that were causing hesitation, for better or worse.

The Bottom Line

When all is said and done, I usually allow about one in three resumes to pass on to the next phase. The time spent in the resume review phase is very cheap compared with time spent in the following phases where you invest more of your own time and that of other people. By eliminating a significant number of resumes up front, you can save yourself a lot of time, but by having a good process you can ensure you don’t eliminate potentially great hires.