The past couple weeks I’ve been looking at a lot of developer resumes and I’m once again reminded how difficult and exhausting the process can be. Over the years I’ve slowly built-up a system to help me manage the process and I thought I might share what I’ve learned. This is certainly not to imply that my system is perfect or that I have everything figured out. However, if like me you feel like you’re groping in the dark for how best to review developer resumes then perhaps this post can be a starting point for you.
It’s a hard problem
I think the first thing to say is if you’re feeling overwhelmed by the problem it’s not your fault. This is a fundamentally hard problem.
Let’s say you have 100 applicants to a developer position. Well you can’t interview them all so instead they give you a piece of paper that’s meant show why they should be one of the 10 you actually decide to interview. We call these resumes and it’s considered normal but if you really stop and think about it it’s kind of an absurd proposition. How long does it take to really get to know a person? Weeks? Months? Years? And yet we expect to somehow determine by looking at a piece of paper for 5 minutes which of these applicants is best for the position? I don’t think so.
No, the first thing you’re going to have to accept when undergoing this process is that you’re going to get it wrong. You will accidentally reject people who would’ve been a great fit. There’s just no way around it. I’ve personally rejected people who ended up doing great things and I’ve regretted it. And some of the best hires I’ve made almost got rejected based on their resume.
The more I experience the hiring process the more I realize how arbitrary and random it can be. You will do your best to find the best fit for the position but you will make mistakes and it’s not your fault. So don’t beat yourself up about it!
This is directly related to the first point. Recognizing that the process can be very arbitrary and random it’s important to be humble about it. It’s easy to fall into the trap of being dismissive or even cruel about the little pieces of paper in front of you but it’s important to remember that they represent real people. Chances are they’re actually quite smart and while they may not be what you’re looking for they’re probably very competent people with strengths of their own.
Understand also that writing a resume is skill of its own that is largely unrelated to the actual job of software development. Some people just don’t know how to write a good resume but they might be excellent software developers. Even if they’re good at writing resumes they can’t read your mind. You probably have in your head a handful of things that matter to you and that you consider important to the position. Unfortunately they don’t know what those things are. If they’re smart they might’ve tailored their resume based on the job description but even then most employers are bad at articulating what they actually care about in the job description.
Writing a resume is hard. At least as hard as reviewing one. It’s important to leave cynicism at the door when you’re trying to find the best fit for your team.
Define what matters
Like I said before, most employers are bad at articulating what actually matters to them in the job description. And typically that’s because they haven’t really thought about it themselves. It’s important before you begin the process to sit down and really think about what you value.
Do you really need someone with experience in a specific technology or can you hire a smart person who’s willing to learn? Do they need to have 15 years of experience or is your team capable of supporting a junior developer? Does your team need someone to lead and organize or do you need someone who likes to be heads-down and focused?
These are important questions that don’t have right or wrong answers but are still important when it comes to building your team. I think the default behavior is to assume that you always want to hire someone with many years of experience with the exact technology that your team uses but depending on your team dynamics that may not be the case. Sometimes the plucky junior is exactly what you need and sometimes a little outside perspective from a different technology can help you solve problems better.
This is where we bust out our handy-dandy spreadsheet. List out all the candidates in the rows and all the attributes you care about in the columns like so:
Then you’ll need to come up with some kind of formula for ranking the candidates. It doesn’t need to be fancy. It’s probably something as simple as:
portfolio + (2 * leadership) + passion
Do your homework
Hiring managers often have a sort of machismo when it comes to reviewing resumes. You might hear one proudly say something like “I review every resume in less than 2 minutes!”. While I understand where that mentality comes from I don’t think it’s ultimately very helpful when it comes to identifying good candidates. Obviously you have to work within time constraints but ultimately you’re not trying to review them quickly you’re trying to review them well.
I’ve found on average most resumes can be reviewed very thoroughly in under 10 minutes. That’s not to say that I always spend 10 minutes on every resume or that I limit myself to 10 minutes. The main thing is to do it thoroughly.
What do I mean by thoroughly? Well, in general my goal is to really understand everything they’ve put on their resume and then some. I want to understand the details as well as the big picture. If they’ve written a cover letter I definitely want to read it. If they list a portfolio or some projects they’ve worked on I want to check that out. Even if they don’t list anything on their resume I’ll probably try to find their Github or their blog if they have one. Some resumes don’t require much time but if you find something interesting keep digging!
Don’t ignore the cover letter
I will typically start with the cover letter. Most cover letters are generic and basically pointless. But a good cover letter that is tailored to the position and the organization can be a great sign that the individual actually cares about the position. It’s rare but it can be a good data point that frames the rest of the resume.
The big picture
Usually I’ll review the resume from the bottom to the top because it’s often a better way of understanding someone’s overall career trajectory. A good resume will have the most important things right at the top and that’s super helpful. However, once I’ve scanned for that I will then jump to the bottom and start reading upwards. At this level I’m trying to get a general sense for how I’m going to score the candidate on my defined attributes later. How many years experience do they have in technology X? Have they held leadership positions or otherwise demonstrated leadership qualities? Do they demonstrate through their accomplishments and their words that they care about what they do? At this level you’re trying to find evidence that they have the predefined attributes you’re looking for but it’s important not to get tunnel-vision!
Find the best in people
A candidate may not meet your predefined criteria and yet they might be exactly what you need. It’s okay for your criteria to evolve and often you’ll realize a candidate has some attribute that you actually value and that you’d like to add to your predefined attributes. So don’t be too quick to dismiss them. If you feel like you’re reading a “bad” resume take a moment and try to figure out what makes this person awesome. Everyone is awesome in their own way. Thinking like that will help guard against cynicism and it might provide insights that could help drive the entire process!
The devil’s in the details
Don’t gloss over things you don’t understand. You might find something interesting and it’s also a good opportunity for you to learn. If they list a technology I’m not familiar with I’ll go and look it up just to understand at a high level what it is and what it’s for (this is actually a pretty cool way to get exposed to new ideas by the way). Or if they list a company I’m not familiar with I’ll look them up (this can be a good way to get an understanding of your local job market and beyond). I’ve lost count of the number of times I’ve looked up something I didn’t understand that ended up being super interesting and relevant.
You’d be surprised some of the cool stuff people leave off of their resumes. I’ve found side projects with hundreds of commits and active, well-written blogs that the applicant didn’t mention. Whatever the reason, you can often find some valuable data points about the candidate with just a couple google searches that you otherwise wouldn’t get if you only looked at the resume.
The portfolio is King
Not everyone agrees but for me the portfolio is King. Now, I’m well aware that people have lives outside of work and not everyone has the time to work on interesting open source side projects in their free time. It’s certainly not the only data point I use when evaluating candidates. However, as a hiring manager it makes the hiring process a lot easier. Ultimately all the interviews and ritual of the hiring process are about answering some simple questions. Are you capable of doing the job? Will you produce quality work? Do you care about what you do?
If a candidate is regularly writing quality code that I can actually see then I’ve pretty much answered those questions and I almost don’t need to interview them.
Scoring the candidate
So, having thoroughly reviewed the resume next comes the “easy” part. I say easy because you don’t want to overthink it. My recommendation is just to assign a value from 1 to 5 on how strong you feel they are in your predefined attributes. There’s no science to this. It’s pretty much based on your gut instinct after having thoroughly reviewed their resume. You can’t really know whether your assumptions are true based on the resume alone. But the idea is someone with no leadership experience in either their personal or professional life might get a 1 while someone with 20 years experience as a leader might get a 4 or a 5.
To generalize, 1 represents little or no knowledge, 2 represents a basic understanding, 3 represents competence, 4 represents proficiency, and 5 represents truly exceptional mastery. 5’s should be pretty rare. You have to leave room for the truly remarkable candidates. Don’t worry too much because you’re not just going to blindly follow the numbers. The numbers will only serve as a guide to help you see which candidates rise to the top. At end of you’ll end up with something that looks like:
Tuning the formula
Now you’ve got a bunch of raw data that more or less represents your general impression on the candidates’ abilities in different areas that matter to you. And you’ve got some sort of crude formula to rank them proportionately based on how much you care about each of those attributes. Now you can take that raw data and sort it by your ranking formula. You’ll end up with something like:
There’s no perfect formula but eventually you should have a system that generally brings the best candidates to the top. You’re not going to blindly follow this ranking. There may be some candidates near the top that your aren’t keen on and some that you like might be further down than you’d expect. Chances are there are attributes you just aren’t aware that you value or don’t know how to articulate. It’s worthwhile to reflect on what those attributes might be but you don’t want to drive yourself crazy over it.
Deciding who to interview
Once again, there’s no perfect formula so ultimately deciding who to interview will come down to your gut instinct. In some sense this last step becomes the easy part. By using the formula you can narrow the scope from hundreds to maybe the top 20 or so. And by reflecting on the attributes that matter most for the position you should have the clarity needed to make the final decision. From there it’s just about following your intuition and hoping for the best!
Hopefully this post is a fairly practical and mostly un-opinionated primer if you find yourself feeling overwhelmed with trying to review hundreds of developer resumes. I’ve given a handful of talks on the subject of hiring in general but because it can be such a controversial topic I suppose you could say I haven’t had the courage to publish my opinions to the wider world. If the feedback is positive I’ll consider writing more about the hiring process. To that end, make sure you leave me some feedback in the comments or however you prefer to do so.