As a rite of passage, every software management author has to give their take on the hiring process (Joel’s, Erik’s, Paul’s). This is mine.
In an ideal world you would take as long as you want to fill a position. This would allow you to be very picky about who you interview and even pickier about who you hire. I’m a staunch supporter of this approach and tend to be a pretty harsh interviewer as a result; at times interviewing 30 or 40 candidates before giving someone the nod.
But sometimes you don’t have the luxury of spending four or five months to fill a position. There may come a time in the life of your company when you’re faced with more job openings than you have developers, and you need to hire people in a hurry.
Hiring Fast
The best example of this is a venture funded start-up. Start-ups backed with venture capital are on strict deadlines to reach financial goals or risk having their funding eliminated. As a result they consume new hires with an insatiable hunger, and more than once I’ve seen situations where the development team needs to grow two or three times its size in the span of a few months. If you’re a manager in this situation you’re forced to leave conventional wisdom behind and enter a mode of hiring fast rather than hiring perfection.
Take this not-so hypothetical situation: your current team of 6 developers needs to be at 22 people in 4 months. You have 16 open positions, more than 2.5 times the number of developers on staff, and you need developers who can hit the ground running.
I think I just heard someone scream.
We could argue all day about the drawbacks to growing a team this quickly, but assume that you’ve been told to hire 16 developers or find yourself a new job (hire or be hired, in other words). Think about it in these terms: any start-up attempting to dominate a rapidly-growing market must take this approach or be consumed by competitors who will.
So the question is: how can we modify the strategies of conventional hiring without throwing them out entirely?
Hiring fast consists of the following steps:
- Write the Shortest Job Description Ever
- Skim Resumes Like Crazy
- Use the Numbers
- Hold Phone Interviews
- Finish In-Person
1. Write the Shortest Job Description Ever
Don’t kid yourself, job hunters don’t read long job descriptions. They read bullet points, skip to the required skills section and submit their resume. The shorter your description is, the higher the likelihood you’ve adhered to the single most important tenet of good writing: brevity. A long job description usually means the person writing it doesn’t really know what the candidate will be doing once she’s hired (what I call the kitchen-sink approach). Aside from the Pope, there’s not a job on earth that requires a three page description.
If your description is longer than half a page (three quarters if you use a lot of bullets), revise it.
2. Skim Resumes Like Crazy
Hiring is about playing the numbers; as a manager you’re trying to maximize the chance that the person is going to fit. Since we don’t have time to meet every candidate in person we rely on other means such as resumes and phone interviews to give us a picture of a candidate’s abilities. A resume can get you about 20% of the way, with phone and in-person interviews taking you to 80% (the highest you can get without actually working with someone).
Most managers take resumes too seriously. If you’re spending 15 or 20 minutes reviewing a resume you’re better off spending the time on a phone interview. You can tell a lot more from a conversation than you can from a piece of paper.
Your sole task when reviewing their resume is to decide if the candidate is worth talking to on the phone. You must become fast at skimming resumes; you should be able to evaluate one in 3-5 minutes.
3. Use the Numbers
In his book, Winning, Jack Welch, former CEO of GE, introduced a concept called Differentiation that consists of rating each employee as an A, B, or C according to performance. Intel uses a similar approach. The intent of these scales is to create a common, familiar method of ranking employees. The exact scale is not important; using a consistent metric everyone can understand is the key. In my experience a 10-point scale works best.
My dad has worked in the construction industry since people built skyscrapers out of dirt, and he learned early on how to evaluate electricians. His method is something I call the Rule of Thirds: on a 10-point scale you make money with your 7s, 8s, and 9s, break even with your 4s, 5s, and 6s, and lose money with your 1s, 2s, and 3s. There are no 10s in that list since no one is perfect; the highest possible rating is a 9+.
In every job search there are hires, maybes, and no-hires. Using the Rule of Thirds, 7-9 is a hire, 4-6 is a maybe, and 1-3 is a no-hire.
The only difference between hiring slow and hiring fast is what you do with the maybes; when hiring slow the maybes become nos, when hiring fast you let the maybes proceed to the next round of evaluation. If you’re at the last round (the in-person interview), you should never hire anything less than a 5.
In general, a developer with killer technical ability but so-so people skills is a 7. A developer with fabulous people skills and so-so technical skills is a 6. Someone with the complete package can range from an 8 to 9+.
The key to hiring fast: Always hire 7-9s, never hire 1-4s, and hire as many 5s & 6s as you need until you can find more 7-9s.
4. Hold Phone Interviews
From the time you receive a resume to a scheduled phone interview should be no more than two days. This may sound fast, but it follows from the fact that the best candidates are hired very quickly, if they hit the job market at all. Executing quickly is critical to finding 7s, 8s and 9s.
Phone interviews are the next step of evaluation after reviewing a resume. First round phone interviews should be given by hiring assistants or recruiters and consist of 5-10 short answer technical questions. If the candidate makes it through the first phone interview, call them yourself and ask 10-15 in-depth technical questions. You should keep this call to 20 minutes.
Here are a few tips for this phone call, which is your first real contact with the candidate:
Start with Banter. Psychologists say that 55% of communication is non-verbal. I’ve found that people tend to be very nervous during phone interviews due to the lack of visual cues, and nervous candidates are less likely to give you a true picture of their capabilities. Put them at ease with an introduction and some small-talk, typically relating to something other than work.
Give Them An Outline. Continue with a quick rundown of what to expect during the call. You’re dealing with developers so known, logical steps are helpful.
Ask for Clarification. Next, try to get to the bottom of any ambiguous statements on their resume. This typically involves asking about specific details of their current position, including why they want to leave. Also ask about any outrageous claims or discrepancies.
Ask Technical Questions. Candidates tend to get nervous when answering technical questions so be sure to explain how many questions you’re going to ask and to let them know that you’re not looking to pass or fail them, rather to get an idea of their strengths and weaknesses. Try to stick to more conceptual subjects like architecture and basic programming concepts, as opposed to language specifics.
See If They Have Questions. Since you are their first technical contact with your company they will typically have questions about the size of your team and whether there’s free soda in the lunchroom.
If the candidate is obviously an 8 or better, try to schedule an in-person interview at the end of the call. If not, close the interview and use their 1-10 ranking to decide how to proceed.
6. Finish In-Person
The in-person interview has been discussed in so many articles that I’m not going to beat it to death here. Joel Spolsky’s Guerilla Guide to Interviewing has a good outline for an in-person technical interview. Here are a few of my thoughts:
- Ask a few technical questions that don’t have specific answers and observe how the candidate responds. There are plenty of smart developers, but someone who can translate complex concepts into words is an exception.
- Ask them to write code and watch how they approach the problem. Recursive questions are always fun and help indicate whether or not they understood the things they were taught in their computer science courses.
- Ask any additional technical questions you haven’t covered before now. This is your last chance before making a decision.
- Finally, if you’re at all interested in the candidate, be sure to evangelize your company and answer their questions to the best of your ability. You’re almost to the point where you’re going to make them an offer, so you want to convince them that working anywhere else is a mistake.
Once the interview is complete, use their 1-10 ranking and the Rule of Thirds to help with your hire/no-hire decision, keeping in mind you should never hire less than a 5.
If hiring were easy it wouldn’t be the subject of so many books, articles and seminars. Hiring technical people is extremely challenging, and hiring a whole slew of technical people in a short time can feel like parting the Red Sea. My hope is that this article lends some guidance when you’re forced to hire like a start-up.
