Programmers come is as many flavors as Ben and Jerry's and with just as many nuts mixed in, so you'd better know what you want. The selection process only gets harder when you start branching out and looking for technical writers, multimedia developers or other less conventional roles. So the first step is to think hard about your requirements. The normal way of documenting an opening is a job description that sets expectations correctly and helps all those involved in interviewing work consistently.

A job description may contain such things as job titles and levels, but these are really secondary material designed to keep HR occupied between meetings. The real description has two purposes: to crystallize the exact nature of the opening, and to help derive the qualifications and experience the ideal candidate will have.

Just like writing a specification for an app, you can approach it from two directions. One is to work out the needs to be met and the other is to enumerate the functions. Normally, working from the needs in gives better results as it allows more flexibility in the implementation stage, in this case selecting a candidate. When hiring someone this means starting with statements like "The successful candidate will be responsible for building and maintaining bridges from the intranet server to legacy databases."

From that statement you can get a clear indication of the kind of skills and experience required for the job, rather than stating up front that the candidate will know Blue Lobster and have three years experience in C++. By stating both these views of the job in your description you can be sure that all your interviewers are singing from the same hymnal. The fundamental rule here is to eliminate ambiguity: if you, a colleague, an agency or the candidates can read a significantly different interpretation into the description, you are in trouble.

A good job description is essential if you are using headhunters. Although most of them will just send you whatever resumes are sitting in their in tray, a good agency will be able to adapt their search profile to your needs. This is particularly important if you are filling a specific team role; it is less important if you are hiring generic, quality programmers to join a rapidly expanding team. This is more common in ISVs where you are trying to ramp up the team as fast as possible. Enterprise developers are more likely to have a specific hole in the jigsaw that needs to be filled with exactly the right piece. Programmers have different motivations from managers. Knowing this is key to keeping your team happy and on the job, and the process starts here with the job description. Don't write it as if it were a job for you—make it an abstract, objective, ego-free statement of the work to be done and the skills required. You can check out with your team if the job description matches their expectations of their future colleague—remember how the pointy-haired boss is always hiring no-hopers without consulting Dilbert, Alice and Wally? Don't fall into the same trap!

If it sounds like building a good job description is a lot of work, you're right. But think how much more pain, cost and work it is to have to fire someone who isn't right for the job. And, in the spirit of reuse, the work involved is not lost when you hire a candidate. The job description should form the basis of his or her job plan for at least the first year of employment.

The First Cut: Arbitrariness Is a Necessary Evil
My experience of hiring has been that you're either crushed under an avalanche of resumes or you get none. Occasionally you luck out and have one or two clearly perfect candidates, but most of the time you are faced with a huge filtering task. On the other hand, if you don't receive any suitable applications you will have to rethink the job description, your advertising and recruiting efforts, and the search channels.

Filtering can be a long, slow process. That translates to expensive, so you want to limit the number of people doing it. I'd recommend that you get one person, probably yourself, to go through the whole set and create a short list. Don't circulate the whole set; you'll just waste everyone's time. A manager is there to ensure that the team is productive, and often the best way to do that is to do the thankless work. Save your team's strength for assessing the relevant candidates.

No mercy. Click here

When filtering I've developed a simple rule: any doubt and it's out. This applies at every stage of the hiring process, but particularly here. I read about one man who was faced with four hundred applicants for an unskilled labor position. In desperation he arbitrarily rejected all those who had written on blue paper. For techie jobs you might not go this far, but if you have a bad gut feeling about a candidate from the resume you're unlikely to change it at the interview stage. I personally can't tolerate resumes that are difficult to read or too heavy on presentation.

It's worth mentioning at this point that resumes and cover letters are confidential documents and should be treated with respect and care. Don't leave them lying around for all to see. And be particularly careful with submissions from people you know personally—if necessary pass the work to someone else. Even worse is receiving resumes from people who work for friends…and let's face it: this is likely to happen in our relatively small and heavily networked industry.

Eventually you will be left with a number of suitable-looking resumes in your file. Committing to an interview costs time and money for both parties, so consider some pre-interview checking. A telephone interview to screen geographically remote candidates can avoid travel costs. Ask to see their previous work or contact a former employer, as long as you remain discrete.

Minimize Interview Stress
Since interviewing is so expensive, you want to make sure you get it right. Interviewing can be deeply stressful for both sides of the table, so the less hassle before and after the event the better.

First, estimate how many interviews you think you'll need for each applicant. Personally I think two is the ideal number, with each one covering different areas. More than two suggests that there are doubts, and one is only acceptable if you have a really strong candidate.

Next you want to decide how many people will interview each candidate and in what size group. Interview panels are out, unless you want to reduce candidates to gibbering wrecks. Over the years I've found the best format is to interview in pairs, with a maximum of three pairs. You should include as many of the people who will be working with the new hire as possible: this is not a chance for you to flex your managerial muscle by making an important decision unilaterally. Imposing a new worker on the rest of the company, especially at senior levels, is a recipe for disaster. I saw one inadequately interviewed VP last just seven weeks before being shown the door. A very expensive error on all sides.

