[paulbaumgart]

Inspired no doubt by Joel Spolsky's famous (in some circles, anyway) article: http://www.joelonsoftware.com/articles/GuerrillaInterviewing...

Their objectives are basically the same. The difference is in the ways of proving the "getting things done" part.

I never assumed the programming questions in an interview were really about getting the right answer in ten minutes or however long you spend on it, but more about giving the interviewee an opportunity to explain their thought process and problem solving approach to the interviewer. I don't agree that asking interviewees to solve programming problems in an interview is useless, but obviously looking at code samples from other work is great, too.

[jacoblyles]

>"I never assumed the programming questions in an interview were really about getting the right answer in ten minutes or however long you spend on it, but more about giving the interviewee an opportunity to explain their thought process and problem solving approach to the interviewer."

That's what they say. But do you know anyone who failed the questions and still got hired? My experience has been that even when I nail the algorithmic questions, I miss a few trivia questions and don't get called back. Nuance cannot be replicated at corporate scale.

[jerf]

Well, I can say on the flip side I've been involved with hiring decisions where the interviewee did not nail every single answer, but we hired anyhow.

It should be pointed out that I structure the interviews to try to avoid that case anyhow. If your interviewee nails everything, it either means that you've got a class-A programmer, or your interview difficulty tops out too soon. I've become a big believer in gradated interviews. I've got a pretty good SQL series that starts out where the answer is literally "SELECT * FROM some_table" (though I find it occasionally trips people up to simply omit the where clause) and goes up from there on this little two-table schema. I've got some good HTML generation series that starts out with a simple "can you dump out a table from a 2D array or equivalent structure?" (since I try to do language-agnostic interviews) and go up through "do you know about escaping" and "can you handle optional parameters" and so on. Over time I've been selecting for the series that produce more gradation.

[paulbaumgart]

Potentially worthless anecdote: I mostly botched an algorithm for finding Pythagorean triplets in an interview recently, and still got called back. (For round 2 I brought a nice big cup of coffee ;-)

I don't have the experience to know how well it works in the general case, though. Anyway, I don't think Aaron is arguing against interviewers using the technique wrong, but rather that it doesn't correlate at all with "good hires", even when used more intelligently. I don't think that's true.