In my experience the process of finding the right candidate can be stressful. It appears that within the IT industry, the cases of failure are higher than the successes. In the absence of any standards the interview process is inconsistent and conducted using what can only be described as “IT Folklore”.

Part of the problem starts with most recruitment agencies. Agencies work in an almost mechanical way. Instead of filtering candidates intelligently they seem to filter using a dumb keyword or “buzzword” match approach.

Despite the agents, the more damaging part of the process is the interviewing itself. Technical abilities should in theory be easy to measure objectively. However in reality this is not the case as the current style of “testing” often produces inconsistent results.

The testing style that many companies use does not seem to be coherent. For some reason the focus and emphasis of many tests appear to obsessed around brain teasers and puzzles.

Although one could argue that a good surgeon is someone who has excellent “hand eye coordination” it is only one metric. It would be absurd to measure the competence of a surgeon by their video game playing skills.

When I was searching for a candidate I wanted to avoid the current style and so decided on a different approach. The first thing I did was decide what were the objectives I was trying to achieve from an interview. Personally I think an interview has two sides, the technical and the non-technical which are equally important.

The non-technical element for me was about getting a “feel” of the personality of an individual. While it is true a short period of time is not sufficient to get the full picture about someone, I think you can at least get a decent impression about them.

Regarding the technical side I boiled it down to three essential things I wanted to find out about the candidate:

What have they done?

What can they do?

Why do they do it that way?

In terms of the first objective I think asking them about their past jobs and experiences was enough to ascertain what they had done. It is hard to lie about technology you have never used because you simply will not know enough to give a thorough answer.

I derived the last two objectives by writing an exam paper. The “examination” was conducted on an offline laptop. The candidate was left alone (except for popping in at fixed times to check on progress). As for the questions on the paper I created four sections:

Section 1: Warm up questions: basic computer science questions.

Section 2: Open ended question: “How would solve?” type question.

Section 3: Programming question: Create function x.

Section 4: A set of SQL questions: write a SQL query to do x.

Once this was done picking the right candidate (for us) was simply about weighing the test score along with our impression of the personality. We found the process was painless and we believe it delivered the right candidate.

Conclusion

Programming interviews can be problematic. If it appears that you are constantly not finding the right candidate, you may want to consider looking at how you conduct your interviews. For myself this approach had the successful elements in finding the right candidate.

Until next Monday, “Live long and prosper”