Pairing up interviewers is not a Mr. Nice and Ms. Nasty thing; it allows the interviewers to take turns at talking and observing. I find it interesting to see how the candidate reacts to my interviewing buddy's questions. Body language is almost impossible to assess if you are talking. You also get a chance to think up more questions, allowing for a more in-depth interview. You can also come to your buddy's rescue if they get stuck or if they need help. In one interview, a potential systems manager started to bully my buddy into saying whether or not he would get the job. I was able to terminate the interview there and then, which answered the question definitively for all of us.

Buddying up is also a great way to train people who have no experience of the other side of the interview table. They can sit in and learn, perhaps not contributing much at first, but they will soon develop a personal interview style.

Setting up the interview room or location is important for putting all involved at ease. Unless you are hiring in the early days of a startup, a simple meeting room with water and glasses is best, especially for the first interview. Try not to keep your candidate waiting, and if they must wait, make it somewhere as relaxing as possible. Being in someone's office on your own is bad, but being in a crowded open area with everyone staring at you is even worse. A customer reception area is perfectly neutral for waiting (if you have one). And never, ever hold an interview in an open area.

Read More on Hiring   Curiously enough, the majority of books on managing programmers steer well clear of the issues of hiring... Click here.

At a first interview you will want to start by introducing yourself and your role. This is a perfect icebreaker as it provides context and a means of starting conversation. After some social chitchat you should get down to the meat of checking if the candidate has the skills you need. Don't be afraid to ask to see examples of work or make people do some work on the spot. You can learn a lot from the way people approach problem solving, even on small examples worked out on the whiteboard. As DeMarco and Lister point out in Peopleware, a circus master would not hire a juggler without seeing him or her juggle.

And yes, you do find people who don't live up to their claims. During a series of graduate interviews I was asked by the previous pair to check up on one candidate's technical knowledge. A few questions about caching should have had him begging to leave. I remember him arguing forcefully about the fact he didn't know the word "bus," claiming it didn't matter that he didn't understand the fundamentals of computer architecture.

In such a case you have to remember that you are in charge, you are hiring, and you can't let the candidate walk all over you. Unfortunately too many techies have interviewed with "technically challenged" companies and found they could browbeat their way into good positions. That doesn't work with me; don't let it work for you.

Make Decisions Quickly and Informally
We developed a neat trick during a burst of rapid hiring called "the thumb test." All the interviewers would gather without sitting down and give a thumb up, down or sideways. Any downs and the candidate was out, all ups and they were through to the second interview, any sideways would be discussed, still standing. Unless the sideways people could be persuaded to change to a thumbs up, the candidate was not accepted.

The next step for someone who has passed this test is some homework. The person making the hire calls the candidate, invites them for a second interview and explains a task that must be performed before they come in. Graphic designers can show you a portfolio of prior work, but for most of us in software showing code from previous jobs is likely to be breaking contracts if not the law. Asking someone to code up some small application or algorithm will give a good indication of what they consider good practice, allowing you to match it to your standards. If you are hiring technical writers find a piece of incomprehensible manual and ask them to rewrite it in plain English.

Second interviews can be much less formal, perhaps taking place in your office if you are lucky enough to have one with a door and you can stop calls. Start such an interview by looking at the results of the homework, and going through their approach. You may not need to pair up for this stage, allowing for freer discussion. You'll probably want to go into much more detail about the proposed job as well, to give the candidate a clearer impression of whether they want to take up the job or not. I like to ask a lot of general questions as well to assess the person's general background and to assess their enthusiasm level.

When you're done, apply the thumb test again. If you're really lucky only one candidate remains and that person accepts. Deciding between several good candidates is difficult and should be done by only one or two people, typically the hiring manager and perhaps a specialist. Don't stress out your team by asking them to help make this decision.

"Compatibility" Isn't Just a Computer Term
Beyond the skill set, do you value a good personality fit? Communication and trust are essential for any new hire, so you must make sure that both will be possible. This is why I like to ask general questions, trying to find areas of common interest and distinctive behavior patterns. Hiring the wrong person can be disastrous for any organization, but so can hiring clones. You need to enrich your corporate gene pool by adding varied approaches, but at the same time avoid splitting into factions. Alternatives are fine as long as they sit well in the established framework.

Ten Ways to Put Off an Applicant
Being interviewed is difficult enough without having the interviewer wind the stress up to snapping point. Click here.

A good analogy comes from comparing rowing and football teams. In the former all the members work together in locked rhythm. Any one can take any other seat and oar—together they form a body corporate moving to the same beat. In a football team each person has a specialty and usually cannot be moved from one area of the field to another. Neither way of working is better—just different. Work out the kind of team you want to build and make sure you hire folks that fit the model.

Compatibility is essential when making that extremely difficult hire: the manager for an existing team. Unless the team is underperforming and needs a collective boot up the backside you will need the cooperation of all the team members. Try and include them in the interview process; after all, they will have to work with this person. Only if someone is being particularly unhelpful should team members be excluded from selecting a new boss. The whole objective is to ensure that new and existing staff work happily and effectively.