February 13, 2008
Dubious Interview QuestionsSomebody sent me a link to a page on the corporate network that had some sample technical interview questions. I won't link to the page here, but suffice it to say that the questions are of dubious value (I contacted the owner of the page in question, and we're going to work to update it to have better questions).
Consider the first 3 questions on C++; obviously whoever wrote these had just spent some time reading the part of the manual that talks about structs, because the questions are: "What is the difference between class and a struct", "Why is a struct public", and "Can you inherit and have member functions in a struct". The correct answers are not, as you might suspect, "I don't know", "To confuse people who have figured out copy constructors", and "I'll say yes, because it sounds like a bad idea so C++ probably allows it" but actually have to do with the fact that a struct is public, to allow backwards compatibility with C. The problem with this type of questions in general is that they rely too much on knowing specific facts, rather than how willing and able people are to learn new things. And going beyond that, those specific questions deal with some arcana of the C++ language that few right-thinking developers would ever take advantage of. I mean, you have a struct which is like a public class, which is a dumb idea, and then you'll put member functions in it (so much for backwards C compatibility), which is even dumber, and then to top it off you'll subclass (or substruct, I guess) the whole thing? If somebody knew the answer to this question it might imply that they had actually written code like that...which might make me less likely to want to hire them, not more (then for extra measure, there are two other questions about dynamic casts and unions...it's like a police lineup of bad C++ techniques).
Most of the rest of the questions are like that; they ask about a single fact, many of which are esoteric--except for the ones that are trivial. For VB, the first question is "What is a method" (trivial) and the next one is "What are the four states a Form can have in Visual Basic?" (esoteric). For Java you have a question on what an interface is (trivial) and then one about .java files with multiple classes definitions (esoteric). Then there is this classic about SQL: "What is the difference between locking and deadlocking?" That last question reminds me of a quote from Jack Vance: "[he] was a man beyond her understanding; whether he were vastly more subtle than she or vastly more elemental, she would never know."
The problem with questions like that, especially the esoteric ones, is that getting them right or wrong doesn't mean much. A great potential hire might not happen to know much about VB forms; a "no-hire" might by happenstance have recently tried to create a .java file with multiple public classes in it. When I talk to people about interview questions, I always encourage them to pick questions that give the candidate an opportunity to think, not just spit out facts. For example, most of the sample questions on that page could be improved by giving the candidate the answer and then asking them to talk about why they think it works that way. And requiring thinking on their feet is one reason that coding questions work well; it's not whether they write great code, it's whether they think about it first, how they decide if it is correct, how they discuss possible improvements...that's what you need a good interview question to show you.
Posted by AdamBa at February 13, 2008 09:45 PM
TrackBack URL for this entry:
Argh, I accidentally deleted a comment by Andrew:
"Not everybody is an external thinker. Some people find it hard to think aloud, they produce far superior answers if given time to process internally first. Asking these people to tell you what they are doing while they are fighting with code on a whiteboard is not going to give you an optimal view of their capabilities.
The argument for asking trivia questions is that somebody who is passionate about a particular language will likely have poked around the edges out of interest. And just because you know about a language feature doesn't mean you use it (I know about C trigraphs but I've never written code with one in it).
Conversely not many people write binary search trees or linked lists from scratch either but they continue to be interview favorites because they give an insight into the depth and breadth of a candidate.
External thinkers tend to dismiss trivia questions as being unrevealing whereas internal thinkers tend to dismiss "think out loud" questions for the same reason. The art of interviewing is figuring out an optimal balance for each candidate. In my too many interviewers rely on stock questions rather than approaching each interview as a conversation."
Posted by: Adam Barr at February 21, 2008 05:48 PM