I have over the last 8 years or so become terrified of interviewing techniques that revolve around having a conversation with a candidate, even (or, in fact especially) directed conversations.
Like many others before me, I've discovered that there is a huge gap between the ability to talk intelligently and productively about solving programming problems, and being able to actually solve programming problems. It's fine to hire someone who can reason through and discuss solutions... as long as you're also going to hire someone who will write the code for them.
Otherwise: get sample code, and watch them code something.
You may find http://www.interviewzen.com/ useful. It's a hiring tool I'm building around the idea that you can tell a lot about someone's coding ability by seeing them in action.
Ha! I had this exact same idea not long ago, that's interesting. Have you talked to (potential) customers? I've had multiple times questions like "what's the advantage over google docs/screen sharing?" (which is free).
Feedback has been very positive so far - customers are finding it makes the initial screening process much easier. One advantage over Google Docs is the ability to do time-shifted interviews, making it a good first filter for job postings.
Feel free to drop me a mail and we can chat further.
But does that perceived gap mean that your technique is actually better for the company? I'm seeing a false dichotomy here where those who can talk about code can't write it, and those who can write code are inarticulate. I have a nagging feeling that being "terrified of...conversations" supplies a bit of confirmation bias to your technique.
Where do you see tptacek implying that those who can write code can't talk about it? He's merely telling us that being able to talk about code doesn't always imply being able to actually produce code.
"It's fine to hire someone who can reason through and discuss solutions... as long as you're also going to hire someone who will write the code for them."
Like many others before me, I've discovered that there is a huge gap between the ability to talk intelligently and productively about solving programming problems, and being able to actually solve programming problems. It's fine to hire someone who can reason through and discuss solutions... as long as you're also going to hire someone who will write the code for them.
Otherwise: get sample code, and watch them code something.