- 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
This chapter is from the book
This chapter is from the book
This chapter is from the book
Writing the Job Description
Your hiring effort begins with writing a job description suitable for posting. Keep in mind that the objective of this description is to attract the largest number of qualified candidates—it’s a marketing brochure for the position. It should be specific about what you’re looking for to discourage the unqualified, broad where you’re open to a wider set of talents, and persuasive about the company as a great place to work and the position as an ideal opportunity for your kind of programmer, highlighting the social significance, career visibility, and lasting value of the contribution the right candidate can make.
In a small company, writing job descriptions will likely fall to you. In medium-size and larger companies, the staffing or HR organization will prepare these, but you should plan to collaborate on or edit them if not outright provide all or most of the job description and requirements. Unless you actually write the posting and are certain it will be run verbatim, it’s wise to ask to be included in a review cycle. We have seen job postings (some of them appearing in expensive display advertising space in Sunday newspapers) that are inadequate and sometimes downright embarrassing due to rewrites of requirements and use of maddeningly ancient boilerplate by wellmeaning but nontechnical recruiters.
If you’re writing the posting yourself, you’re probably thinking you’ll draw it from the internal job description; we showed you a sample in Chapter 2. But that’s really barely a start. It lacks both job-specific detail and the sparkle to attract candidates.
For example, while “Programmer 3” may be a fitting title within your organization, you’ll need one that is both more meaningful and more descriptive of the background and technology experience you’re looking for candidates to have. The other key qualifier that most job seekers use to determine if a job might be a fit is location. “San Francisco Bay Area” is much too general; in a good economy, a programmer trying to minimize the commute will skip right by your listing rather than try to figure out where in the 100-plus-mile Bay Area the job actually is. Be specific.
That will lead to titles such as
Entry-Level Ruby on Rails Programmer—SF Peninsula
Experienced Full Stack Programmer—Cambridge
Oracle Programmer with BI Experience—South Bay (SF)
Java Architect—Denver
Support Engineer, .Net/Sharepoint—Vancouver
Principal Programmer, Engines Team, Search Technologies—Austin
(The latter title, since it doesn’t specify C++ or Java or Python, might be for a role where you’re much more concerned about finding a candidate with strength in algorithms, data structures, and system software internals than with specific language or platform experience.)
If telecommuting three days a week is possible, the top of the listing is the place to put that, as the example in Figure 3.1 shows.
)
FIGURE 3.1 Sample job description
Now come the key elements of your job posting. The first is a brief summary of the company and its product(s) with your focus on why a programmer would want to join you there. This paragraph is about selling, so if you’re not used to writing compelling copy, get one of your sales or marketing colleagues to help.
Next is a job description that is specific to the job for which you’re hiring. Here again, the internal job descriptions in Chapter 2 are too general for recruiting purposes. What coding, design, and architecture do you need this programmer to create? What special technical skills and knowledge do you need? What best practices experience do you expect as a minimum qualification? Are you looking for someone to lead or mentor other programmers, or give them technical direction? Do you need a communicator who can collaborate with your business partner? A technical guru who can translate business requirements into technical ones, or even directly into architecture? A mathematical wizard who can turn business requirements into complex analytical algorithms? A UI designer who from business requirements can conjure up a brilliant UI that users just intuit?
Now you’re ready to describe the skills you’re looking for. This is the time to describe the language and platform experience you need, in detail, along with the level of skill and knowledge you expect. You should also be specific about the experience you need candidates to have with leadership, management, project management, communication, analysis, design, architecture, and coding. Are you hoping for a programmer who takes direction and just codes? Or a programmer who gives direction? How many years of experience? Education? (There is no consensus regarding the extent to which education is a predictor of programmer success, so we would not recommend making a degree an absolute requirement short of some statutory requirement or some organizational quirk that would make lack of a degree a predictor of failure.)
Sometimes follow-through, attention to detail, and a sense of ownership can be more important than specific skills. Don’t ignore these “soft skills” when crafting your job descriptions and during the interview.
Divide skills into “required”—what you absolutely won’t hire without— and those that you would really consider a bonus in a candidate who has the required skill set.
Also consider whether travel will be required. Disclosing it here will increase your chances for a good fit long-term.
Finally, don’t forget to give candidates a way to contact you—an e-mail address, usually, as well as your Web address.