As a C++-programmer in interviews I repeatedly found myself in situations were the interviewer wanted to probe my knowledge of good programming style. These typically were centered around basic knowledge of OOP.

I know OOP is useful to encapsulate concepts and I use it daily. However, since a language like C++ allows many different styles and some C++ approaches like TMP or STL algorithms are not OOP at all (but rather more like functional programming) I find myself stuck on how to best "sell" my knowledge of other approaches as well without coming across as arrogant or as somebody without appreciation of the basics. I fear this emphasis on OOP of the askers comes from them being socialized in the 90s where OOP was believed to be the cure-all, but that is an arrogant standpoint to take.

How would I make the best of questions like this?

  • 1
    There are just a few handful concepts of basic OOP. Prepare a ready made code example for each of them and you should clear most of these. And yes an interview is to mostly satisfy the interviewer doubt of your knowledge on the subject and it's the worst occasion to have ideological quandaries.
    – eminemence
    May 7, 2012 at 9:34

3 Answers 3


I would say you have to do your best answering this kind of questions, like you should do your best answering any kind of questions.

Later on when you are given the opportunity to ask the interviewer questions, you should raise the subject, asking questions like:

  • Do you only do OOP?
  • I use a different programming approach, how is it acceptable in your team?

And so on... and this way you can not only start a conversation about selling your expertise with those other approaches, you can also see how rigid and how much emphasis is really given to OOP in that team/company.


Don't worry too much about the asker's motivations, and just answer honestly. Remember, an interview is a two-way street. You don't want to get stuck in an ideologically inflexible company any more than they want to get stuck with you.

That being said, I think you're being a little paranoid about interviewers' intentions. An astounding number of supposedly professional programmers do not understand the fundamentals of OOP. 99% of the time, interviewers aren't trying to see if you drank the OOP kool-aid, but only want to see if you have a basic understanding of it. Even if you feel another paradigm is better suited for a certain solution, interviewers want to know that was an informed conclusion, and not borne of ignorance of OOP.

Rationalization is a very common defense mechanism when someone doesn't understand something. If people don't understand a concept, they argue the concept is stupid or inapplicable rather than admit their own ignorance. Even if you truly think OOP is a poor choice for an answer, you must nevertheless distinguish yourself from the rationalizers. The way to do that is to both explain the OOP solution and why you think it's a poor choice in that situation.

  • 1
    +1 for style questions being more about environmental fit . . . May 7, 2012 at 15:16

I would emphasize that you follow SOLID principle, which is OOP and more. Not only does it guarantee that your code is object oriented, but that it's fashioned in such a way that substituting objects following the SOLID principle is a relatively straightforward task. Not only would it send the message that you know OOP, but it demonstrates that you understand the subtle points about what distinguishes good OOP code from hacky complicated OOP code written by someone who used to program in C and thinks all other languages should be programmed in the same fashion, since lets be honest, that's what makes you a good programmer, not just being able to use OOP.

Be prepared to thoroughly explain for each of the five principles why each is important and what might happen to code which ignores that principle.

Not the answer you're looking for? Browse other questions tagged or ask your own question.