I wear many hats on the projects I work on, from developer to mentor to pure consultant. One of my current clients is having me help make staffing decisions by performing technical interviews on potential candidates.

I've helped out with this kind of thing before, and I want to make some comments because I have noticed a lot of trends in technical interviews. I'll also have some comments on the interviewees, and how you can talk yourself out of a job over and over again. To put this all in context, let me just say in the past 10 years as an independent consultant, I have never had a day of bench time. Also, in the many, many interviews and initial meetings I have been to, I was only not given the project one time, and that was quite mutual by the end of the meeting. Some day, I will write about that particular experience, and in an unusual change of things, I am going to name names of the guilty to save others the same problem.

First, the concept of the technical interview. I have seen post after post of technical questions to help identify the level of technical experience a candidate has. It's amazing how specific those questions are. Why? They really don't need to be. From my experience, when someone is asking those excruciatingly detailed questions, it's more for the interviewer to feel superior than the interviewee (a warning sign for you job hunters) than to ascertain a knowledge level.

It's not practical or informative to ask deeply detailed technical questions. Why? Programming is like medicine in that it's highly specialized at times. I was asked some specific details about the DataAdapter one time, and I couldn't answer it. Does that make me a bad hire? Most people wouldn't think so, but I wrapped the functionality into a data access class, and I don't have to worry about the implementation ever again unless I need to do something specific.

As an interviewee, it's important to worry less about the answer to that type of question than to address how you'd solve the problem. In the DataAdapter above, I stressed I employed the OOP concept of encapsulation, and if I need to know a specific implementation, I grab Google or the MSDN and solve the problem. The key is this: if you don't know the answer, be truthful about it (and why), and how you would solve the problem.

You can really identify a programmer's level of expertise with simple questions. For example, I ask something like “What's the difference between an abstract class and an interface?” Not terribly tough, but you can tell from the detail of the answer a lot, both about their programming style as well as their level of knowledge.

I ask two sets of technical questions. The first are the the purely technical questions (about 10), and then seven or eight “philosophy” questions. I plainly state there are no right or wrong answers, but I just want to see what level of thought they place into their development. Here's an example:

Describe some exception handling you've implemented, and the advantages and disadvantages you encountered with that method.

Not too bad, right? But what does it tell us? It tells me how robust of an application this developer is capable of writing. From these interviews I have been participating in, I would say 80% of the candidates say “I just log to a file.” without any reason why or “try..catch”. All you need here is an answer and a conviction. But with the low quality of either portion, I know handling the problems in an application are not a real priority, which also tells me the developer does not code defensively. Things like validation and good user dialogs will likely be missed too. While these things may not be important in your organization or project, it may also mean they are not the most diligent programmers.

This ends the question section of this topic. In the next part, I will descibe how I watch a couple of top candidates snatch defeat out of the jaws of victory!