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 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.

share|improve this question
1  
You should go through groups.csail.mit.edu/mac/classes/6.001/abelson-sussman-lectures so that you will better understand the limitations of OO. –  Job Mar 11 '12 at 5:33
add comment

4 Answers

up vote 10 down vote accepted

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.

share|improve this answer
    
In a job interview, is the duration of the solution's lifetime any longer than "until the interviewer has read the code"? How do you decide that one answer is usefully extensible and another wastefully gold-plated? –  user4051 Aug 29 '12 at 14:11
    
It's a good question Graham. Sometimes I ask candidates to code something up against a spec and use that to decide if they will get an interview. I have had people submit solutions that either a) do what the spec asks and no more and b) do what the spec asks as if it were a full enterprise app of much greater complexity. (technically there's a c category too...) I'll interview people who provide both types and actually play devil's advocate getting them to explain why they chose to do it one way, and how it would change in different circumstances. –  Ian Aug 29 '12 at 22:08
    
I will add though, there's no way to protect yourself from an interviewer who has a set of expectations and is determined to catch you out. I swear some people see it as a contest "I'm interviewing you, do you really think you are better than me???" sort of thing. It's a flawed method and you are probably best off not working for someone like that. Not much help if you need a job now though, but might be small compensation. –  Ian Aug 29 '12 at 22:18
    
I've seen that too :-(. The good thing is you can quickly tell that you don't want to work with those people... –  user4051 Aug 30 '12 at 6:16
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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
share|improve this answer
6  
Most of this list has nothing to do with OOP. –  Gary Willoughby Mar 10 '12 at 17:16
    
Could you elaborate on "Hide Connection Strings"? –  Job Mar 10 '12 at 19:26
1  
"Attempt to create a good GUI" Don't we all attempt to create good everything? –  JeffO Mar 10 '12 at 21:01
1  
It probably does but it doesn't address the question asked. –  Gary Willoughby Mar 11 '12 at 0:07
1  
-1: I agree with @Gary Willoughby. This is a decent list of best practices, but it doesn't address the question. –  Jim G. Mar 11 '12 at 4:02
show 2 more comments

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.