Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
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 '12 at 9:34
add comment

3 Answers

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.

share|improve this answer
add comment

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.

share|improve this answer
1  
+1 for style questions being more about environmental fit . . . –  Wyatt Barnett May 7 '12 at 15:16
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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