The Trouble with Resumes

You’re reading an excerpt of The Holloway Guide to Technical Recruiting and Hiring, a book by Osman (Ozzie) Osman and over 45 other contributors. It is the most authoritative resource on growing software engineering teams effectively, written by and for hiring managers, recruiters, interviewers, and candidates. Purchase the book to support the author and the ad-free Holloway reading experience. You get instant digital access, over 800 links and references, commentary and future updates, and a high-quality PDF download.

While hiring teams often view resumes as the primary means of making top-of-funnel decisions, filtering candidates by their resumes is noisy, biased, and inefficient. Although little academic research exists on the predictive use of resumes in software engineering hiring specifically, research has been done on the function of resumes across all industries. An 85-year meta-analysis found that resumes (along with other traditional assessment methods like interviews) are very poor predictors of subsequent job performance.

Engineering managers tend to harbor the suspicion that engineers are better at reading technical resumes than recruiters: “We’re domain experts! We don’t need to rely on proxies and can actually tell what the candidate can do!” But even the most experienced, qualified engineers aren’t always on the same page when it comes to what makes a good technical hire. In fact, the more experience you gain, the higher the risk that you may be stuck in your own way of seeing things. This makes the static data of a resume a particularly poor alignment tool.

Interviewing.io recently conducted a study* in which researchers removed all personally identifying information (name, contact information, dates, et cetera) from a set of resumes, and showed them to hundreds of recruiters and engineers. For each resume, researchers asked participating recruiters and engineers just one question: “Would you interview this candidate?”

On average, participants correctly guessed which candidates were strong* 53% of the time, and there was no statistically significant difference between engineers and recruiters. Moreover, and even more importantly, people’s errors weren’t consistent. In other words, everyone disagreed about what a good candidate looked like in the first place.*

Figure: Distribution of Resume Scores

Source: interviewing.io

Academic and industry research has consistently proven that bias is a common problem in resume filtering as well. In a 2003 study on resumes by the National Bureau of Economic Research, experimenters submitted identical resumes to a series of help-wanted ads in the Boston and Chicago areas where the only difference between resumes was candidate name; some names were thought of as traditionally white and others as traditionally Black. Resumes belonging to candidates with “white-sounding” names received 50% more callbacks. These results were repeated in a 2016 study at Harvard Business School, targeting 16 metropolitan areas and including traditionally Asian names. Another study showed bias along class and gender lines in law firms.

​candidate​ As a candidate, you will increase your chances of being judged by your strongest attributes by doing everything in your power not to be filtered by your resume alone. If you have a resume with no name-brand schools or companies, the reality is that you’ll face stiff odds at companies with many applicants who do. And even if you have a degree from an elite university and employment with a top company, you’ll still have more luck advancing through the hiring process at any company if you can get into the funnel later, via a warm introduction, referral, or any other connection you can find. A few things to consider when building a resume:

• Attention to detail. Avoid typos, poor organization, or other easy-to-fix formatting problems. These can mean automatic rejection. Many people looking at a resume think, “If you can’t write one page without four typos, how are you going to do other work where attention to detail matters?”

• Provide context. When describing work, include context on your role (and how it fit into the team) and the business impact it had so reviewers know why it was important and how you performed. An ineffective, mechanistic description would be: “Worked on Java backend of the AcmeTronix 7000.” Something like this is far better: “Was main developer of backend of Acme’s e-commerce platform used for $1M/month in transactions. Led team of four.”

• Look forward. Highlight what you want your job to be, by writing your resume to show your aspirations, not just what you factually have done in the past.