I’m going to take the incredibly unpopular stance that nano-questions are not considered harmful. It’s true that only asking nano-questions, or emphasizing them, or thinking that a good engineer must necessarily be able to answer all of the nano-questions perfectly are all broken ways of thinking.

But I look upon them as a kind of FizzBuzz. I know for a fact that while you can look them up in Google in 500 nanoseconds, experienced people doing hands-on work are going to be able to answer 2/3 nano-questions instantly. A few such questions sprinkled in the opening part of the interview are useful for weeding out the AbstractArchitectureAstronautFactoryFactories from the Programmers.

I’m not talking about esoterica, e.g. “What is protected inheritance in C++?” Lots of practitioners might say, correctly, that they never use it and can easily look it up if you need to know how it works. And sometimes answering esoterica correctly has negative correlation: You end up hiring people who are SmartButTooBusyPlayingWithCoolIdeasToGetStuffDone (I’m a prize example of this). But if a programmer says he’s working with jQuery and I ask him to explain the difference between $(‘.foo.bar’), $(‘.foo,.bar’) and $(‘.foo .bar’), I don’t want to hear from him that he can look it up on the Internet, a jQuery programmer knows the answer.

It’s acceptable for someone to say, “I don’t know jQuery, but I’m a smart guy, I can figure it out on the job by looking stuff up,” but if he says he’s been using it to build awesome HTML5 applications, I want to ask a few of these questions to make sure that I’m interviewing the person described on the resumé. A working programmer will know the answer to all of them, they shouldn’t be hard. Interview pressure will cause some fuzz, so I don’t expect perfect, maybe get 2/3 or 3/5 right and then we can talk about composition vs. inheritance or whatever other pet “Start a conversation with a smart person” question.

I want to be incredibly clear about this: I don’t think that there is some strong correlation between memorizing things and being a good programmer. I don’t think programmers should rush out and memorize trivia just to “pass” an interview. I look stuff up all the time in my job. But I do think that if the questions are easy and obvious to the working programmer, a few of them are an appropriate FizzBuzz for weeding out the folks who have falsified their hands-on experience.

By and large, interview questions are a touchy subject because they serve as a kind of metric for valuing people. So when I say I think it’s cool to ask a few of these questions, some folks are going to think that I say that I measure their worth by whether they know a handful of bits of information. That’s not the case. I’m not saying you’re unworthy if you don’t memorize things. But I am saying that if you claim to have a certain type of experience, there are some questions that are going to be dead easy for you to answer, and those questions are going to help us get to the good part of the interview very quickly.

p.s. List vs Set is a funny question. I can’t imagine anyone with a degree being ignorant of the difference regardless of the programming language! It’s also a good lead-in to a more experiential question: “Okay, can you describe a time you’ve used a set of some kind? What were you trying to accomplish? ..."