- 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
Preparing to Interview
Once you’ve got candidates who look like they might be a fit, it’s time to interview.
The first interview is by phone, a screening interview. You need to find out
If the candidate is still interested
Whether the candidate is interviewing with other companies (and what the time frame is with those companies, whether the candidate already has other offers, is considering them seriously, and when a decision must be made)
What kind of job the candidate is looking for
What the candidate considers to be their areas of expertise
What compensation is expected
Why the candidate is looking for another job
The candidate’s availability to start working for you
Whether the candidate is willing to commute to your location if working in your offices is a requirement
Ask candidates to describe in detail what they have worked on, both for you to gain confidence that they actually did what they said, but also to know that they can explain what they have done and what they know. Drill down into one or two of the accomplishments they cite to confirm that they have the skills you need.
For a highly specialized technical position, you may want to choose a highly technical team member to conduct a second screening to test expert knowledge the candidate claims to have and that you need.
Once you confirm that candidates are credible—that they appear to meet all your criteria—you’ll assemble an interview team. Then bring in two or three leading candidates for one or more rounds of interviews with your team, your colleagues, and perhaps your boss.
The job description you prepared earlier, such as our sample one in Figure 3.1, should provide all the criteria you’ll use to qualify a candidate and measure one against another. The challenge is to remember to test every candidate against all those criteria, and then keep track of how the candidates stack up against them and each other. Mickey long ago came up with the spreadsheet format in Figure 3.2 to help him do that. Enter your criteria into a similar spreadsheet to keep track of your candidates and their qualifications.
){kind=link}
)
FIGURE 3.2 Principal programmer interview summary
Plan a strategy for who will pursue which skills and qualities, and additionally who will help you sell the candidate on joining the company. (It works both ways.)
The interviewers you assemble may include
You
Your HR or staffing person
Programmers who are the technical leadership on your team
Programmers from related teams with whom your hire will need to interface
Your UI designer
The product manager
The project manager
Another development manager or two (particularly if you’re green at hiring; another manager’s observations and feedback can help you with what to look for and how to look for it)
Others in the business from whom the programmer will get requirements or collaborate around product and support issues
Your boss (or even your boss’s boss)
In one company, Ron’s CEO asked to interview every candidate to whom Ron thought he would want to make an offer (provided the CEO’s travel plans or other conflicts did not hold up the hiring process); he wanted a head start with new hires for his goal to know everyone in the company, considered it a “touch test” to build confidence in his senior managers’ hiring IQs, and offered the gift of his time to assist with the sometimes challenging task of luring highly qualified developers who were choosing among competing offers.
On the other hand, earlier in his career at a much larger company, Ron’s midlevel boss gave him carte blanche to hire without the boss interviewing a single candidate. At a third company, not only his boss but also his boss’s boss were on the interview schedule. You’ll likely have managers of every stripe as well, but if they interview, they’ll almost always want to be last to do so; most will want to see just the “keepers.”
Mickey and Ron would both rather have more interviewers than fewer. When hiring FTEs, Ron typically selects two teams of four to five interviewers for a first and second round of 45- to 60-minute one-on-one interviews. Get to know how long your interviewers prefer for an interview. Some will be like Ron, who wants a full hour with candidates, whether his or another manager’s candidates; others are happy with 30 minutes and uncomfortable with even five minutes longer than their requested time.
Programmers are critical interviewers. They will have to work and team with the new person. They also likely know the skills and experience that are needed or missing better than anyone. But programmers are also generally the least prepared to interview. You need to spend time with new interviewers to go through the technical and team qualities you want candidates to bring. Then you can work together on questions and exercises they can pose that will help reveal the candidate’s facility.
Assign areas of focus for your interview team members: the various technical skills you need; analytical, problem-solving, communication, and interpersonal skills; and résumé red flags and omissions. Make sure you have interviewers who will ask technical questions that demand technical answers. Divide up the candidate’s projects and companies among your interviewers, so that someone digs into the details of each one. And divide up the qualities you’re looking for, both to ensure that among your team someone is pursuing understanding of that quality as well as to avoid a day of interviews where everyone asks the same questions. A wiki page or other collaborative online space is perfect for letting your team sign up for those areas about which they feel most competent or most passionate.
All that preparation will help ensure that your interviewers are prepared. Too many interviewers in too many companies read a résumé five minutes before the person comes in—or on their walk to the lobby to pick up the candidate—and end up contributing a fraction of the thoughtful, in-depth understanding that a well-grounded, well-thought-out interview should produce. The entire interviewing team must be clear on the need for this hire, with whom the new hire will work, and what the new employee will be tasked to contribute. Then each interviewer can create initial specific questions, using the résumé to guide further questions when probing into the candidate’s experience and background. Interview training is something that is not often given to employees, but the cost of hiring the wrong people far outweighs that time and effort.
When you’re hiring programmers, you have to get at their ability to code. It’s essential to answer questions that elicit a picture of their understanding of programming. It’s critical that you ask them to do some design and to write some code.
Encourage candidates to bring a portfolio of projects—documentation they’ve written, designs they’ve created, samples of their work, and even demos on their laptops or online that demonstrate their prowess.
Then ask the candidate to show you an app that they built. Evaluate the user experience.
—DAVE WILSON
Sometimes doing this can have unexpected effects. Ron’s youngest hire was, at Apple, an intern just out of high school. Ron had heard, through a connection, about the young programmer’s prowess but wasn’t sure his team would embrace a high school kid. As it turned out, the young programmer brought in samples of random-dot wall-eyed auto-stereograms; he had read about the technique of hiding 3-D scenes in images that at first glance appear to be nothing but random dots, and he’d figured out how to reverse-engineer a program to create them. As Ron watched his team squint wall-eyed at the samples pinned to the team wall, willing the 3-D images to emerge, he knew he had a fit.
As you set up a morning or afternoon or day of interviews, you need to plan for someone to be the first to greet the candidate, and someone to see them out. As the hiring manager, you’re a strong candidate to fill at least one of those roles. Taking the closing role can be a great opportunity to debrief candidates on their perceptions of your company and your team, try to correct any misperceptions, and send the candidate off with a positive impression.
Ron also tries to have a trusted strong interviewer lead off—and report back at once if the candidate seems at all a bad fit. There’s no use wasting the candidate’s or the team’s time further if you determine up front that the match isn’t there.
If possible, take the candidate and at least part of your team to lunch. The interactions you’ll see will be priceless for making a decision about whether the candidate has “team fit.”
Mark Himelstein, an Interim VP of Engineering in the San Francisco Bay Area, prepares his interviewing teams by going over
What the person is being hired for
Issues/areas to be covered (making sure that someone is covering the basics)
How to sell the company consistently
He notes, regarding selling the company, “I have used role-play to teach developers how to sell the company consistently. We agree on the point I want each to make, then I have them use that point to sell the company to a colleague in 120 seconds. I have the team offer critiques to their peers on how to improve the pitch.”
Finally, do candidates a favor by presenting them with an interview schedule when they arrive that includes times and interviewers with their titles and (should the candidate want to follow up) e-mail addresses. Having your greeter not only present it but draw a verbal picture of the interviews ahead and who the interviewers are will put your candidate at ease and get logistics out of the way so that you can all focus on fit.
Take a look at the sample interview schedule in the Tools section.