This is one interview question I ask in every interview, and I get a lot of grief for it. I've done it for years. I used to work for a guy who was primarily a Delphi developer, and he as much as ordered me to not ask that anymore. I think it's a fair question. People who work in IT using an object oriented language should have a basic grasp on what the three tenets of Object-Oriented Programming are. If you work in an object-oriented language, you know what they are, but you may not know what they're called.
- Encapsulation: This is basically information hiding. All it means is that data internal to the class that other classes have no business messing with are inaccessible to the naughty classes trying to mess with them. That's what the "private" and "protected" keywords are for. If you make everything public, you might want to go pick up the old Bjarne Stroustrup book. This is your craft, time to learn it.
- Inheritance: This one is easy. It's what comes after the colon in your class declaration (in C-style languages, anyway). Most everybody knows what this is. One hopes they do, anyway.
- Polymorphism: This is the one everybody forgets. It's also the hardest one to describe. In layman's terms it means you have a virtual function/property/whatever declared in an ancestor class that is overridden in a descendant class. For instance, if you have a Shape base class with descendants Square, Rectangle, and Circle, you might have an Area() method on the base class that is implemented differently by each descendant class. A Shape pointer/reference that actually points to a Circle will calculate (Pi)r^2. A Square will calculate W^2, and a Rectangle will calculate L*W. The more common example is the Employee base class that calculates salary differently for hourly and salaried employees, without the need to know what type they are. You just automatically get the right one because the method is virtual.
Most people are familiar by now with how virtual methods work in their favorite OO language, but most people don't know there's a computer science term associated with that behavior. That's why I ask this question. I don't expect most people to get it right, it's about the reaction to the question.
The results to this question are always fascinating.
At a previous job, one candidate answered that he wasn't sure if he had the right answer, but tried anyway. He went on to describe Encapsulation. I gave him credit, because he was A) honest that he wasn't sure, and B) I was pretty sure he knew the answer at one time, because describing Encapsulation means he actually learned the three tenets at some point. We hired him. He realized what a nuthouse he'd gotten himself into and left. C'est la vie.
I told a friend of mine about this question and she used it in an interview. The interviewee responded "Oh, that's just a buzz word". That's the kind of thing that sets me off. You can't possibly think I would ask a question I didn't know the answer to? Don't bluff. Calling one of the staples of computer science a "buzz word" shows that A) you're bluffing, B) you don't really know, and C) you've dismissed it as something not necessary to learn to do this grunt work thing called programming. Any monkey can do this, right? Calling polymorphism a buzz word is a bit like saying the X-Ray is a passing fad in the medical field. This kind of answer tells me that coding is not a craft to this person, it's a 9-5 job. Programmer is not what they are, it's just their job. That doesn't make them a bad person necessarily, just not somebody I want to work with.
A more recent interviewee responded simply "I don't know". Surprisingly, this is a good answer. It shows honesty and integrity. It tells me that I can count on a straight answer from you when I need it. Besides, I was pretty sure he knew it, he just didn't know it's name. There's a Taoist tenet that states "knowing gets in the way of learning." This sounds absurd at first, as do most Taoist tenets, but someday it will click, if it hasn't already. Admitting that you don't know means you're able to learn it. That's a good thing.
You can learn a lot from an interviewee from this question. Short of having them actually write code (which I think we should), it's one of the best ways to cut through to what kind of programmer this person is.
I've been talking with my boss recently that I think the interview process for developers is a bit flawed. We hire people based on their ability to interview well, not their ability to write good code. Jeff Atwood of Coding Horror wrote last year about the FizzBuzz test. Jeff is one of my favorite bloggers. He takes his craft seriously and has trouble with people who don't. He defines the type of person I want to work with. Luckily, most of the people I work with currently qualify. I've suggested (seriously, even thought I think it wasn't taken as such) that we should administer the FizzBuzz test. The test is simple.
Write a program that prints the numbers from 1 to 100. But for multiples of three print "Fizz" instead of the number and for the multiples of five print "Buzz". For numbers which are multiples of both three and five print "FizzBuzz".
Since I work with good developers, I find it hard to believe that 199 out of 200 applicants could not pass this test. I would hope most of the candidates I see could. Maybe they can't. This test would tell us a few things though.
A) Whether or not they can write code at all. That's a good thing to know when you're hiring a developer at near those kinds of salaries. Some people interview really well, and can't write code to save their mother. That's not necessarily easy to glean in a 30 minute interview unless you ask them to write code.
B) How they code. Truthfully, there's more than one way to solve the FizzBuzz test. The "obvious" choice is to use the modulus operator, but there's always another way. Say using counters. How the applicant solves the problem is telling. Also, seeing them code the answer gives you a clue to how they work, something you can't tell from a finished product, even if they get it right.
Anyway, there's no summary point to this, just a final suggestion. Take your craft seriously. It is a craft, it is an art. Your college COBOL teacher was wrong. It's what we are, not just what we do. If you don't "go try that out at home" occasionally, if you don't have some sort of IDE installed on your home PC, you might reconsider is this is the right career for you. On the other hand, if you're reading this blog, it's highly unlikely that you fall into that category.