Why do technical/programming phone screens focus on inheritance?

Question

I've noticed that in most technical phone screens, programming questions tend to focus on inheritance. For instance:

• If a class is intended to be inherited, what should you do with the destructor? (Answer: make it virtual)
• What's the deal with public/private access?
• What's "protected" for?
• Etc. etc.

It strikes me that there are more meaningful questions to ask these days. And, IMHO, reliance on inheritance as the primary design solution to an OO problem is a bit problematic. Am I wrong? Is knowledge of inheritance quirks the best way to assess technical skill?

EDIT

Commenters have asked me to explain in more detail why I think reliance on OO-based questions is problematic. Let's see... Basically, my thinking is that there are plenty of cool, non-OO questions you could ask. For instance:

• (C++) What's the difference between a map and a multimap?
• (C++) What are the two different kinds of things you can use as template arguments?
• (C#) What's an extension method?
• (Perl) What restrictions, if any, exist on the number of arguments a function can take?
• (Python) What are the different ways you can use import, and what are the consequences of those tactics?

I submit that the above questions are also pretty decent weed-out questions. So my question for this forum is: Why don't phone screeners ask questions like those above?

Answer 1

The goal of a phone screen is generally to figure out which candidates it is worth spending the time and energy to interview in person. So the goal is generally to weed out candidates that aren't worth the time to interview in person rather than to identify the best candidates. That means that questions in phone screens tend to skew toward objective questions that deal with relatively basic topics and don't require any code or particularly detailed explanations. The goal isn't to assess technical skill so much as to identify people that don't have the technical foundation to deal with the more interesting questions that would be asked in a face to face interview. The interviewer likely wants to avoid more challenging questions because it is much more effective to ask those sorts of questions face to face where there are whiteboards and scratch paper and candidates are likely to have a much better chance of explaining themselves well.

Phone screen questions also tend to get handed down over time so whoever is interviewing you probably got a list of questions from someone else a few years ago that they've never bothered to update. On the one hand, this means that questions tend not to keep pace with new developments and techniques. But from the interviewer perspective, it's very helpful to have stable set of questions in order to make comparisons easier. When an interviewer prepares a new set of questions, he or she is inevitably shocked that the candidates don't do nearly as well as was expected. Inevitably, the interviewer assumes that certain things are "common knowledge" because they're so common in that particular developer's day-to-day tasks only to find that among programmers more generally, they're rather more esoteric. If you have a relatively stable set of questions, it's a lot easier to judge how a candidate stacks up to prior candidates.

Answer 2

Two reasons.

First because, in a phone-screen, you don't want to ask trivia questions. By trivia questions, I mean those that are easy to people who have used those features and difficult to those who haven't. You can't write well in an OO language without knowing about inheritance. You can without knowing about extension methods.

Second, because often the person doing the phone-screen isn't that technical. In some companies, the manager will do them; in others, a secretary or HR person will do them. In those cases, someone will usually Google for phone-screen questions with answers and these are the ones that come up most often.

Answer 3

They are very useful for the candidate allowing them to weed out interviewers who think inheritance is the most important feature (or indeed only) of OO.

This generally means that they did a CS degree and this is all they remember about programming but have never actually programmed anything in an OO language in the real world.

This reflects courses on OO which concentrate purely on inheritance and the vital importance of a creating hierarchy of shape classes and the vexed question of "is a rectangle a square" or "is a square a rectangle".