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 one 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” while others require payment. Bu,t let’s be straightforward: I believe it to be complete and utter crap. Now that it’s said, let me explain.
First, a little explanation about my experience in such matters is in order. I’ve been working for around 15 years in the software industry as a consultant, so 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 a 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, although I passed with a good 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 take 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 hired… then my first task as a new employee was to browse through all questions to find other potential errors.
In my humble opinion, there’s a 0—let me emphasize that—zero correlation between the ability to answer multiple-choice questions on a 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 a 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 overpromise. 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 say 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 similarly 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 in 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 are a lot of code-related problems available out there, but you should cook your own. You don’t want candidates to rehearse for a specific problem, but rather to show you what they can do it on their own.
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 interviews. Why is that? Well, my guess is that because most people still don’t understand software development and don’t know how candidates can be evaluated, they go the only way they know. As I understand it, 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 backgrounds know that uncertainties add up. So, a company with 20 persons will have 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 bullsh*t, but yeah, everyone goes along with the flow.
Recruiting, planning, timesheeting… sad state, isn’t it?