Interviewing programmers on philosophy

Today I took a survey on Object Oriented Concepts. Two computer science researchers are trying to determine how divorced the theory they teach is from the day to day practices of professional programmers. Here’s the introduction:

You have done some programming for fun, or you are a professional that has been on one of those $2000 a day professional development courses, or read the latest book, or subscribed to the current in-RSS feed, so you know how you’re supposed to write good code. But do you actually write code the way you’ve been told is The Way, or do you ignore the theory and follow the tried and true practices learned the hard way in the School of Hard Knocks, the way that really works?

We’re researchers. We know what we teach and we know what all the research papers/books say, but you write the code – you know what really works and what’s just so much theory. Here’s your chance to tell us what you know.

If you’re a programmer, you may want to take the survey. I’m sure the researchers would appreciate it.

I’m so enamored with it that I think I’m going to post my answers to each of the groups of questions here, just because I wanted to add more detail and also because I think they’re interesting points of discussion.

What the survey really made me think, though, is that programmer interviews should center more on questions of philosophy. Obviously after an interview you should know whether the person you interviewed can program, but it’s also helpful to know whether you’d actually want to let that person touch your code. I think philosophical questions could extract more information that pertains to both. They also measures the thinking skills of the candidate, and their ability to communicate effectively.

Here’s one of the questions from the survey: “When working on a class, is its depth in the inheritance hierarchy important to you?”

That’s something that someone who thinks about programming could really chew on. If a candidate doesn’t even know where to start on the answer, that tells you something about them immediately. Or perhaps they answer in great detail, but their answer is the opposite of yours, and you don’t find their argument in favor of their side convincing. Do you really want to sit in meetings with this person for the next few years having this same discussion over and over? Do you want them refactoring your code because your way is different than theirs?

After responding to the survey, I want to ask other people these types of questions. They drive right at what’s important in finding good team members.