Looking to Hire an Engineer? 3 Reasons to Forgo the Phone Screening

I just finished an interview circuit for summer internships with six or seven different companies (Fog Creek, Google, some YC startups... other big names here).

The companies in my sampling space definitely were not "filter[ing] out the really bad engineers." It wasn't discussion about hashtables or pointers. They were basically asking me to write actual code over the phone. I was asked to explain how to sort four million items in linear time from a network stream, because there wasn't enough memory to hold the input. I was asked to prove a lower-bound on O-complexity for comparison sorts (over the phone). Several companies asked me to actually implement a hash table, including designing the associated hashing algorithm (really good ones involve some hard prime number math. It's the sort of thing you need math textbooks for).

This is all very interesting, of course, but not really very useful. For one thing, I was not being hired to foster interesting discussion over the lunch table, but rather to write good code--yet these sorts of questions were clearly normal lunch faire. Nobody asked me about how to properly document code, evaluate design patterns--and worst of all, very few companies actually had me write any code to speak of. It was assumed that if I could explain an algorithm, I could write it, which I don't think is strictly true.

In any case, there appears to be some sort of deadlock condition inside my head--the part of my brain that explains an algorithm cannot function at the precise same moment as the part that invents such an algorithm. So while I write great code, I often struggle with phone screens (either I sit in silence for a minute or two to think, or I start spouting off tautologies to give my mind a chance to work). In the real world, it's perfectly acceptable to think before you code, but it comes back to haunt you in phone interviews.

Even more troubling to me is that I have a pretty extensive list of projects on my resume (web stuff, OSS stuff, etc.) and nobody (NOBODY) actually looked at any of the published code I've written. If I was hiring someone who had put OSS code on his resume, the first thing I would do is checkout the source and poke around, but I guess asking constant-time-sort questions in rapid succession is more fun than doing actual work.

If the companies hadn't made me an offer after two or three phone interviews (maybe half?), I told them thanks but no thanks when they tried to schedule more. I looked the hardest at the companies who had me write and e-mail them actual code, which I had time to carefully contemplate, after which the "interview" was largely a formality.

Exactly. He starts with saying that Sergey Brin wouldn't pass Google's phone screening, but (at least when I interviewed with them for an internship) Google phone screens with engineers. The conversation was good, the problems were an interesting/fun challenge, and it would certainly have been effective in deciding whether I was cut out for the position.

I think that the argument should be rewritten to say that the only people that should be judging competence are the ones that work in the field. An HR person shouldn't be trying to decide whether an applicant has passed a screening. They should get an engineer to talk to them instead and decide.