Found via Mark Pilgrim's b-links, How to be a Programmer. Like Mark, I am struck at how good this is, but I can think of a different way to use it.
It's been a while since I've interviewed people looking for jobs. I may be in the happy position to do so again soon. Most of it is down to intangibles: do they know what they're talking about or are they bluffing. I always want to draw them out, which means I need to ask lots of open questions. (A "closed" question can be answered very quickly, in the worst case with a simple "yes" or " no".)
This document is a trove of open questions. Where it has a section headed How to ..., it's easy to substitute, ,"can you tell me about a time when you did ...." or "what is your approach to..."
The way the document is organized, it's also easy to choose. The sections are helpfully categorized into Introduction, Intermediate and Advanced, with sub-sections on things like Team Skills and Judgment.
The actual answers don't matter so much. The ones in this document are good, but I would expect any candidate to speak from their own personal experience and with their own personality.
Of course, I don't always expect to be sitting on the same side of the table. One day, I'll be the one looking to be employed. Many of the same questions are good for applicants as well. (What is your team's approach to version control? How would your company/organization/department generally make a build or buy decision?)
I'm writing about this at least partly so that I can find it again when I want it. A weblog is more permanent than a bookmark.