> I'm going to ask them to explain how a closure works. How they deal with AJAX. What they think about "!important". Things to be careful about with floats. How

> I'm going to ask them to explain how a closure works. How they deal with AJAX. What they think about "!important". Things to be careful about with floats. How CSS precedence/specificity works. Give them an example webapp idea, and ask how they might architect it. ... None of these are gotchas. You can do those in a half hour initial phone screen. Getting an idea of the applicant's general and/or domain-specific technical competence before you fly them out absolutely makes sense. I think what the author is criticizing, or at least the part of the author's criticism that I agree with, is the typical on-site interview that spends 3+ hours testing one's algorithmic knowledge and whiteboard coding skills. I do think that approach is vastly superior to doing nothing at all, but my personal experience suggests that testing the applicant's skills in a real life situation, after having vetted their technical knowledge/competence over the phone, seems more likely to identify strong engineers.