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.)
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.