Unless one is interviewing for a really specific set of capabilities for a particular job, it's best to try to gauge aptitude for programming positions instead.

Unless one is interviewing for a really specific set of capabilities for a particular job, it's best to try to gauge aptitude for programming positions instead. I believe that it's possible, with the right questions, to check for basic competence in a few areas and to avoid some bad hires. I have a few small problems in my repertoire that can be solved by any good programmer in 5-10 minutes, but can't be solved in even 45 by a candidate who lacks basic understanding of how to analyze a problem, deal with basic abstractions like indirection, etc. I.e., I've given up on trying to distinguish the great candidates from the good ones, and now I just try to identify the people who just have no idea what they're doing. The error bars around the results of a 45-minute technical interview are just too damn wide, even with research and training, to do anything except try to prevent obviously bad hires.