I agree with you on every point. I hate gauntlet interviews/interviewing and the questions should definitely be targeted towards hire/nonhire.
Only I don't think you meant this the way it sounded, so just to be clear: "does the candidate know how to code?" shouldn't be the only criteria you're testing for in a good hire.
There's much more to a good engineer than how well they code, of course. Technical skills are key, but hiring managers need to ask things that also help reveal behavioral things like communication, teamplay, unstoppable ego, etc.
These can all be major problems and, in my experience (hundreds of interviews now) by the time they're at an on-site interview, these should be a major (if not the majority of) focus. Ideally, if you handle your interview process in an efficient manner, you should be pretty comfortable with the technical skills before an on-site interview where the primary technical questions/tests should be just to verify they weren't cheating off-site.
In the world of ajaxy collaborative text editors (e.g. Google Docs) and screen sharing tools (e.g. dimdim/GoToMeeting/WebEx), etc, there's no reason you shouldn't include programming assignments as part of phone screens using their home machines, observing their coding live on the phone/screen. Bringing candidates on-site without doing something like this (especially for a 6-hour gauntlet interview circus) is risking a day of theirs and a day of yours to find out something you could gather without bringing them in.
Only I don't think you meant this the way it sounded, so just to be clear: "does the candidate know how to code?" shouldn't be the only criteria you're testing for in a good hire.
There's much more to a good engineer than how well they code, of course. Technical skills are key, but hiring managers need to ask things that also help reveal behavioral things like communication, teamplay, unstoppable ego, etc.
These can all be major problems and, in my experience (hundreds of interviews now) by the time they're at an on-site interview, these should be a major (if not the majority of) focus. Ideally, if you handle your interview process in an efficient manner, you should be pretty comfortable with the technical skills before an on-site interview where the primary technical questions/tests should be just to verify they weren't cheating off-site.
In the world of ajaxy collaborative text editors (e.g. Google Docs) and screen sharing tools (e.g. dimdim/GoToMeeting/WebEx), etc, there's no reason you shouldn't include programming assignments as part of phone screens using their home machines, observing their coding live on the phone/screen. Bringing candidates on-site without doing something like this (especially for a 6-hour gauntlet interview circus) is risking a day of theirs and a day of yours to find out something you could gather without bringing them in.