Is OO-programming really as important as hiring companies place it?

Question

I am just finishing my masters degree (in computing) and applying for jobs. I've noticed many companies specifically ask for an understanding of object orientation. Popular interview questions are about inheritance, polymorphism, accessors etc.

Is OO really that crucial? I even had an interview for a programming job in C and half the interview was OO.

In the real world, developing real applications, is object orientation nearly always used? Are key features like polymorphism used A LOT?

I think my question comes from one of my weaknesses. Although I know about OO, I don't seem to be able to incorporate it a great deal into my programs.

Answer 1

OOP is a paradigm that allow your program to grow without becoming impossible to maintain/understand. This is a point that students almost never get because they just do little projects lasting from two weeks period to two months at the most.

This short period is not enough to make objective of OOP clear, especially if people on the project are beginners. But sticking to some modellisation is crucial for big projects, I would say >50,000 lines of code. OOP isn't the only solution to that, but this is the most broadly used in the industry.

This is why people want you to know OOP.

I would add, by exprience, that almost all junior programmers have serious flaw in modellisation and OOP. Most of them know how to write classes, inherit from them and basic stuff like that, but they do not think in "OOP" and end up misusing it. This is why any serious recruiter will always look what your competencies are in the OOP domain.

As these things are not learned at school, there is a simply enormous variation of knowledge between different candidates. And let's be honnest: I don't think someone whih poor knowledge in OOP could work on any big project, simply because it would require more time for lead devs to manage these people than simply writing the code themself.

If you don't think "OOP" yet, I would suggest you to read some books about it and apply in company that does not have really big projects; to get used to OOP keeping doing useful work for your employer (and as long as he/she is giving you your salary, this will be usefull for you too).

EDIT: ha, and I would add that I already wrote OOP code in C, even if it's not the most common usage of C, this is possible with strong knowledge. You just have to build vtables manually.

And behind OOP technique, something is hidden: software design. Software design, is really helpful, in C as in any other languages. Many recruiters will test your software design competencies, and OOP question are good for that, but OOP isn't the main thing that is being tested here. This is why you have those questions even for a C job.

Answer 2

The overwhelming problem with computer programming is handling complexity, and modern programs can be very complex indeed, and this appears only to increase.

Much of the work done in software engineering of non-trivial computer programs concentrates on taming complexity and make it accessible to as many as possible without devoting a lifetime of learning first.

Examples:

• Modularization: You make programs conceptually simpler by having modules of code, where each module only know a little about other modules (instead of e.g. a mouse icon drawing routing being allowed to manipulate network card buffers directly).
• API's: They give a simple usage path to the complex programs behind the API's. When you open a file you do not care that network shares are handled different from an USB-disk. The API is the same.
• Object orientation. This allows you to reuse existing code and make it work transparently with new code you add, while still hiding all the underlying complexity.

In other words, knowing a lot of tricks is necessary if you want to work on non-trivial pieces of software, either alone or (most likely) with others.

Answer 3

Yes, primarily because perhaps the two most popular development platforms used in commercial development (Java and .NET) are object oriented and that means yes, OO is used a lot (including polymorphism, inheritance and everything else).

Companies don't specifically care about object orientation as a technology - this isn't an ideology thing, they care about people who can develop solutions to their problems in ways which align with their IT strategy.

But I wouldn't worry too much about feeling it's a weakness. Without disrespecting your education, most people in the commercial world don't see programmers leaving university (at any level) as the finished article. You've still got a lot left to learn and that's understood (probably better by the companies than the students).

Answer 4

As in real life, the real life programming differs from that in theory.

Yes, if you keep OO paradigm polished and always at the back of your mind, you can do better at writing code that is manageable, understandable and easily extensible.

Unfortunately, the real world has this:

• project time pressures
• procedurally oriented team members
• cross-located teams, multiple vendors
• legacy code not having any orientation whatsoever
• as long as it works, a few care about how code is written
• even if code does not work, motivation is to fix it, not "OO" it
• modules, platform limitations, frameworks which simply don't allow you to do good OO

In a real job, you have to work with above issues. This sounds demoralizing. But, treat this as a heads up. Hiring companies place too much importance on OO while hiring. It's easy to see why. The only way they can test the candidate is asking about the understanding of OO. And unfortunately, many candidates just brush up on those questions before turning up for an interview.

Real-life OO comes slow. It helps if you keep reading and keep improving it over the time.

Answer 5

I had quite the same feeling upon finishing my Bachelor's Degree, and a great book that showed me why and how OOP is relevant for real-world applications is Head First: Design Patterns. I sincerely recommend you take a peek, it's written in a really fun way and makes a lot of valid points of why an OOP-approach is desirable when working with larger scale, constantly-changing systems.

Answer 6

Even for some jobs in C, you might need to know object oriented design (and probably be better at it than if your compiler did it for you), as evidenced by a recent series of articles on object-orientied design in the Linux kernel. (Part 1, Part 2)

