Of interviews, and interviewers Part 2: Who will interview the interviewers?"I can see what the candidate has done in the past from looking at their CV. What I really want to know is what they are capable of doing in the future." The above quote is from a CTO in a discussion I had with him on interviewing techniques, after I started working for him. I think it goes straight to the nub of the problem. Given the rapid change in technologies in the IT business, past 'performance' is not always a sure guide to future ability. It seems to me that when it comes to job interviews we can identify the following elements that need to be considered by the interviewers: 1. What do we want out of the interview? 2. Who is going to do the interview? 3. Advance preparation. What are we going to talk about with the candidate that will elicit the information identified in item 1? 4. Environment: Is the interview going to be carried out in a working environment? If not, what is the justification for the environment chosen? Interviewees need to consider their normal working practices, and how they are going to translate those practices into something convincing in an interview environment. We'll start with a look at the interviewing side of a job. The first question is what do we want out of the interview? The answer is obvious. Somebody to do the job. Unfortunately, that's where most people leave it, perhaps with a wave of the job advert, which is usually a boiler-plate shopping list lifted from someone else's advert. If you don't have a worked out, and focussed, view of what the job involves, how you expect it to evolve, and what skills are going to be needed both now and in the future, then your chances of finding someone suitable are less than if you had made a random pick. The next question - who is going to be doing the interviewing - is not really very often considered. Usually people are just drafted in to make up the panel, and left to get on with it. Think about it though. Why are people from a profession notorious for its lack of social skills allowed to carry out recruitment interviews? Their decisions may well have a serious impact on the future of the business. And why is no-one ever given any training on how to carry out an interview? OK - so we have assembled a (usually very homogenous) group of people who are going to do the interview. Now comes the question of what to ask. This is a thorny issue indeed. Are you looking for a specialist or for a generalist? The questions will be completely different. How does your shop work - what sort of questions will get you that sort of information? Of course, you don't actually have to ask questions at all. Some of the most effective interviews I've been to had no questions per se, they were a series of discussions based on my CV. The discussions covered the work I'd done, how and why I made the decisions I did, and how I would use that experience to solve related problems in other situations. In general, there seem to be two ways to carry out an interview. Either you can opt to find out what the candidate doesn't know, or you can try to find out what they do know. Given the huge scope of C++, and the varied working practices, the chances of anyone, even Bjarne, knowing everything are close to zero. Obviously you need to know in general terms in what areas the candidate has gaps in their experience. Having found a gap, all you really want to know is whether the candidate has made any attempt to fill in the gap by reading, discussion with co-workers, etc. That said, there is little point in pursuing the details in this situation - it just ends up making the candidate miserable and hesitant in answering questions about the things they do understand. If you do find that the candidate has a gap in their knowledge in an area that you would have expected them to know, then the most important thing is to find out why. They may, of course, have been lying on their CV, but that isn't always the case. It may well be that there are perfectly good reasons why there is a gap. Perhaps, for instance, the way they design programs is such that they have never needed that feature of the language. I once went to an interview for a Qt programmer in which one of the interviewers was totally focussed on the qmake tool (used to produce intermediate files when using Qt libraries). I've never used the tool, though I've been using Qt for several years. I use Qt's Visual Studio plug-in which handles everything via VS's solution/project system. By the end of the interview I was starting to get really fed up with the mantra, "Let's go back to qmake". He spent so much time 'proving' that I didn't know much about qmake (something I explained right at the start), that he never did find out what I knew about Qt programming. And finally, what about the interview environment... Let me start by asking a question. Would you expect someone to take the practical driving test by explaining, using a whiteboard, how they would cope with different situations? Details to include what they are doing with their hands, feet, eyes and ears... Of course you wouldn't. But we do expect people to solve programming problems without a computer in an interview. Have you ever tried to drive while thinking what your feet are doing? That's very similar to the problems you pose when you ask a syntax question sitting across a table in an interview. The candidate has probably typed it into the computer thousands of times, automatically, and doesn't even think about it any more. It's the computing equivalent of changing gear in a manual car! Be careful what you ask for, you might just get it. You could easily end up with someone who can do exactly what you want at this moment in time, but is incapable of moving on to the things you want to do next year. Probably the most difficult thing to find out is whether a candidate is able to learn and move forward. Many years ago I went for a job as a London bus driver. The 'interview' consisted of driving a double decker bus round London in the rush hour! It went something like this: the instructor drove the bus for 10-15 minutes and gave me a running commentary on what he was doing. We then swapped over and I drove for 15 minutes (I'd never driven a bus before, it was terrifying). We pulled into the side of the road, and the instructor went through what I'd done wrong (mostly not taking corners wide enough and bumping over the pavement) and what was the best way to correct the problems. Then I got back in the hot seat and drove around for another 20 minutes. It was that last 20 minutes that was the test. I was being watched to see how well I corrected the errors. The instructor already knew I could drive, because I had a license. What he wanted to know was, could I be taught to drive a bus. Fortunately for the programming world, although I passed that test, my eyesight wasn't up to their stringent standards, and I was turned down (this was in the days before operations were outsourced to a bunch of cowboys). So I had to resort to the much less glamorous profession of programming instead! I don't know what the equivalent of that test is for programming, I wish I did, it would make life much easier, both for the interviewers and the interviewees. There was an extended discussion on interviews on the accu-general mailing list recently which is worth reading and presents differing views on the topic. I'd recommend a read of it should you end up having to act as an interviewer (search the archives for the subject 'Torturing interviewees' - yes, really). Next I'll take a look at this problem from the interviewee's point of view, but in the mean time I'll leave you with the Cheshire Cat's take on things: `Would you tell me, please, which way I ought to go from here?' |
If you have any questions or comments about the articles on my web site, click here to send me email. |