Telephone interviews take place if a recruiter wishes to reduce the number of prospective candidates before deciding on a shortlist for face-to-face interviews. They also take place if a job applicant is a significant distance away from the premises of the hiring company, such as abroad or in another state or province.For me, the point is to save time. I've had candidates who looked good on paper drive over 2 hours for an interview only to discover they're seriously lacking. For me the phone interview saves their and my time by quickly weeding out Programmers who can't Program. I wrote this post for managers thinking of implementing phone interviews or interested in ways to improve their phone interviews.
My aim is to be able to get through the phone interview in 30 mins and it could probably be shortened further to be honest. 30 mins is doable for a candidate on a lunch break or just before/after work if need be and isn't a big impact on my day.
I start by introducing myself and giving a little of my and the company as well as introducing the role we're hiring for. I let them know the phone interview isn't meant to take longer than 30 minutes and that there will be plenty of time for questions in any face to face interview, but that I'm happy to answer any questions they have. I say that we don't expect everyone to answer all the questions and not to worry if they're unsure of some of the answers. The point of this is to try and put them at ease. Phone interviews can be more stressful for candidates because of the lack of in person interaction and the short time limit, especially if things start going wrong. I generally do what I can during the interview to keep them moving on from questions they're stuck on.
We have a standard set of questions every candidate gets, written down on one side of A4. We start with a few basic questions about the languages we use, "Where can you apply the final keyword and what does it mean in each situation?", "What's the difference between an interface and an abstract class?" etc. There's also some more esoteric ones which it doesn't matter if more junior developers miss but it's always a nice sign when more experienced developers get them. This just checks that they do know the language they've got on their cv and that they know how to do more than the absolute minimum with the language features available. One problem with these questions is that anyone who's got a certification in the language can easily walk the questions, this is not an indicator of their being a good programmer.
Next is the real check, we get them to implement FizzBuzz for us over the phone.
FizzBuzz: Write a program in pseudocode or any other language (with the probable exception of Brainfuck) which iterates over the integers from 1 to 100 inclusive outputting either the number, the word Fizz (for multiples of 3), the word Buzz (for multiples of 5) or the word FizzBuzz for multiples of both 3 and 5.This is almost embarrassing to ask someone to do but it's surprising how many 'programmers' can't do this simple task. It's surprising that any can't do it to be honest, let alone enough to make it worth while as a question in an interview, but it is. This chap has an alternative to FizzBuzz and I'm sure there are others but to date I've not met someone who was familiar with FizzBuzz outside its use as a drinking game. By the way, I don't actually make reference to Brainfuck in the interview.
Finally there are a couple of more computer sciencey questions, specifically I ask if they're familiar with design patterns and if they can describe how to implement one for me. If they struggle or select a pattern or are finding hard to describe their chosen one over the phone, suggesting they describe how to implement a singleton usually seems fair. Some prompting is fine, I believe if they understand what a singleton is but never knew the name for it that's still ok. Lastly I ask if they can describe what a linked list is and how they would implement one, again any language or pseudocode is fine. These last two can be tricky for some people, familiarity with design patterns is important for me even if they're knowledge isn't comprehensive they should be able to describe at least one and implement a singleton or another pattern of their choosing. Knowing what a linked list is beyond new LinkedList() shows some appreciation of what happens beneath the code they write, this is similar to the final keyword question at the start. Failure on the linked list question isn't a major issue and if we like them we'll likely talk through linked lists in the face to face interview, but that's for another day.
The above is what I currently do, I'm sure it could be improved and if your situation differs significantly from mine some of the above may well not work for you. I've found these phone interviews a great predictor of success or failure in a full interview. I do think that 30 minute phone interviews as a pre screen for potential hires are extremely useful and if you're not currently doing them you should give them a try. For another take on phone interviews, or if you've landed one at google check this post out http://allenc.com/2011/04/how-to-score-a-google-onsite-interview/
If you're interested in hiring great developers please take a look at JobsTractor.com, you can sign up for the beta right now, or drop me a line if you've got any questions.
No comments:
Post a Comment