It all looks really different from the other side of the table. Back when I wrote this, that, and the other thing, the kind of questions that get asked in technical interviews seemed (to a recent candidate) to be unfair, arbitrary, nerve-wracking, impolite, unrelated to anything about the job, and not likely to predict anything useful.
Since that time I’ve probably done 40 phone screens and interviewed 25 people in person (including for other groups). And the questions now seem eminently fair, even though they’re the same questions. (Why, to maintain our high 10% hiring standards, I’ve even taken to playing the “how many fingers am I holding up?” game with _both_ hands behind my back. (Oh boy — I am _just_ kidding. I can’t emphasize that enough. Really just kidding.)) One thing that impresses me is the level of consensus. An algorithms interviewer may like someone while a C++ interviewer doesn’t, but two independent grillers on the same subject will usually agree.
With that said, my biggest worries about the process are that 1) it favors good talkers, 2) it favors people who have done a lot of interviews, 3) it favors quick thinkers, and 4) it can’t tell you anything about persistence.
Quick thinking might seem like a good thing to favor, but people’s thinking styles really do differ a lot. Some people (like me) are really slow mullers — we need a lot of time to think things over, but don’t stop doing it. (I do some of my best thinking in the shower, actually, but most interviewers unfortunately don’t offer one.) I would take a really committed, thoughtful, persistent mind over a whiteboard whiz any day, but I don’t know of a way to test for it.
Tim Converse 
Hi there, interesting blog.
I had this problem in hiring a while back; worse, I needed real maintenance code grinders who were good and had attention to detail, but who could work on a truly evil large system trying to pull it into production readiness without going crazy. I hired a whiz kid who fell into a pit of despair in the first month, contract discontinued after 3 months. I totally understood his problem, but I needed someone who would cope.
For my second attempt I used testing as well as interviewing, and, most importantly, a take-home task. I gave candidates a broken app, asked them to identify and fix as much as possible, primarily via a bug list, but extra marks for finding and fixing undisclosed traps. And it worked! The woman who beat all others on that task, who happened to not interview as well as others, turned out to be perfect for the job.
The moral is, you need to find a way to trial an applicant on what they’ll actually be doing in the job. In my opinion, anyway.
the STAR approach works well in technical interviews…
http://web.mit.edu/career/www/guide/star.html