Help me phone screen interview candidates more effectively?

This is probably irrelevant, but here is how companies I respect interview for tech jobs: 1) Phone screen 2) Ask for code samples and give tests as necessary. Ideally leaving room for creative responses and avoiding the "trivia questions" approach which is proven to be useless 3) In-person interview That way the in-person is a respectful conversation- you know, the way job interviews are done in literally every other field. The ones that don't treat people with decades of experience like slow children being sent to a blackboard to do a problem. I know basic respect for tech people as human beings is out of fashion, but just thought I'd throw it out there.

Here's one approach: go through all the resumes with a highlighter, hitting any elements that relate to the job description. Resumes with no highlighter get binned, which narrows down the field. When you call the candidate for our prearranged phone time, spend a few minutes describing the organization, a few minutes talking about the job itself, and then just ask, "Your resume (cover letter) says that you have experience with yak-shaving/sysadmin/fryer-scrubbing. Can you tell me some more about that, please?" Anyone who can't talk easily about this for a few minutes is in trouble. Anyone who can't, after that, tell me what the hardest part of that work and/or their favorite part, may also be in trouble. The last step is a face-to-face interview. If you use the phone well enough, you only have to interview a few folks. :7)

Could you send them a code sample right before your interview and ask them to explain it?

outlaw of averages: oh. my. god. that looks *perfect*

I've done hiring for Pivotal Labs here in Singapore, and our first step is to spend 45-60 minutes pair programming with a candidate on a simple java problem (that touches on most of the elements of Steve Yegge's questions above). The pairing can be quite easily done via Skype screensharing (the candidate doesn't do any typing, they just have to talk and think) and it makes sure that they can code before they spend time pairing with our engineers. We do the same pairing exercise with every candidate so that we get experience tracking how good various aspects are as predictors. Good luck, Carl Coryell-Martin

Not something to adopt right away, until you have some practice with questions you're comfortable with, but I've noticed that even with good interview questions there are people who will duck them and dodge and generally avoid providing you with the solid answers you're looking for. This is because those solid answers do not exist. In your case, sometimes they can't provide details about their project because they had to have their hands held through it and don't really understand what it did; they didn't understand the algorithm they were told to implement; and there is no syntax they are proud of. But as I said - not to adopt until you know you can catch the people who DO know their stuff.

with #2 - please help me come up with better questions or a better way to gauge someone's technical competency in SQL and/or C# over the phone. The last time I was job-hunting, several phone screens used things like shared google docs and piratepad to write actual code.