GTK+ also uses a lot of object-oriented design patterns.

Answer 7

Jon Hopkins wrote:

Yes, primarily because perhaps the two most popular development platforms used in commercial development (Java and .NET) are object oriented and that means yes, OO is used a lot (including polymorphism, inheritance and everything else).

Which is pretty much what I was going to say, but it's not just Java and .Net, C++ is everywhere, Objective-C is all over OSX, all the cool kids are doing Ruby or Python, and all of these things and many many more have a focus on object orientation. A lot of newer languages are multiparadigm, so something like F# is primarily a functional language, but also supports object orientation. It is everywhere, and having at least some understanding is very useful. Don't fret too much about it though, having just completed university courses means that you're ready to start learning about developing code in the real world :)

Answer 8

I have to express some disagreement with this notion that OO is everything - one could say OO allows you to build cities, but procedural programs are the bricks.

To give my answer in the form of an analogy, a general needs objects, the soldier needs procedural. Once you drill down enough in OO you find procedures, and if that is your expertise and you're good enough, don't worry about OO, cause it's easy enough for somebody to write this OO chess game code:

-findBestMove
-makeBestMove
-waitForPlayerInput

but then somebody has to write the code behind -findBestMove and you can be sure it isn't just this:

foreach $move (@moves){
    $bestMove = ($move > $bestMove ? $move : $bestMove)
}
return $bestMove

On the other hand, if you don't know how to read the OO code, worry. Because you can be sure (almost) that your code will be messing with objects of some sort. Unless you work on the fortran legacy behemoth of 12000 global vars and 1200 line "modules" I currently maintain.

Answer 9

I've done programming for a long time, and I find the concepts of OO are useful even when programming in C -- even though if tested I would probably fail to describe those concepts in every tiny detail. At one point, I even created an OO language, albeit a rudimentary one, to get my head around the concepts and to find enjoyment in OO from a new angle.

BTW, C++ has made a huge and ugly mess of OO, whereas Objective C does it right.

About interviews, they have become a horror show -- from both sides of the table. Most interviewees are very freaked out by them. Most hiring managers are astonished by how many people fail even very basic programming tests.

That said, there are some enormous douche bags working in the software industry right now who know NOTHING and yet expect the world from prospective employees.

Answer 10

Learning OOP is not as useful as learning software development. Go read Code Complete 2.

Sure it's a useful tool but OOP itself is really small. In general when companies and recruiters say "OOP" they mean "Software development". It's being used as a generic term.

Real recruiters will tell the difference between you knowing how to develop software and matching the "Has 3 years in 'OOP'" tickbox.

Answer 11

OOP is not important because of itself, but because of what it takes with it. Something that deals with the capability to abstract and isolate, group things together end expose only the parts that are required to interact together.

This is a common engineering technique called "modularization", that allows to create complex systems as aggregation of simpler ones, without to take care of every single details at high level, and that require components to be replaceable, even without them to be exactly the same.

Those "engineering concepts" have been tried to be kept into the software development from the time software product themselves had become larger than the "single developer capability", thus requiring a way to make developers to work on independent pieces, and let those pieces to interact together.

That said, those principles are not necessarily found only in OOP (it the computation theory is valid, there are infinite possible methods to come to those results).

OOP is simply a successful attempt to put those things together, giving to those general terms (like modules, encapsulation, substitution) more precise definitions and elaborate conceptualization on those definitions (patterns) that can fit into programming languages.

Think to OOP first not as a "language feature" but as a "common lexicon" that makes software engineers approach the software design.

The fact that a given language has or not primitives that directly enforce that lexicon ensuring -for example- that a "capsule" is not opened inadvertently by who is not supposed to do that is a secondary aspect of OOP design. That's why even large C project are often "managed as" OOP, even if the language itself offers no direct support to that.

The advantage of all that is not recognizable until a project size stay into the single developer capability in understanding and track everything he does (in fact, in those situation it may be even seen as "overhead") or into a small group developing something in a short period. And that's the main reason juniors who studied OOP in term of a "language feature" often misinterpret it producing bad designed code.

How OOP fits into languages depends on how language designers interpret the OOP principle in their own construct.

So "encapsulation" in C++ becomes "private members" (and a "capsule" become a class), "substitution" becomes virtual functions override or template parametrization/specialization etc, while in D a capsule is a "module" (and substitution goes through classes etc.), thus making certain paradigm or pattern directly available in a given language and not in another and so on.

What recruiters seek in asking OOP question is just check your capability to abstract and concieve software design for future large projects and development. OOP, for them is just a "dictionary" they supposed both you and them know so that you can talk about other more general things or concretize into a specific implementation.

Answer 12

The answer is yes, as several others have noted.

BUT, if you want to work on piles of non-OO procedural spaghetti code, you can find that out there too. I think you will prefer the OO work.

