I'm giving my second technical interview next week, and I'm wondering what makes for a good interviewer.

The first time I gave one, I tried a version of pair programming in an attempt to break the monotony of similar interviews and to get a feel for what their work sample might look like. Unfortunately, the candidate ended up stumbling through the interview, even on what I thought were very simple parts, and I didn't feel comfortable saying whether it was an issue on their end, an issue of development environment and tools, or interview failings on my part.

So for the upcoming one, I'm thinking of going with a more traditional hourlong <strikeout>waterboarding</strikeout> whiteboarding approach. But I'm still left with a question of how to approach it, effectively and compassionately. Structure-wise, I'm thinking of splitting it 10-15 minutes for introduction and warmup question, around 30 minutes for a more complicated question, and using the remaining time to talk him through any issues he had while coding and give him a chance to ask me some questions. IME this is the standard approach--what do you think of it?

Two things I currently think are valuable (though I'm eager to get feedback on):

1) Taking notes and pictures--I should be able to go back and objectively reflect on his skill level.

2) Balancing between not stepping on the interviewers toes, and being an effective spotter when there's a blocker that wasting time on something that won't give me any more actionable information.

Beyond that, though, what things should I do to make sure the interview acts as a solid predictor of future performance? And as the interviewee, what makes you walk out of the interview room feeling like the interviewer respected you as a human being and gave you the chance to perform at a representative level?

Also, is it weird to ask for feedback from them on how they think you conducted the interview?