The title is "Most Technical Interviews Suck". The content is about how what a series of interviews at one specific company sucked, and the interviews didn't sound all that technical. Bad day, sure. But definitely not supporting the title.
I mentioned at the end that I do acknowledge this is a specific case, however, it is just an example followed by a conclusion. What I wanted to say is simply that technical interviews in general tend to focus on the question itself more than the person being interviewed.
I've done a lot of interviews. Hired a bunch of people. And I'll agree that technical interviews aren't a great proxy for how we really should be handling hiring (blogged about it a couple days ago http://mlaroche.blogspot.com/2011/10/algo-interviews-are-ove.... Must be college interview season where you are too if we're both thinking about it.).
Some of the worst candidates have had the best resumes. I'd bet good money they could have talked coherently about their projects, made it sound like they'd cured cancer. But when I asked them to do something not much harder than FizzBuzz on a whiteboard, they choked. Ask them to intersect two lists? They'd use Excel. Ask them how Excel would implement that? They freeze, the interview is over. This was a normal pattern. Thankfully, our recruiters started asking pulse-checking questions, and the number of these interviews dropped.
Interviews need something that can't be directly prepared for and directly rehearsed. Unfortunately, I don't think your solution has provided that. I think it would tend to hire silvertongued people who cut and paste.
I just replied to another comment with a similar point. I am not suggesting we should never ask technical questions. All what I am saying is that we need a balance between technical questions and knowing about what the person did or can do. (Look like I might need to update the post to mention that)
