Finding and Hiring Great Programmers
- Determining What Kind of Programmer to Hire
- Writing the Job Description
- Selling the Hire
- Recruiting Full-Time Employees (FTEs)
- Recruiting Contractors
- Reviewing Resumes
- Narrowing the Field
- Preparing to Interview
- Interviewing
- Making the Decision to Hire a Programmer
- Making the Right Offer to a Programmer
- Follow Up until the Programmer Accepts
- Summary
- Tools
A step-by-step guide to finding, recruiting, and hiring great programmers.
Save 35% off the list price* of the related book or multi-format eBook (EPUB + MOBI + PDF) with discount code ARTICLE.
* See informit.com/terms
This chapter is from the book
This chapter is from the book
This chapter is from the book
There are Many Programmers. However, there are not that many great programmers.
“Exceptional engineers are more likely than non-exceptional engineers to maintain a ‘big picture,’ have a bias for action, be driven by a sense of mission, exhibit and articulate strong convictions, play a pro-active role with management, and help other engineers,” said an insightful 1993 study of software engineers.1
Frederick Brooks in his classic work The Mythical Man-Month2 cited a study3 from 25 years earlier that showed, among programmers with two years’ experience and similar training, that the best professional programmers are ten times as productive as the poorest of them. The researchers had started out to determine if changing from punch cards to interactive programming would make a productivity difference, only to find their results overwhelmed by the productivity differences among individuals. They found 20:1 differences in initial coding time, 5:1 differences in code size (!), and 25:1 differences in debugging time!
Barry Boehm, 20 years later, reported a 25:1 difference between the most and least productive software developers and a 10:1 difference in the number of bugs they generated.4 In 2000, Boehm and coauthors updated their study to examine teams and concluded that teams of experienced top-tier programmers could be expected to be 5.3 times more productive than teams of inexperienced bottom-tier programmers.5
While there are some IT organizations that pride themselves on hiring “ordinary” programmers, there are few product companies and professional services organizations where you can be successful managing a software team without the ability to staff some part of your team with “great” ones. It’s no wonder, given the kinds of people programmers can be, that finding and identifying exceptional programmers can be a challenge.
Hiring is far and away the most difficult-to-undo decision that managers make. Being successful at staffing will ease the rest of your job. The worst of unsuccessful hires can cast a plague upon your team for months, undermine your leadership, incite dissension and strife, delay or derail your deliverables, and in these ways and in every other way demotivate and demoralize your entire organization. Not to mention how hard it is to get rid of underperformers and other bad hires.
If you’re hiring not only programmers but also managers of programmers, remember the rule Ron heard at Apple and Mickey heard directly from Steve Jobs:
Steve’s point was to emphasize how essential it is to hire top-notch managers, for the combinatorial effect they have as they make hires.
We’ve both been fooled. Ron had already been hiring for a decade when he interviewed a manager he was convinced would be a stellar contributor to his organization: “I was certain, given how well he talked the talk, that this was a guy who would really deliver. I called two of his references, and both shared stories and anecdotes that convinced me he’d walked the talk many a time before.7 My interview team was unanimous in making a ‘hire’ recommendation. It was a time when I’d inherited a bad apple or two, but I’d never hired one. Until then. I realized it fast and I acted quickly to communicate the change I wanted to see in his behavior. Luckily, when I called him into my office, not even two months on the job, for a change-or-leave meeting, it was he who opened the conversation: He didn’t feel like he fit; he was giving notice; he needed to leave. I was lucky.”
While it can happen, we’ve figured out a few principles that have resulted in the vast majority of our hires being good ones.
Determining What Kind of Programmer to Hire
It all starts with knowing whom you want to hire. You’re hiring not just a programmer, but also someone to fill a role and a need in your organization.
We outlined in Chapter 2 how to build a job description for the kinds and levels of programmers you need in your organization. But those are generic descriptions.
For individual hires, only by consciously thinking through the skill sets, values, ethics, and orientation you need are you likely to hire the right programmers for the slots you need to fill out your team.
Think through whether your focus will be on experience, or on energy and passion.
Do you need
A programmer who can mentor the team in best practices?
A coder with a mind wired to ferret out the gnarliest design flaw?
A designer who can sense the big picture and envision how your requirements can be broken up into modules and components?
A developer who is comfortable being proactive and collaborative with management?
Or do you need
To churn out thousands of lines of code in short order?
To prototype features important to your customers that your veteran programmers blow off as “fluff”?
The flexibility and speed to iterate routines over and over as their essence becomes clear?
These are not mutually exclusive sets of characteristics. But the former type of programmer is more likely highly experienced. And the latter type is more likely a fresh, passionate one. Be conscious of which you need.
You also need to know whether you are better off with a full-time employee or a contractor.
Do you need
A programmer for the long term?
A fully integrated member of the development team?
A developer with an evolving set of skills and tools whom you expect (and are willing) to train and grow over time, as needs or technologies change?
Or do you need
A highly developed set of specialized skills and tools now?
To fill a short-term need?
The former is likely an employee; the latter, a contractor.
Finally, will you consider distant candidates, either to move them to your location or to have them work remotely? Are you unable to find the candidates you want in the local pool, or is the skill set you need so rare that there is no pool of candidates, short of thinking regionally or nationally? Can you afford to pay moving costs? Or are you up to managing a geographically distributed team?
If so, you’re likely to find yourself conducting some or all of your interviews by phone or videoconference. Conversely, you can leverage national trade shows and conferences to meet and recruit programmers who are uniquely qualified.
While at Apple, Ron frequently sought out hires at the Applefest and MacWorld and OOPSLA conferences. After giving a talk one year, he was approached by a programmer with laryngitis who was madly scribbling messages on pages of a 3” × 5” pad to communicate his interest in Apple. It was an odd approach, but he soon became a stellar Apple hire.