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.

I'm an Object Oriented Programming fanatic. I have always believed in modelling solutions in terms of objects. It is something that comes to me naturally. I work with a services start up that essentially works on application development using OOP languages. So I tend to test understanding of OOP in the candidate being interviewed.

To my shock, I found very very few developers who really understood OOP. Most candidates brainlessly spit out definitions they mugged up from some academic book on object oriented programming but they don't know squat about what they are saying. Needless to say I reject these candidates. However, over the course of time, I ended up rejecting almost 98% of the candidates. Now this gets me thinking if I'm being over critical about their OOP skills. I still believe OOP is fundamental and every programmer MUST GET it. Language knowledge and experience is secondary.

Do you think I'm being over critical or do I just get to interview bad programmers unfortunately?

EDIT:

I usually interview programmers with 2 to 5 years of experience. The position that I usually interview for is Ruby/Ruby on Rails application developer.

share|improve this question
1  
Why don't you rephrase this question as an example of what you would look for or would reject a candidate based on? That might help developers here let you know if you are being overly critical. –  NickC Nov 24 '10 at 6:05
1  
I don't agree, at all, with language knowledge and experience being secondary. I have a difficult time finding programmers who understand the difference between big / little endian systems, much left bit shifting, much less all of the operands that any given language offers, much less (I could go on, and on, and on). How is a comprehension of OOP concepts going to help a programmer who can't program? –  Tim Post Nov 24 '10 at 7:34
    
@Tim if you're interviewing systems programmers of C programmers, I would agree. If you're looking for someone to create CRUD applications for mundane business tasks... not so much! –  Steven A. Lowe Nov 24 '10 at 9:02
    
The problem is a lot of shops work with the start up just get it done now mentality. Basically you make some giant methods, throw in the if statements/etc. and end up with a mess, but you get it done. You may have to rewrite tomorrow but they don't care. I call this the "start up" type mentality. Unfortunately I think to do object oriented design professionally you need the right shop. Sadly the "right" shops seem to be rejecting me due to not having object oriented design knowledge... So you'll keep getting candidates like me...sorry. –  Cervo May 7 '11 at 21:28
2  
Also schools do not teach object oriented design mostly. They talk about ADT's and encapsulations. But not design patterns, refactoring, etc.. While I know what abstract classes, interfaces, virtual/abstract methods/etc., encapsulation, etc. are. I don't really know how to use all those tools to make good object oriented designs. Schools don't teach this. And many employers do not teach it or have good example code to learn from. I have read books on design patterns/oo design but it's not the same as 40+ hours per week of hands on experience doing it..... –  Cervo May 7 '11 at 21:31

8 Answers 8

haven't you imagined that OOP might not be the pinnacle of all knowledge? there are other ways to think, after all. Even more, there are lots problems out there where OOP isn't the best answer.

share|improve this answer
    
True but as I mentioned we work with only object oriented programming languages (Ruby, Java). Candidates applying for the job of a programmer are supposed to have experience with OOP because thats what they have been doing when they built applications in the past. –  Chirantan Nov 24 '10 at 5:43

OOP is merely one way of coding. There are many Multi Paradigm Programming Languages that does not necessary need OOP to work. In fact, you also need to see what nature of the job is. For example, System Analysts that do little programming can not know OOP, but do well in his/her job.

On the other hand, there's proof (read it somewhere, can't remember where - probably on Stack Overflow blog or Joel on Software) that there are many graduates or freshmen in the industry that hardly know OOP or good programming practices. These people are probably the black sheeps in your team who will code poorly, have bad documentation and poor understanding of the code.

share|improve this answer

Who are you interviewing?

If the answer is fresh out of schools grad, then that's expected. In school a student gets to learn a lot of theory about OOP and the accompanying assignments are hardly long enough to make them understand the advantages of using OOP vs Procedural.

share|improve this answer
2  
Generally college doesn't teach design patterns, refactoring, software design. Mainly just the concepts encapsulation, inheritance, abstract classes/interfaces/etc. and not really how to use all that to make a good design. In fact a lot of shops focus on just getting it "done" as well. I didn't even hear about design patterns until 5 years after school and I had to go read my own books on them. The same goes for refactoring. Only one of my employers uses these things (and sadly I was a DBA there not a developer)...so I still would fail at an OO interview.. –  Cervo May 7 '11 at 21:35

