I’ve recently been hiring at Barcap and the in doing so have been reflecting on the various merits of structuring the process (these are enumerated in full in my article Technical Interview Process).

Be decisive:

If a candidate is good then take him forward (if you have several rounds). If he is not then reject the candidate. If you are not sure then reject the candidate. A bad hire will cost much time and money so if in any doubt, do not hire.

Be aware of preconceptions:

It is easy to form a prejudice before you enter the interview. These can be formed from the candidates CV, from talking to a recruiter or a colleague that has interviewed the candidate. It is hard to turn such preconceptions around in a one hour interview it is best to avoid them in the first place if you can. If you do think they may be forming try to be as neutral as possible in the interview. Trust your instincts and find out for yourself.

Objective measures only tell you so much:

Using the tools suggested here to find out if a candidate is technically able is only a small part of the story. Your task as interviewer evaluate whether the guy will fit in. Again trust your instincts and if in doubt just say NO.

Overall:

You are looking for bright people that get things done.

These are by far the two most important attributes.

Putting formality into the filtering process injects a level of objectivity into something that is otherwise often just left to a ‘feeling’ as to whether the candidate was up  to scratch. In addition it allows broadening of the areas over which candidates are measured as well as making the process more scalable (as candidates taking tests has a smaller time constraint on the interviewer than direct contact). This means that more CV’s can be processed which is beneficial when CV’s provide a fairly arbitrary indicator to the worth of a candidate.

However an increasingly structured and rigorous process does by no means equate to the hire of consistently able candidates. This is simply because these processes can never really indicate whether the applicant will actually be any good when they sit down at the desk and start coding. They just provide additional ‘yard sticks’ with which to measure and evaluate abilities that are supposed to be associated with capable people.

Time spent preparing and executing the selection process is time well spent when you consider the overhead of training someone only to sack them after six months. However it is important to not loose sight of the fact that, as with any process, you can take it too far.

In summary, you need an effective interview process both to find and attract good people, but there is no point going overboard with this process as there is a limit to what any process can really tell you. It’s up to you to judge that you are covering enough in the process to remove the chaff without wasting too much time in the process.

The good backup method, and one we usually use, is to only take on contract staff initially and convert them over if they are good. Whilst this is a expensive process initially it can be beneficial if you do get a ‘dud’ candidate (and there are a lot of them about).

If you are interested in this topic generally, Scott Berkun's essay (whilst not totally in agreement with mine) makes a good read: How to interview and hire people and Joel is excellent as ever: Joel on Software