Recruiting is a complex process, and recruiting developers even more so. In this post, I will focus solely on the interviewing part (and leave the rant about recruiters who are paid 1 year of the candidate’s salary to just match buzzwords for another time).
I recently stumbled upon an article about interview questions, again, telling you about "right" answers for such and such questions. There are plenty of such articles on the World Wide Web, full-fledged sites dedicated to this topic and a couple of books too. A few of them are "free", the others paying. But let’s be straightforward: I believe it to be complete and utter crap. Now that it’s said, let me develop.
First, a little explanation about my experience in such matters is in order. I’ve been working around 15 years in the software industry as a consultant, so that I’ve been interviewed a lot by employers and customers alike. Also, I’ve been on the other side - technical recruiting, either alone or as a part of a recruiting task force.
Here are some examples of the situations I’ve experienced as an candidate in no particular order:
- The lightweight interview:
- "Do you know this?"
- "Yes"
- "And that?"
- "No, but I can learn"
- Multiple-choice questions on a very specific subject (EJB). Interestingly, albeit passed with not a bad score (28/30 if I remember well), I was not chosen
- Multiple-choice questionnaire. Then, on some questions, I asked about the context because different answers could apply but the person who made me pass the test couldn’t answer.
- Multiple-choice questionnaire again. But a question was incorrect and I told the recruiter about it. In the end, I was recruited… then my first task as a new employee was to browse through all questions to find other potential errors.
IMHO, there’s a 0 - let me emphasize that, zero correlation between the ability to answer correctly on a multiple-choice questions kind of test and the ability to be an effective programmer. As additional evidence, as a teacher, I also used this kind of test as an exam once and that was an great disappointment, good students failing miserably. May I also mention a certified Java X programmer - certification is based on this kind of test, not being able to explain the overall architecture of his latest project?
At least, the chit-chat kind of interview doesn’t over-promise. It’s generally friendly and based on human interactions. The key here is for the candidate to be as truthful as possible. I always tried to do that, and it worked every time. Why would I tell something which is not true? Otherwise, at some point in the future, I would be exposed as a fraud. I’d have lost time as well as my employer, and my reputation would be tarnished. However, some people don’t think likewise so interviewers have to take precautions.
In the end, the only interview method that does work is to put the candidate in the exact same situation he would be during regular work: in front of a computer and to make him solve a problem. Sure, it’s still miles away from a real situation but it’s hard to get closer. There a lot of such code-related problems available out there, but you should cook your own. As above, you don’t want candidates to rehearse for a specific problem but to show you what they can.
And yet, despite everything, some recruiters - if not most, still prefer to go the multiple-choice questions road. And candidates read and sometimes are willing to pay to rehearse for such kind of interviews. Why is that, then? Well, my guess is that because most people still don’t understand software development, don’t know how candidates can be evaluated and thus go the only way they know. As I understand, at least Americans have a bias toward tests because they’ve been used to them in public schools (please correct me if I’m wrong); Europeans have no such excuses.
However, this is not limited to recruiting. It seems managers at all levels prefer wrong information to no information at all. Hell, it’s even worse because most of them know it’s wrong, but they are happy to pass it to the upper echelon nonetheless - that’s their job. Come to think of it, this behavior is very widespread. Take time-sheeting for example: people cannot be totally precise, so let’s assume 5% uncertainty. Readers with scientific background know that uncertainties add. So, a company with 20 persons has 100% uncertainty on their time-sheets. Another golden example for preferring wrong information to no information is project planning. Everybody know that in most cases, it’s a lot of bullshit, but yeah, everyone goes along with the flow.
Recruiting, planning, timesheeting… Sad state, isn’t it?