Reading Joel Spolsky and others on the hring process is always interesting. One aspect of their writing that has always intrigued me has been the "quiz questions" used to get a feel for the interviewee's level of intelligence.
Lately I've been interviewing people regularly and am slowly coming up with a format that gets me closest to a person's technical level as it pertains to our company. I usually ask a person to rate themselves on a scale of one to ten in three areas:
2. "Fat" clients (Windows Forms .NET / COM )
3. Database programming and administration (SQL / Database Design)
But beyond the technical questions, beyond the idea of "Smart, Gets Stuff Done" as goals in the ideal candidate, probably the most important thing about working the environments I've been exposed to is learning how they deal with "Friction." I was watching a panel show once on CSPAN where a wizened old military man said: "The difference between war plans and war is friction." As I understand it, friction has to do with all those little things (and big things) that go wrong. In our case, friction is almost always involved in trying to hit release dates. Friction is also a big player when it comes to team dynamics and how people treat each other.
For all the talk online about people who are exceptionally smart and productive, I'm surprised that the question of friction isn't more important when choosing programmers since friction is always a part of software development. Everyone's got a story about this, but here's mine: I worked with a guy who was exceptionally sharp, anal-retentive, and detail oriented. He'd forgotten more within his discipline than I probably will know. I would ask him from time to time for help on the little problems I was dealing with and his answers were always prompt and accurate. We worked together as peers and that's what made me capable of liking him however, for many people, he was nearly impossible to deal with because any change that required flexibility on his part was out of the question. If I'd been a team lead on a project, he'd be a difficult decision because of this attitude, and what would push me from the "maybe" into the "no" decision would not be my own ability to work with him, it would be his affect on the team as a whole and how he affected the team's group culture.
One thing to bear in mind is that I'm a consultant who writes business-ware which may mean that friction comes up for me a lot more than someone working at a shrinkwrap company, or a behemoth powerhouse with zillions of great hackers. But as my experience accumulates, I begin to see that a person who has the ability to calm a client down while being able to refocus and get a project out the door is more valuable than a person who is a brilliant programmer but unable to deal with the type of rapid change and improvisation necessary for our work.