EDIT: Forgive my case of gunslinger's cynicism and sense of humor. As Raynos said, just because something is OO doesn't mean it's good. Proper application of OO takes real work and thought; just having instances of it does not automatically mean an app is well made. And conversely, I'm sure there's well written procedural code out there. My experience in corporate IT shops through the 90's and 2000's has been that a lot of bad code was written and probably still exists. But closer to the OP's question, I have noticed that the smarter developers are, when given the chance, moving to more OO systems.

Answer 13

OO is a fundamental basis on which other techniques are built. A key point is to first fully understand the difference between a type (class) and an instance of that type. Don't try to read on without fully understanding that (thinking it will become clear later), because you'll have to read the rest all over again once you catch the vision.

Once you get the hang of it, you'll never want to do without it. I'm not a purist when it comes to encapsulation, patterns, frameworks or whatever. On the job, you'll have to adapt to various views and concepts. I'll list some previous job experiences of my own:

At one company, my peers wanted as much as possible lazy-loading (empty constructors, bulky properties that had to check for null values everywhere). They were building web-based server-side objects that lived a short life.

The next job was totally opposite. Objects lived inside a desktop (Excel-based) application. As much initialization as possible should be in the constructor (or one of the many constructor overloads). Empty constructors were not allowed since empty objects had no right of existence (which made persistence quite a challenge). In addition I had to adapt to their "coding style standards" (where to open parenthesis, add whitespace after comments etc...), because my code could not be checked in if it didn't get through style-cop.

Currently I'm working at a company where none of the developers ever tried to understand OO. It's hard to express how extremely frustrating that has been. I've had to improve my Grep skills, in fact I have a HotScripts macro assigned to my F12 key in order to do a grep on the selected text. I'll spare the other frustrations...

Once you obtain OO skills, you'll almost be allergic to spaghetti! However in all cases, OO-or not, be patient and adapt. Be reluctant to "throw it away and start over". Your boss will rather choose you when it comes to throwing out. Unfortunately "making mony" is more important than elegant code.

Sorry for the long answer but I tried to cover most of the scope of your question :-)

Answer 14

It depends. One reason you need to know OO because it's the lingua franca of the programming world. As another answer points out, nearly every major language is OO in some way, which means that basically any company that might hire you is using an OO language. Ever try hiring OCaml programmers? It's impossible; the talent pool is too small. If you started your company using OCaml and your company becomes successful, you won't be able to hire programmers fast enough and you'll go out of business. Therefore nearly every company with more than 3 programmers uses an OO language, and in order to communicate with your coworkers and use your platform's libraries, you'll need to have an understanding of OO.

Depending on the particular language the company is using, inheritance and polymorphism is either extremely important or just moderately relevant. You can't do anything in Java without busting out 10 GoF design patterns and a dependency injection framework. Java is one of the most widely-used languages, therefore OO principles are really important to the many companies using Java.

If the company is using a modern hybrid OO/functional language that has lambdas and function pointers, like Scala or C#, then inheritance suddenly becomes less important because you have higher order functions to handle lots of the really simple things that would otherwise require lots of ceremony. However you still need to be able to work with OO stuff because most libraries you use will be written in an OO way.

If inheritance and polymorphism aren't important to the company, you're still likely to get OO questions because:

• You are interviewed by an HR person who knows nothing about programming and is asking questions off a checklist. Do you have 3 years of X, do you multitask, etc.
• You are interviewed by an engineer who wants to make sure you haven't been living under a rock. OO is the lingua franca, so you'll be asked some cursory questions about it.
• You are interviewed by an engineer who isn't very adept at interviewing. In general, engineers love trivia and complexity, so you will get a lot of questions about polymorphism, inheritance, and GoF design patterns only because these things are interesting to the person interviewing you.

Answer 15

Short answer is Yes

The longer version why you feel or in a dilemma as to why its important is only due to the fact that you haven't worked on any projects or implementations which serve some purpose. Its perfectly valid in classrooms to have examples on Automobile then extended to Car, Trucks... but when you jump into software development its a solution targeted to ease of some tasks. Now if it weren't were for OO we would have everyone writing similar codes across the code base or reinventing wheels everyday. Imagine what a mess it would be if one were to dive into such a codebase to fix something. The classroom examples are for a vague definition or representation of how/why it is done. The real test is out when you start building your app, no doubt as anything it could be terribly used but it far out weighs the sanity due to its clear and concise usage. So better start of working on these weak area least you churn out nightmare codes.

Answer 16

An object oriented language helps you keep an object oriented design in your code, which is good. But it's also true that such a design can be obtained with any other paradigm language: the reason of the popularity (especially among companies) of OO-languages stands probably in the commercial success of java and c#.

Had Mr. Gates started his company the right way, we would probably be studying SCHEME before applying for a job.

Answer 17

In a word "Yes".

You may think you know the theory, but you need to write some code and put it into practise. There are - literally - thousands of examples and exercises available on line.