4 ms·
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
by raganwald 15y ago
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? ..."
- kstenerud 15y agoI disagree. Fizzbuzz is actually a different beast in that it exploits the generality that people who can't think coherently in complex architectures usually can't think coherently in simple architectures either. It's also why I love it when an interviewee has never heard of fizzbuzz before; it means that I'll get a 100% true test of their ability to think in basic algorithms (i.e. they aren't regurgitating something committed to short term memory just before the interview - although that's usually easy to spot anyway). Nano-questions, on the other hand, I don't see as useful at all. I spent 5 years writing enterprise Java applications, and I couldn't tell you what package List and File are in without looking them up. I've also been away from Java for a few years and have been using other languages, so I couldn't tell you for sure if the "inheritance" keyword is colon, parenthesis, "extends", "subclass", "specializes", or whatever. So in this case I'd get 0 out of 3, thus weeding out a proven, experienced, enterprise Java architect. Even if I had known the answers, I'd consider it a major red flag that such questions were even asked, as it would bring into question the interviewer's ability to think creatively (and no creative person wants an uncreative boss).
- mikeash 15y agoI'm not sure your jQuery question is quite of the same nature as the nano-questions mentioned in the article. Your example is actually fairly conceptual. Yes, it requires them to know the syntax, but asking them to explain the difference ends up being fairly high level. The examples in the article have no high-level component at all. I don't know what package File is in off the top of my head. I've never needed to commit it to memory, since the IDE will look it up, and if that doesn't work I can look it up myself. It's not useful information. Your question, on the other hand, is useful information.
- bermanoid 15y agoList vs Set is a funny question. I can’t imagine anyone with a degree being ignorant of the difference regardless of the programming language! That's not what he's complaining about, though, he said that question was perfectly fair game. Because it is something that, as a Java programmer, you actually need to know to do your job. Similarly, the difference between the jQuery selectors is relevant, because those things actually do different things. I'd argue that even your joke example, "What is protected inheritance in C++?" is still relevant, if esoteric, because it's knowledge that could potentially be relevant to how code works and what it does. You truly never need to know what package List or File is in, though, in the real world. If you're programming Java like 99% of the other people out there (i.e. you're not the type of masochist that thinks they can be productive in a boilerplate-heavy language like Java with nothing but a text editor), your IDE will fill in those blanks, and quite literally hide the import statements from you so you never need to think about them again (unless you mis-selected the class, in which case the fast solution is still not to remember the actual package name, but to delete the offending import statement and "Optimize imports" again, this time picking more carefully rather than mindlessly selecting the first one in the list...). That said, most Java experienced programmers would probably know that stuff like List is somewhere in java.util, and stuff like File is going to be in java.io, just from having auto-completed them so many times, so it could be a very weak filter against people that are lying about their experience. But I still don't think it's a useful question, at all - if they get it right, it very weakly confirms that they're not lying, and if they get it wrong it's nothing more than a minor eyebrow-raiser, suggesting that possibly they've exaggerated their familiarity (though again, any practicing Java programmer could be very good but still be weak at the "Name That Package!" game, because it's 100% irrelevant to the job). The thing is, you'd get far more information either way by just having them rant about Java in general, or asking them to talk about what pieces of the standard library they use the most, etc.