The Dark and Obscure Art of the Phone Interview

[nonnihil]

Being in the midst of a job hunt, I am doing a lot of phone interviews. Because I hate phone interviews with the burning fury of a thousand suns, I would very much prefer that the phone interviews that must be conducted yield a maximum amount of useful information in a minimum of time, so that I don't have to do, eg, four or more phone interviews with the same company.

So let me offer some helpful advice. I have redacted the names of the companies involved to A, E, I, and O.

A good phone interview starts with actually calling. Company O, the same company that thinks it sensible to schedule four or more phone interviews, finds itself unable under the circumstances to actually call at the times it schedules, or indeed at all. When it does call, it calls the wrong person (sorry, unknown person with my same first name, that Company O keeps calling you at unusual times!)

Now typically there are some technical questions -- attempts by the company to determine whether I actually know anything. (Well, company A saw fit to completely omit this step, which sort of makes me wonder why they called me at all, but all the rest wanted me to answer some questions). I am a connoisseur of technical interview questions, and am always eager to hear new ones, but I have come to some conclusions about these questions from which a budding technical interviewer might benefit.

For instance: You will not have your Software Engineer job title revoked if you do not ask a question about Quicksort. I don't know where this rumor came from, that everyone is obligated to ask a questing about quicksort. Perhaps it is the only algorithm that anyone can remember after college? Let me tell you a few things about quicksort:

• Note to Company E: "Dictate a quicksort implementation in C, over the phone, right now" is not a good technical challenge unless you are attempting to hire techno-autists or undergraduates. I am appalled at myself that I could answer this, and doubly appalled that an interviewer would consider that a good thing.
• Quicksort is provided in the standard library of virtually every modern programming language. While an algorithms geek might be able to provide you with a nifty implementation, in real life everyone -- EVERYONE -- worth paying a salary to will implement it with the language-appropriate equivalent of "#include ". That is why they are engineers, rather than professors.
• Also, even that is usually silly. I have checked my company's 100K+ lines of code, and found exactly two array sorts, both of which ought to have been avoided, and neither of which is done on an array large enough for algorithmic performance to matter. I suspect that this is generally true: Most arrays that will ever be wanted sorted can be better generated by sorted insertions, spreading the latency over inserts is better in general, and the exceptions will mostly want to preserve the original array and so prefer a nondestructive sort (copy-the-array-and-then-quicksort will be much slower than mergesort or heapsort. Trust me on this).
• So, dudes, why the obsession with whether an experienced and battle-scarred software engineer can spit out facts about quicksort? You're embarrassing yourselves (particularly you, Company O. I know for a fact that you have some good technical questions in your files, so you can't claim inexperience).

Some technical questions come tantalizingly close to not sucking, before returning to the mire of awfulness. Here's an example of a bad technical question, taken from Company O. Company O requested confidentiality (doubtless out of embarrassment), so let me cut out the crucial detail and give you the essence: "When you [do obscure thing X] to a running Java process, what happens?"

• There are a number of interesting questions that this might mean. "In what order does it affect your threads," for instance, or "are finalizers called, and if so on which thread," or "could this condition be detected from running code?" In fact answering those questions requires a deep insight into the inner workings of the java interpreter.
• There are also some silly and superficial questions here, eg, "what is printed to standard error?" This is a silly question because (1) it pretty much requires that the interviewee have at some point done X to a java interpreter, which isn't a terribly interesting job qualification, and (2) in a phone screen, it pretty much invites the interviewee to do X to a java interpreter and tell you what happens, which also isn't an interesting job qualification.
• But hey, you know what would be even sillier than meaning the latter of those? Meaning the latter of those, but only mentioning it after you let the interviewee puzzle through the answer to the former, a priori, for five minutes and then tell him that no, he's wrong, because you meant the latter.
• Particularly if the interviewee has previously mentioned that the j2me interpreters he works with generally don't actually have standard error, and so he logically would be very, very unlikely to have known or cared what was printed there.

I note at this point that I haven't said anything nasty about the phone interviewing prowess of Company I. This is because Company I's phone interview was effective, concise, challenging, and informative (well, it could have been done in one call rather than two, but that seems too much to ask these days). So take heed, all of you: It can be done right, you just aren't doing it that way.