What are the most important OO skills to show off in the job hunt?

Question

I am in the market for new employment, and found a position were they asked me to create a programming sample based off an assignment. I blew the sample trying to get it done quickly one night, and got declined - only to be given a second chance recently.

The concern was that I didn't really demonstrate object oriented knowledge. I've rethought my approach but I figure it's worth asking: if you were hiring someone for an OO position, what skills would you most want to see them demonstrate they had a firm grasp on?

I want to be sure that I'm missing anything important this time around.

Answer 1

When I interview people I'm looking for people who will produce solutions that will be extensible and maintainable for the duration of its life time. How that maps to OO ties into the questions I ask when I interview.

I start with language questions. Are you familiar with all the constructs and subtleties of the language (C# primarily). If you pass that we move on to patterns.

It might seem like an odd choice to go to patterns before OO principles, but it gives me a chance to poke around in their experience around different areas. UI patterns, enterprise patterns, GoF patterns, etc. This will include some OO priniples as you can describe some, if not most as patterns. SOLID is important to me, D is dependency injection principle, that's a pattern. so its a nice segway to...

How to structure applications for maintainability, extensibility and testability. It's quite an open discussion, I know what I'm looking for and steer the discussion. I don't believe legacy code should become a millstone around the neck, so I want to know how you structure code in a way that makes that true.

Most importantly is that throughout I don't just ask HOW, I ask WHY. Why is a much under used question in interviews I find.

Answer 2

The ones that elegantly solve the problem they pose in the interview.

They don't care about your OO skills (well, they do care some). What they do care about is that you can solve their problems. If you've been putting in 105 hour work weeks, you should already know OO anyway.

The problem is not parsing out which OO skills they want to see, it's being disciplined enough to show them the kind of solutions they need (whatever that looks like).

In other words, don't show them inheritance if the programming sample they asked for doesn't require it.

Answer 3

Let me add few of my favorite OOP questions.

Usually, I start with simple question, and move on from there depending on the ability of the candidate.

Like someone told, most important questions are HOW and WHY and I choose the below topics to ask these!

1.How to choose between Abstract Class and Interfaces

Start with the difference, then ask the Qs in a design situation which one will you use?. The objective is to check the knowledge about the proper usage about the both.

2.How to choose between inheritance and Composition?

Here the candidate should be able to distinguish the has-a, is-a relationships. And should be able to choose the proper one in the given situation.

3.Can you be the compiler and JRE

I have this simple code snippet;

class A {

}

class B extends A {

}

From the above I start with the below code,

A a = new B();
B b = new A();

There are lots of questions here like which of them will compile? WHY? WHY NOT? What we can do to make it compile what will happen at run-time.

Then in the same example, add methods in both classes and you can move on to the method overriding and overloading etc..

As I told in the beginning these are only titles, you can go deeper in all these topics.

Answer 4

I guess some of the few things you need to demonstrate are:

• Understand the problem
• Good class design
• Use proper class modifiers, prefer information hiding
• Use features like inheritance, abstract classes, interfaces correctly if possible
• Prefer Generics over untyped lists
• Use exception handling
• Create a good (and simple) architecture of at least 2 tiers
• Use Constants instead of properties with literal values when applicable
• Arrange your code well in namespaces and folders
• Use good naming standards
• Be sensible about your usage of static types
• Code security
• Validate inputs
• Hide connection strings
• Provide, if possible, configuration options
• Provide help functionality even if not fully implemented in this version
• Prepare a document for requirements, architecture, class diagram, and other documentation as much as possible
• Include exceptions for not coded methods if any (in case you don't have time for them)
• Design your database well
• Attempt to create a good GUI