Interesting point, but I think this post is attacking a certain kind of phone screening, rather than all phone screening.
If you get a (people-friendly) geek to do the phone screening instead, with a single question: "would you like to have a further 30 minute chat with this person?", I would hope you get better results.
I'll agree that getting HR to do your phone screening for technical people is pretty disastrous though.
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.
The author seems to fundamentally misunderstand the point of a phone screen, you don't ask trivial questions to see how good the engineer is, but to filter out the really bad engineers.
If someone doesn't know what a hashtable or a pointer is then there's no point in wasting their time or yours in bringing them in for an in-house interview. Many companies reject as many as 70-90% of candidates at phone interviews due to candidates lacking basic skills.
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.
Yes - this. I've been doing the same for the past couple months, and I've encountered several types.
Some companies just have me recite my resume - I feel these haven't done any legwork at all, and I usually don't bother.
Others seem to have looked over things, and have me describe in detail the problems I solved, the various alternatives I considered, and so on. This is a good thing!
Only two companies sent me coding assignments, which I completed rather well, I think - I imagine these companies got the best feedback of what I was capable of.
Aside: coding problems are a fine line to walk. One assignment I got had a trivial implementation of the spec, so I actually extended it to make not trivial (basically, they removed everything but the special cases). I extended the problem and wrote the general code.
Other companies have problems that require quite a lot of coding, or at least a lot of time to think and design "correctly". They are interesting problems, but when hiring interns, companies should remember that interns are also usually full-time students (and this one hold a part-time job as well). I just simply didn't have the time to devote to implementing your complex problem, especially when I'm only half-interested in your company.
In the end, perhaps my experience was slightly unusual, because I think my resume displays a lot of experience doing the things I am looking to do more of. Also, looking for an internship is much different than looking for a full-time job.
Hiring is difficult, yes: companies have a hard time finding good engineers, and good engineers have a hard time finding somewhere interesting to work (Social networks are cool and all, but if you're building one that simply targets a specific set of people, with no extra differentiation, I'm simply not interested.) This is why I'm so interested in entrepreneurship - you get to work at a great company, and you only have the best engineers working for you! (Hopefully.)
I've found that aggressively filtering resumes does a better job than a phone screen. E.g. the presence of "Three years at Microsoft as an SDE" or "Avid reader of Joel On Software and Coding Horror" give you better people than just those who know what a pointer is.
I'm not sure I've ever read an article that's more wrong.
First, refusing to an employer's criteria of hiring will never get you hired. There are more degrading things in this world than explaining technical, even trivial, things to a non-technical person.
Secondly, SAT or any other standardized scores aren't a test of intelligence. Even purporting so shows your level of intelligence. I know plenty of engineers and programmers who did poorly on standardized tests yet who are freaking geniuses compared to others who scored much higher.
Yeah, I agree that reviewing resumes more closely might be a better indicator of qualification than a phone interview, but I don't think they should be entirely forgone. They add an important level of inspection.
11 comments
[ 3.1 ms ] story [ 30.0 ms ] threadIf you get a (people-friendly) geek to do the phone screening instead, with a single question: "would you like to have a further 30 minute chat with this person?", I would hope you get better results.
I'll agree that getting HR to do your phone screening for technical people is pretty disastrous though.
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.
If someone doesn't know what a hashtable or a pointer is then there's no point in wasting their time or yours in bringing them in for an in-house interview. Many companies reject as many as 70-90% of candidates at phone interviews due to candidates lacking basic skills.
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.
Some companies just have me recite my resume - I feel these haven't done any legwork at all, and I usually don't bother.
Others seem to have looked over things, and have me describe in detail the problems I solved, the various alternatives I considered, and so on. This is a good thing!
Only two companies sent me coding assignments, which I completed rather well, I think - I imagine these companies got the best feedback of what I was capable of.
Aside: coding problems are a fine line to walk. One assignment I got had a trivial implementation of the spec, so I actually extended it to make not trivial (basically, they removed everything but the special cases). I extended the problem and wrote the general code.
Other companies have problems that require quite a lot of coding, or at least a lot of time to think and design "correctly". They are interesting problems, but when hiring interns, companies should remember that interns are also usually full-time students (and this one hold a part-time job as well). I just simply didn't have the time to devote to implementing your complex problem, especially when I'm only half-interested in your company.
In the end, perhaps my experience was slightly unusual, because I think my resume displays a lot of experience doing the things I am looking to do more of. Also, looking for an internship is much different than looking for a full-time job.
Hiring is difficult, yes: companies have a hard time finding good engineers, and good engineers have a hard time finding somewhere interesting to work (Social networks are cool and all, but if you're building one that simply targets a specific set of people, with no extra differentiation, I'm simply not interested.) This is why I'm so interested in entrepreneurship - you get to work at a great company, and you only have the best engineers working for you! (Hopefully.)
First, refusing to an employer's criteria of hiring will never get you hired. There are more degrading things in this world than explaining technical, even trivial, things to a non-technical person.
Secondly, SAT or any other standardized scores aren't a test of intelligence. Even purporting so shows your level of intelligence. I know plenty of engineers and programmers who did poorly on standardized tests yet who are freaking geniuses compared to others who scored much higher.
Yeah, I agree that reviewing resumes more closely might be a better indicator of qualification than a phone interview, but I don't think they should be entirely forgone. They add an important level of inspection.
So you know he knows what he is talking about.