I have been reading Joel on Software, which is Joel Spolsky's web site on programming, interviews, jobs, etc. (He is also the author of the book by that name.) Via one of his blogs, I found another site, Gayle Laakmann, who is an undergrad CS student at Penn. Both sites contain, among other things, interview questions given at companies like Google, Microsoft, etc.

"An important thing to remember about interviewing is this: it is much better to reject a good candidate than to accept a bad candidate. A bad candidate will cost a lot of money and effort and waste other people's time fixing all their bugs. If you have any doubts whatsoever, No Hire."

I can accept that given the amount of competition for software jobs, some people will fall through the cracks. However, no one should be surprised if people who actually held software positions and were actually getting work done become discouraged and leave the field if they find themselves unable to pass these interviews. Since these interviews come fairly early in the evaluation process, there's nothing they can do to offset a poor performance that's not indicative of how well they'd actually do the job, such as using their references. (Although one could make the argument that references will generally say good things, so chances are you're not going to find many, if any weaknesses that way in candidates.)

cellio, you have been interviewing potential hires lately; are you finding that there is a strong correlation between performance on this type of interview and on the job?

Comments

The vast majority of the people we've hired have turned out to be very good, but of course I don't know how many other good people we didn't hire.

Informal networking before the interview does help provide useful information. High-tech-wise, this is a small town; odds are good that someone here has worked with the person if he's local. If he's not local, I think some reference-checking happens before the expense of flying him in for an interview, but I could be wrong about that.

We aren't as hardcore as what Joel describes, by the way. And we deliberately spend a good chunk of time talking in a group setting about higher-level stuff and not code, so we can see how the person interacts with a group, talks about his methods, etc. And we want to make sure there's a good fit in both directions, so we talk about what he wants to do and what his ideal job is and so on and he asks us about the stuff that matters to him.

I'm wondering in the case of closely-matched candidates, or borderline cases, if there are actually measurable differences that would show up on the job. For example, in my latest phone screen, I was asked some questions about named. One of them was what port it listened on. I didn't remember and said so. Perhaps I should have said that I could look the port number up in /etc/services, but I didn't think to do that. (I was starting to become stressed again.) But in the course of the discussion, I did say other things that I thought would give the interviewer the impression that I generally had knowledge of it, such as the different types of queries, zone transfers, that it listened on TCP and UDP, etc. Then there was a question about whether you could get that information from tcpdump. It does allow you to print out the contents of several types of packets, but I wasn't sure if it could do specific types of DNS packets. But I did say that you could, at least, look at an octal dump of packets in the ethernet frame, so even if the specific DNS packet types weren't supported, you could inspect the packets yourself. There were other questions like this, where I couldn't remember the specifics but I gave what I thought was good enough information to show that I understood the concept.

I didn't make it to the next cut of interviews, and I'm wondering in the case of people who did, what's the difference between them and me. I wouldn't think that something where all one needed to do was look something up, perhaps taking a couple of minutes, would be significant in terms of employee performance. And anyone can momentarily forget something like a port number or a program option. Perhaps the decision wasn't made on the basis of the interview per se, but on other things, e.g. other candidates were still working (and presumably "fresh"), or younger, or came from companies where they were able to focus on these types of problems more than I could. But there's nothing I can do about that.

Oh, yuck. We don't ask trivia questions. We do ask every candidate for a programming position to write code on a whiteboard; the problems vary but are of a size that you reasonably can write them on a whiteboard. And we ask usage-related questions, but not "what port does named listen on?" (who cares; you can look it up) but rather "what's the difference between an abstract class and an interface (and when would you use each)?" and stuff like that. We'll ask about the specific technologies that he claims and we care about, of course, but it's more at that level than "what does $function return?" etc. About the closest to "trivia" that we get is stuff like asking the running time (that is, big-O notation) of, say, bubblesort. And if they can't give the succinct answer but can describe it that's fine.