What does you Recruitment Process say about you?
Having recently moved jobs, I have been generally unimpressed with the recruitment processes I have encountered. My particular bug-bear is the "technical assessment" questions and my second favorite "the personality profile".
From an eXtreme point of view I fully support the "test first" approach but as ever you must be careful what you are testing for. A lot of the technical tests take a long time and are extremely detailed and demand deep knowledge of the syntax and foibles of particular systems. But is that what you want to know about a candidate? Especially if they are going to be working as a consultant ? This is testing knowledge not application, and it is application which counts. I suppose an analogy is technical tests are like coverage tests, not functional tests: and to the eXtreme mind functional rule!
The "personality profile" supposedly addresses these short comings but again I fear they are testing the wrong thing. These are analogous to architectural reviews of a system -they inform you about the general shape of things, how you believe things hang together and you decide whether you believe its fit-for-purpose. But at no time is there any kind of measure (and I use that accurately, i.e. not a metric) of fit-for-purpose.
So what do I believe is the right way of doing this interview process? What do I see as the recruitment equivalent of functional testing?
Well as a test I might write it as, "I want a candidate who can understand a users needs, use development tools, discuss implementations, do test first, etc. so that they can deliver working systems in the context of our usual working environment".
And how do you implement this test? Pair Programming.
We used this technique very effectively for years at Connextra. The interview process goes like this:
- Sift through CVs for reasonable candidates (I should blog on how to advertise too...)
- Brief telephone interview to test whether they are genuine and have the basic skills necessary for the role. This could include a basic technical and syntax test, but should be brief and take no more than 10 minutes and able to be asked by anyone (i.e. not necessarily requiring technical knowledge)
- If they pass that (and its amazing how many don't) invite them in for a Pair Programming session of about 30-60 minutes. If they freak and say no then you probably didn't really want them anyhow (never had this happen BTW)
- If they pass the Pair Programming, then get into the company fit and position discussions, which is probably only 2 or 3 more phone calls or interviews
I recommend the 30-60 minute timing so you can get 2 people to do 30 minutes each with a candidate. The second one tries to understand what happened in the first 30 minutes through the candidate reiterating and demonstrating. This also helps avoid the single chooser problem.
There is an anxiety about Pair Programming in the interview process about it being a waste of resource. I would argue that it is in fact a valuable investment for two reasons. Firstly, it is the only truly effective way of testing if a candidate is entirely suitable for what you wish them to do. By testing the right thing early it reduces the costs of fixing mistakes later - which might include your company's reputation! Secondly, it involves your current employees directly in helping to choose their future colleagues - which can in itself be a motivational exercise.
Also, remember the interviews are a two-way street, and your company will be judged on the process of interview. In fact it is the only true measure a candidate gets of you. Think: What does your recruitment process say to the candidates?