[prodigal_erik]

I'm not a big fan of trivia, but there are basic details you will necessarily learn over time just by working with any technology, and not knowing these is damning. E.g., asking how arguments are passed is a quick shibboleth to catch the guy who thinks clicking "print to file" entitles him to put PostScript on his résumé (a colleague has actually witnessed this).

[kls]

the problem is that these questions can devolve into a (you know) waving contest in which the interviewer is, instead of interviewing, satisfying his own ego by asking obscure questions that sever no purpose other than to inflate the interviewers perception of his own intelligence. This is particularly dangerous in technology professions where their is a high propensity of intellectual self-conceit.

I understand the low hanging fruit, I just witnessed and interview the other day for a Java web developer, and one of the questions was describe a singleton pattern to which the interviewee could not respond. Given that there has been a history of singleton / Java / Bad things web applications problem, not understanding the pattern is a significant issue and I did thing it was an appropriate question to use as a filter, but asking a web developer deep questions about class-loader nuances seems like overkill to me and I have seen that done as well.

[count]

I always loved to ask a single super obscure question that almost nobody would know the answer to. I didn't expect, or desire the 'correct' answer, I wanted to see how they handled the fact that they were asked something they almost assuredly didn't know. Did they say 'I dunno' and just shrug? Did they make some shit up? Did they try to work it out? That reaction to the uncertain/unknown is, I think, a pretty important part of figuring out if they'll be good to work with - who doesn't run into something unknown on a fairly common basis?