Monday, December 1, 2008

Technical Interview Questions

Have you ever taken a technical interview that went terribly? I just did, and it was horrible. I was asked questions I had no clue how to answer, questions that I barely knew or had limited exposure to and finally questions I knew but answered incorrectly because I was so nervous about the previous bad answers I had given. The worst part is I incorrectly answered questions that I have asked interviewees in the past. So instead of crying over spilled milk I decided to learn from this experience.

First, asking a bunch of random technical questions may seem like a good way to quiz a prospective employee, it really just strokes the questioner's ego and doesn't necessarily give you a true picture of what the candidate is capable of. Do you really care that a candidate has memorized the entire Java API and can tell you the method name, signature and optimal use for any random class, abstract or interface; or do you care more that a candidate can access and understand the JavaDoc API? Is it more important that a candidate can give a detailed treatise on the definition of polymorphism or do you care more that a candidate understands the concept and can put it into practice. Let me elaborate, I had a youth minister once who could spout off any verse in the Bible, he had nearly memorized the whole thing, but when you asked him the meaning of a verse and not the verbatim dictation he was at a total loss.

Second, if you must ask raw technical questions, take the time to order them from simple to complex. Once the candidate starts missing question after question you can reasonably gauge their skill level by the last question(s) answered correctly. Plus you might be able to cut an interview short for a candidate that doesn't meet a minimum requirement, therefore saving your day and not pressing salt into the candidate's wound. Don't bombard the candidate with a slew of random questions from subject to subject. It only shows the interviewers lack of time spent preparing for the interview, and it also gives insight into how the company may work. A scattered interviewer means a scattered brain means a scattered organization.

Third, understand that the candidate may be very nervous; they are after all interviewing for their livelihood, and will sometimes make obvious mistakes. Lead them to correct answers, don't try and trick them. An interviewer who would expressly set out to trip up a candidate is a worthless human scavenger. I'm not saying answer the question for the candidate but sometimes they need a little help to get the ball rolling.

If you are an arrogant, self aggrandizing prig, then nothing will stop you from thinking that the best hires are those that have memorized some abstruse features of Java (http://softarc.blogspot.com/2006/10/my-favorite-java-developer-interview.html). All I can say is, 'congratulations in hiring MENSA.' I personally want to work with talented people who are there to solve business problems not quibble over the esoteric technical aspects of Java.

No comments: