I'm an Engineer, Not a Compiler

Recently I had a phone interview where I got asked a variety of Java questions. This kind of thing is standard, and most of the questions were somewhat standard:

• What is polymorphism?
  
• What's the difference between a List and a Set? When would you use one over the other?
  
• When might you see deadlock?
  
• What is the difference between strong typing and weak typing?

These are mostly fair game. I dislike the polymorphism one, simply because it is so closely tied to most OO languages and inheritance that most people--when overriding or overloading a method, for instance--use it without ever thinking "oh! this is polymorphism in action!" Instead I might ask "what is inheritance and where do you use it," which generally has a keyword or pattern in OO languages. But this is a personal preference and I can see the argument.

The strong and weak typing one was a bit unusual, because he was actually referring to type checking rather than type strength and got a little confused when I described C as weak-static, Java as strong-static, and Python as strong-dynamic (I think JavaScript is weak-dynamic, but I didn't mention it).

What came next, however, were nano-questions:

• What package is List in?
  
• What package is File in?
  
• What keyword do you use to inherit with?

(We also got the "standard interview questions" such as "where do you see yourself in 5 years," etc.)

Russ Olsen mentions two consequences of asking nano-questions:

Aside from telling you not much at all, the tiny question has two real costs: first it takes up the time that you could be spending getting to know this person, finding out if they are smart enough, if they have the right background, if they will fit into your group. The second cost of this kind of question is that it tends to tick off those smart, well rounded people that you really do want to hire.

I got the nano questions listed here right, but let me throw on a third consequence: Asking nano-questions can lead to false negatives by weeding out otherwise great fits.

A good engineer thinks abstractly in terms of designing and building systems, they think in terms of algorithms, components, and engineering design. They do not necessarily know all of the details of syntax of a given language, especially if they are used to a good IDE which does it for them (I use Eclipse: I type List and then control-space to load java.util.List). It is more important that I recognize which package I want than that I be able to name it off the top of my head.

Similarly, it is more important that I be able to tell you when and where I should use inheritance, and when and where I should use polymorphism, than to be able to spit off the definition.

Basically: Any question that takes 5 seconds to answer with Google is not a good question. My favorite phone interview question? "What's your favorite language?" followed by "What are it's weaknesses?"

Yet a lot of interviews and a lot of exams basically test you to see how well you would substitute for a compiler. Even the Java Certification Exams tend to focus on questions of syntax and compilation as opposed to either how well you can actually program or how well you can design a system.

I am a good engineer, I am not a good compiler. I cannot look at a block of code and necessarily tell you that the problem with it is that it won't catch the  ClassNotFoundException, and a modern compiler will tell me that this is a problem. If not immediately, than at least when I attempt to compile. IDE dependency? Perhaps, but that isn't necessarily a bad thing since that is representative of the tools they will be using in the office.

In Short: Finding a good fit for your team is far too important to risk it with a game of Trivial Pursuit: Geek Edition.