Friction

{

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:
1. Web Application Development (HTML / CSS / Javascript / ASP.NET (or any other web app framework or perl/scripting env)
2. "Fat" clients (Windows Forms .NET / COM )
3. Database programming and administration (SQL / Database Design)

I then follow up their ratings of themselves with some general questions in each area. For example, most people consider themselves knowledgable with web development because they know some basic html. Questions I like to pose here may be along the lines of asking what the difference is between DIV and SPAN elements, or what their understanding of why XHTML (versus HTML 4.0) came into existence, or whether they think designing with tables is a bad idea. On the programming side I like to ask a person about the postback cycle in ASP.NET, or if they come from a non-.NET environment, about something like state management (querystring, session, etc...) in web applications. Another favorite area of mine is javascript since many people think they know it but can't provide answers for even a simple question like how to register an event for an html element. When I ask questions the point is definitely not about trivia but more to gauge whether the candidate is about aptitude or whether they'd be capable of jumping right in the fray and making a contribution.

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.

}