If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!

I thought I would write up my thoughts on recruitment, and specifically recruitment of programmers. The reason for this is that I am going through a recruitment cycle at the moment. My new company is a startup and it has made me re-evaluate how I recruit.

In the past
Many years ago when I worked for Argonaut Software I did a large amount of the programmer recruitment. In fact over the course of two years I recruited in the region of 75 extra staff (from thousands of candidates). I had not previously done any interviewing and was lucky enough to have a management consultant who had a wonderful range of interviewing tips that set me in good stead.

Part 1 - The interview
The following set of stages are for complete interviewing novices. If you have done it all before, just skip further down until you find something relevant.

Stage 1

Sit in on 5-10 interviews in the understanding that you are not required to ask any questions unless you happen to think of something. This will give you time to understand the process and feel comfortable in the interviewing environment.

Stage 2

The next stage is for you to start taking more active part in the interview. This must be alongside a experienced interviewer (remember these interviewees are still coming in for a job!). A good way to start is by using a cheat sheet. I do not like pre-defined questions but they do help when your starting out. The reason I dislike them is because a good interview will evolve as it goes along and a pre-defined question is more likely not to fit the flow of the interview.

Stage 3

The next step is to become the lead interviewer. But let’s not jump ahead of ourselves, you should still interview with someone else supporting you. The reason for this is If you suddenly run out of inspiration its always helpful to have a second person. Each interviewer can be thinking of what to ask next while the other is still talking. If you are by yourself and the interviewee is answering with short answers you may quickly feel under pressure of what to ask next.

Stage 4

Knowing when to shut up. In all things business knowing when to not say anything further is very important. It is very easy to fall into the trap of feeling that you must immediately follow up any answer with the next question. By not answering immediately you leave yourself more time to think.

More importantly if you think back to when you have been interviewed yourself and any instances where you have been left hanging, you involentarily think you should continue to answer. Learning to leave pauses is not easy. It’s not polite (in my opinion) to leave pauses so we find it hard to do. Again this technique is easier to learn when you are interviewing in pairs.

Tips on leaving pauses:
1. Don’t do it all the time. It will just seem rude (or weird) if you constantly wait to reply.
2. Pick your moment. Have they just given you an answer that you disagree with? Well, wait 4-5 seconds and see if they follow it up.

At the same time as learning this, you should also be weaning yourself off using a cheat sheet. To do this start replacing your pre-defined questions with just notes of types of questions to ask instead. This still gives you a fall back guide but it also hopefully means you are starting to adapt as you go.

Stage 5

The final stage is all about the questions to ask. In my opinion it is rarely a good idea to ask direct programming questions unless you have led your candidate onto a subject which they show along the way to have knowledge. The reason for this is that programming is a massive subject and you could ask someone a 100 questions and still not have an idea if they are good or not.

The art of good programming interviewing is to start out with very broad subjects then slowly move your candidate towards more and more detail. If you find them deliberating veering away from certain subjects it’s almost certainly a sign they are not strong in that area.

Conversely if they start talking at length on a subject it’s a good sign, but do make sure that you move them away from that subject once you feel confident, you don’t want them to spend the whole interview just concentrating on one subject.

In some instances you could be interviewing for a very particular requirement in which they must know the answer to a range of direct questions. I’d always prefer to find a great candidate that didn’t know the subject I need, rather than an average candidate that did.

The last point I will make on questions is probably one of the hardest and that is to not ask questions that can be answered with a yes or no. If you do then you have just wasted your time, all you have done is found that they agree or disagree with you.

Further Tips

• It is very important to relax certain kinds of candidates. The reason for this is that I have found many geniuses that are totally incapable in an interview, the only way to find them is to engage them on a subject that they feel comfortable and in doing so getting them to relax.
• If your interviewee is very confident then the opposite may be required. You may need to put them under pressure to see how they behave when they are out of their comfort zone. Remember most people are already under a lot of pressure in an interview environment so judging this is important.
• Do not attempt to bluff your way through a subject. If the conversation moves into an area that you are not 100% confident within then immediately steer it away. If you don’t know what your candidate is talking about then you are not learning anything.

In part 2 I will cover what programming tests you should get your candidates to do before, during and after the interview.