Is getting into the minutiae of a technology/language appropriate in an interview?

Question

So I have seen both sides of this question and actually been on both sides as well. In the programming world there seems to be a fine line between great interviewing for the sake of weeding out candidates properly, and that of showing off how much the developers on the hiring side of the table know.

For example, it makes sense to ask someone to pseudo-code or even legitimately code some logic applicable to the job at hand, but I question the usefulness of the interviewer asking a theoretical question like "explain covariance and contravariance" or some other question about a languaute which only the creating product team is probably well versed in (i.e. the .NET Framework team at Microsoft).

I know the initial reaction to this question might be, "Sure, it shows how a candidate does answering a tough question they probably will not know, yada, yada, yada", or "If it is applicable, then 'Yes'..." However, more and more it appears that these types of questions are about the interviewing team showing the candidate how much they know. (I have been on that side of the table when my collegues have done this, and my initial thought was about how irrelevant the question was.)

How can these types of detailed technological questions be useful in an interviewing situation?

Answer 1

It's not necessarily about ego.

I tend to try to dig and find one thing the other person doesn't know, just to see if they try to bluff or if they honestly just say "no, I've not come across that before ... what is it?" (that last bit for bonus points). I don't go hard at it though and I never humiliate a candidate. I don't even want them humbled for the rest of the interview. I just want to know how they react to something they don't know.

However, I have seen a couple of developers interviewing who were clearly just showing off. Those cases were obvious because they were asking questions off a list and then bleating the answer loudly when the candidate got it wrong.

Interesting thing though: neither of them were particularly good developers. I wonder if they were overcompensating. Or perhaps dragging out the trivia portions, where the answers were right in front of them, to avoid getting caught out on more fluid technical conversation (which is where I like to take an interview).

Answer 2

While I'm sure there are developers out there that want to show off in an interview, in the vast majority of cases where I've seen people ask "impossible" questions in an interview, the intent hasn't been malicious. Instead, the problem has been that people in general, and developers in particular, are very bad at knowing in advance how easy a question is likely to be and how likely a competent developer is going to be able to provide a credible answer. Generally, it takes quite a few candidates coming through the door that seem competent but are totally stumped by a particular question for the interviewer to realize that the problem is the question, not the candidates.

When developers spend quite a bit of time in a very particular niche, interacting with other folks that are also concentrating on that particular niche, it becomes very easy to forget the sorts of things that one takes for granted in those conversations that would be challenging for a competent developer in a different niche. When I interviewed with a communications company, for example, one of the engineers had an entire series of questions dealing with Huffman coding. There was one problem on one assignment in one class in my undergraduate career where Huffman coding happened to come up in passing and I hadn't spent any time contemplating the algorithm or why it was structured a particular way so I was way outside my depth trying to answer those questions. To the interviewer, though, who spent a great deal of time dealing with compression algorithms in general, Huffman coding seemed like such a basic thing that any competent undergraduate ought to have internalized it in order to begin to deal with the sorts of problems he was dealing with. I doubt that he was intentionally trying to make himself look smart in front of a bunch of new graduates, it just didn't occur to him that signal compression algorithms aren't a niche that most developers have a lot of experience with unless they happen to be working for major communications companies. I would wager that once a couple dozen folks completely bombed his portion of the interview while doing reasonably well elsewhere, he realized the problem and adjusted his questions.