Strong opinions, weakly held

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.


  1. One thing that really stuck out to me was that none of the options for question 12 were related to maintenance. The primary thought I have when designing any sort of object hierarchy is “how much of a pain is it going to be when I have to come back in 6-12 months to change something?”

    That is almost covered by both the “making it harder to change code” and “making it easier to understand code” options, but I really wanted a “making it easier to change code” option because that’s actually what I’m trying to do – mostly because client requests result in not-irregular changes.

  2. My experience matches Rob’s: they had free response areas most of the times I wanted a “this will make it easier for us to deal with changes” option but a first-class option would have been nice.

    I was also struck by how much my answers have changed as I’ve spent time using duck-typed languages. Inheritance is a lot less hazardous when you’re not doing it because everything passed to key methods requires a common ancestor.

Leave a Reply

Your email address will not be published.


© 2024 rc3.org

Theme by Anders NorenUp ↑