4 ms·

I disagree with some parts of the post. I think good engineers have to be able to work effectively at a high "system" level of abstraction as well as at a low "

I disagree with some parts of the post. I think good engineers have to be able to work effectively at a high "system" level of abstraction as well as at a low "compilation" level of abstraction. If you can't look at a chunk of code and know enough about the language to know that it could throw a ClassCastException, then it is quite likely that you will fall prey to other language gotchas which can bubble up and destroy the entire design of the system you're trying to build. I don't think the current state of the art in software development has yet advanced to the point where we can just black-box away all of the entire "compilation" stuff such that it never affects the "system" stuff. I really would like that to be the case, because it would eliminate a lot of unnecessary complexity in software development. I think asking a limited number of compiler-level questions (less than 5) in an interview doesn't take up a lot of time, and can allow you to get an idea of how much actual experience the candidate has with the language as well as dealing with nitty-gritty problems that come up while you're coding. The value and time spent are both small, so the value/time ratio is probably in the same ballpark as any other question you might ask.

ajuc 15y ago
I don't know. I remember problems with different classloaders, old versions of classes being deserialized, different versions of classes being sent over RMI, etc. Some of these probably resulted in ClassCastException. Some had thrown more specific Exceptions, am I supposed to remember the exact Exception that was thrown in each case? I'll probably know if you show me stacktrace. But I only know because I've encountered such problems. People working on the other end of our system would recognize different set of problems that results in this Exception or similiar. Nano questions are bad, because you are really asking if candidate has had the exact same experience that you had. Some did, some didn't, it doesn't matter. Anybody will solve the problem within minutes, most probably googling the most promising lines of the stacktrace, and ctrl+clicking around in Eclipse (or grepping the source tree, whatever). Even auto-importing packages in IDE can cause problems - sometimes it imports from the wrong package. Is it enough reason to ask questions about "which package contains Hibernate Session class?" or even "which package contains ArrayList class?". I don't think so. Being aware of the problems good abstractions can cause (there's always a few problems) is IMHO enough, no need to remember everything you can google in 5 seconds. EDIT: or maybe you meant that you just check if people know casting can throw ClassCastException, with that I'm OK.

ajuc 15y ago

I don't know. I remember problems with different classloaders, old versions of classes being deserialized, different versions of classes being sent over RMI, etc. Some of these probably resulted in ClassCastException. Some had thrown more specific Exceptions, am I supposed to remember the exact Exception that was thrown in each case? I'll probably know if you show me stacktrace. But I only know because I've encountered such problems. People working on the other end of our system would recognize different set of problems that results in this Exception or similiar. Nano questions are bad, because you are really asking if candidate has had the exact same experience that you had. Some did, some didn't, it doesn't matter. Anybody will solve the problem within minutes, most probably googling the most promising lines of the stacktrace, and ctrl+clicking around in Eclipse (or grepping the source tree, whatever). Even auto-importing packages in IDE can cause problems - sometimes it imports from the wrong package. Is it enough reason to ask questions about "which package contains Hibernate Session class?" or even "which package contains ArrayList class?". I don't think so. Being aware of the problems good abstractions can cause (there's always a few problems) is IMHO enough, no need to remember everything you can google in 5 seconds. EDIT: or maybe you meant that you just check if people know casting can throw ClassCastException, with that I'm OK.