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.
On any other day, if the choice of eclipse or equivalents(IntelliJ etc) is not available it practically makes zero sense to deal with monstrosity and needless complexity Java has with a ordinary text editor. Even if that is Emacs. Emacs is still a text editor.
On any given day Java development makes sense only if done on a IDE. And that's nearly every Java programmer works. Exceptions exist, but they only prove the rule.
Having said all that, These days eclipse really does 90% of the coding. You job is only to tell eclipse what needs to be auto completed.
Emacs has working autocomplete from Java, especially with Semantic. It's far away from being as smart as something like IntelliJ, but it works well enough. Most functions and arguments you remember after a while. I can type much faster than I can think, so less autocomplete doesn't slow down. In fact, not having to watch if the autocomplete gets it right frees the brain to think ahead more. Maybe it's because I'm used to this.
Import statements are one of those things where you have to switch to Google, though.
I am now planning to shift to ST2.
Even on an editor like ST2 which is awesome anyway. You get to see what an editor is designed for. Its supposed to make 'Text' manipulation easy. So that is what it is, after everything.
So Emacs with all its power is still a Text editor, albeit a very powerful one.
Every time I work on Text editor I focus on reading manuals and understanding stuff no matter which editor that is. But with Java,IntelliJ and Eclipse its different, I just throw in whatever little is there on my mind and just wait for the autocomplete to do the magic.
Some of my colleagues go a step far. They just can't write any Java code without an IDE and I see that's the case with nearly every Java programmer I've met so far! Even in interviews. Its sort of like if you are talking of Java development its taken for granted that its is happening on an IDE. You never know, a few days from now the Java language specification my include a IDE specification.
According to me tools and languages must enable you think more than you write. Unfortunately in case of Java(and now growingly Python) you just can't work without an IDE.
Yes, this is often a good use case for avoiding tools like Eclipse (IntelliJ is somewhat better), sometimes the multi-language pain is just too great. Especially if you already have to set up a complicated build by hand and interact with several other systems, the IDE can no longer gain you very much.
For pure Java, though...I don't know. I use Emacs all the time for other stuff, but I just feel so naked when coding Java within it (I've tried a few times, but always end up going back), maybe I'm just too used to all the help I get from IntelliJ...
I have experience working in good IDEs. For many years I did .NET development, and Visual Studio is very, very good.
However, over time I realized that even with all their awesome features, powerful IDEs were a net-loss to my productivity. They work best from a single machine and that made me a lot less likely to work remotely (I have done my best work in the middle of the night, from home). Their less responsive UIs made it easier for me to get distracted. Their slow startup times exacerbated my natural proclivity to procrastinate.
I realized: My working memory is fine for most projects, and emacs' text-based autocomplete fills in the rest.
All I'm saying is: don't assume that the way you work, the tools you prefer, or the tradeoffs you make are universal. There are a lot of programmers out there, and a whole lot of tools.
(If you really care, I have an interview about my setup here: http://aaron.boodman.usesthis.com/)
I just think that it's a good sign that you can tolerate a lot of pain. :)
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).
For example, you could ask how to switch two variable's values in C++ with the aim of finding out whether they know about the swap function (and you can then go on to ask about template specialization for extra credit).
This would be a better question than the ones in the OP because it's not just trivia and it's not something that your IDE will do for you.
Many people will claim to know a programming language on their CV because they spent a week trying it out 3 years ago, figuring that they can just pick it up quickly if they get the job (this might be somewhat true for the 5th or 6th language, but probably not for the 2nd). And these are the same people who will then program in that language for years without ever producing any quality code because they don't realize that there is room for improvement after you know all the keywords.
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.
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? ..."