I would like to answer the EDIT section of your question

I usually interview programmers with 2 to 5 years of experience.

If an interviewee has 2 to 5 year experience, OOP fundamentals is something that is expected and I don't think you are being over critical but just having a reasonable expectation.

share|improve this answer

Disclaimer: I'm not a big fan of this test. But I must agree that failing it is a pretty good indication we don't know OO enough to state on our resume that we know OO.

A small exercice that requires just few minutes to complete for someone that know OO.

The question is: "What is the output on the following code?"

using System;

namespace Polymorphism
{
    class Animal
    {
        public void MakeSound() { Console.WriteLine("bip"); }
        public virtual void MakeSound2() { Console.WriteLine("bip"); }
        public void MakeSound3() { Console.WriteLine("bip"); }
    }

    class Dog : Animal
    {
        public void MakeSound() { Console.WriteLine("woof"); }
        public override void MakeSound2() { Console.WriteLine("woof"); }
        public new void MakeSound3() { Console.WriteLine("woof"); }
    }

    class Test
    {
        static void Main(string[] args)
        {
            Animal animal;
            Dog dog;

            animal = new Animal();
            dog = new Dog();
            animal.MakeSound();
            dog.MakeSound(); 

            animal = new Dog();
            animal.MakeSound();

            animal = new Animal();
            dog = new Dog();
            animal.MakeSound2();
            dog.MakeSound2();

            animal = new Dog();
            animal.MakeSound2();

            animal = new Animal();
            dog = new Dog();
            animal.MakeSound3();
            dog.MakeSound3();

            animal = new Dog();
            animal.MakeSound3();

            Console.ReadKey();
        }
    }
}

Oh and if you are a real a***ole, you can add this just before the Console.ReadKey(); statement:

    dog = new Animal();
    dog.MakeSound3();

And if being an a***ole is not enough, add this:

    dog = (Dog)new Animal();
    dog.MakeSound3();
share|improve this answer
4  
I'd say that this only tests your knowledge of OOP as implemented in C#. I know I know enough OOP to put it on my resume, but without knowing C#, I have no idea how public new void X is different from public void X or if dog = new Animal() is valid (I'm guessing not). –  AShelly Nov 24 '10 at 22:16
5  
-1. This tests exactly one thing: whether or not the candidate has memorized the C# language specification. It doesn't even test whether the candidate has actually understood the C# language specification, and it certainly doesn't test knowledge of OO. For example: it relies heavily on classes. Classes don't have anything to with OO, in fact, many OO languages don't even have classes. –  Jörg W Mittag Nov 25 '10 at 21:55
    
+1 A good test that explores the understanding of inheritance. I know no C# at all, but I can tell the questioner the answer for C++ and for Java, and I know what questions to ask about C# to find out the answer for that in about five minutes. –  DJClayworth Oct 20 '11 at 19:55
    
+1 Good test question. bip, woof, woof, bip, woof, woof, bip, woof, woof, –  Karthik Sreenivasan Feb 1 '12 at 4:56
  • It's important to find out what other skills the interviewee has to offer
  • By working in a large software development team I have learned more in three months then I have learned in 2 years at a smaller company. I think experience should be measured in successful projects, rather than years.
  • Reasonable university graduates are likely to answer the majority of your OO related questions, but they are likely to have no or very little industrial experience to offer.

Because of these points, I think that you may be overcritical with your interviewees.

share|improve this answer

If you interviewed a fresh graduate, than you absolutely too critical.

I think what is important for a fresh graduate related to OOP are: medium - deep OOP knowledge, interest in programming and OOP, hard worker and some OOP college assignment. Some fresh graduates are lack of OOP experience in medium - large project. So I think a medium knowledge and interest in OOP will be enough.

share|improve this answer

Out of all the interview questions you've read about out there, I'm pretty sure that only a few were an actual OO problem and in their case it was probably a simple matter of proving facts about OOP.

Call it a personal sentiment, but the developers out there that are more concerned with software design probably feel disappointed that they'll never have to take an abstract specification and refine it into a solution of objects communicating with the notion of satisfying the specification requirements.

For most of the candidates out there, they'll be abusing to what the interviewing system has been reduced to and will generally focus on preparing data structure and algorithm implementations.

share|improve this answer

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.