I recently interviewed with a number of companies for a number of positions. Some of these interviews were phone screens and some face-to-face. A few times I was asked some very specific “test” type questions which, as a good Java programmer, I should know. Sadly, more than a few times, I fumbled for an answer… Its frustrating to be asked a question that you know the answer to but fail response correctly. Its an even worse feeling to not know the answer at all (regardless of the fact that you have done it 1,000 times), but know you have the capability.
In one interview I was asked to describe the difference between an abstract class and a template in Java. On another occasion I was asked to describe the difference between and inner and outer join. I know the answer to each question, but I messed up during the interview, and I came across looking as if I didn’t know what I was talking about.
During another interview I was asked specifics about how and why I made decisions about system architecture, what technologies I chose and why I chose certain directions. I was asked what open source tools I used. This, to me, seemed like a much more appropriate series of questions. It gave the interviewer a chance to understand my thought process, and see that I have the ability to put concepts to practice. It didn’t put my on the spot, asking a pass or fail question (of which I may know the answer to, but flub).
I’m not saying good programmers shouldn’t be able to answer questions like those I listed above. In fact they should be able to. I’m suggesting, having sat on both sides of the interview table, that the latter approach provides a much better analysis of the candidate.
Kandice Rupert, Kandi Rupert, Kandi Kasper, Kandice Kasper