what kind of insights or questions would lead you to determine a person's OOAD skills.

  • Ask them if they dot their i's.
    – Job
    Commented Nov 24, 2010 at 4:57

10 Answers 10


You could show some half-assed OO design of a simple problem, and discuss what it does, what's good and bad about it, whether it's flexible enough, what could be improved, and how.

If you need to get the discussion going, ask what the person thinks about some aspect of the code, but not with a leading question.

Important is to remember that the discussion is important, not that you knew the answers beforehand. Any decent developer should be able to point out something about the code that you didn't even think of before.

  • i like this method of interview where it is a discussion rather than a Q&A. Commented Nov 24, 2010 at 11:29

Discuss an open ended design problem with the person. See how s/he proceeds to build a model of the system, what kind of questions are asked, how the design changes in response to new information.

A great example - mentioned by Steve Yegge in one of his blog posts - is to ask the person to come up with an object model for XML.

  • Could you give me the link :) Commented Nov 24, 2010 at 11:33
  • 1
    @bronzebeard - Here you go - sites.google.com/site/steveyegge2/… . He actually talks about OO modelling HTML - but I think XML can be a tougher version of the that question :)
    – talonx
    Commented Nov 24, 2010 at 11:40

Having a good knowledge of all the most popular design patterns can prove the candidate actually searched for solutions to his design problems.

Being able to discuss them and know when to apply them or not is a good indication that he understands them.

Asking him for example usages in his past experiences may also helps.

  • That's a test of knowing how overloading works in C#, but hardly a test for OOAD design skills.
    – user281377
    Commented Nov 23, 2010 at 9:38
  • Your are perfectly right. I read your question too fast I change it.
    – user2567
    Commented Nov 23, 2010 at 9:44
  • 4
    However, you can have a knowledge of design patterns and never have heard of the concept. I had been using things like chain of responsibility, observers, and controllers long before I knew that they had names. Be careful not to assume that because someone doesn't know the name of a pattern he can't use it competently.
    – Michael K
    Commented Nov 23, 2010 at 13:22
  • @Michael: yes that's certainly why it's better to first ask how to solve a certain problem, then talk about the actual name of the pattern. I know many people using the strategy pattern everyday and that don't know it is called like that. They just "created" it by just thinking, like the original group of four did. The difference is that the latter wrote a book on the subject.
    – user2567
    Commented Nov 23, 2010 at 13:36
  • Note, the Gang of Four got the patterns from seeing OO code used in other projects. They by no means take credit for any of the designs, only in recognizing them and describing them in a consistent way.
    – Macneil
    Commented Nov 24, 2010 at 3:17

Don't give a vocabulary quiz. "Define Inheritance" or "name 3 features of OO design" are questions that won't tell you anything about the skills of the individual, only how long since he/she last read a textbook. I've met several great programmers who use these skills every day, but would choke if asked to give the formal definition.


Will ask him to write down the business objects, classes, and interfaces/methods for a room or any other virtual entity


If possible, ask for sample code.

Otherwise, find some procedural code to use as an example (or some poorly designed OO code), and then ask them how they would redesign, generalize and improve it. Be sure the program has extra context, so that the redesign can be meaningful.

Ultimately what you are testing-- design-- is subjective. Thus, your evaluation should be open-ended to allow for several possible good solutions, and not just a single one. Then, think about possible changes to requirements that would force an interface change: How do they handle it?


Read the book Head First Design Patterns. All the examples in the book start with an Object Oriented problem and than end up in the Design pattern. They also tell why certain OOP's concepts will achieve limitted results and why certain are better than others.

Even though a Design Pattern book this book is full of OOP's problems :-)

  • I donno about this, cause all the examples in the book are specifically towards one Design Pattern or the other. If you have just enough theoretical knowledge you would be able to figure it out and that doesn't reflect pragmatic application Commented Nov 24, 2010 at 11:32

Start off simple: what's OOP all about?

You could start off by asking about the basic premises of OOP: abstraction, polymorphism, inheritance and encapsulation. Good food for thought to get them warmed up.

Give them a problem

Next, present them with a problem that is likely to involve patterns. It's not necessary to name or use patterns, but their approach will likely yield some if they've got experience in the area.

Perhaps dynamic text input validation. You'd like to be able to validate the input character by character to see if it's a valid date, time or date and time in ISO8601 format. You get a copy of the input string each time a key is pressed and you can return a boolean to indicate if the text remains good in at least one of the formats. Ask them to talk through and sketch out a design using OO design principles.

By the time you've finished chatting about

  1. Controller (that thing that fires the change events and evaluates the responses),
  2. Observer (the validators respond to the change events),
  3. Strategy (each validator represents a different way of determining if the input is valid),

then you'll have a pretty good idea if they understand OOD.

Give them the same problem again, but this time ask for a different design

Now, ask them to redesign the system without using an Observer pattern (if they mentioned it) - they may choose to go for a Chain of Responsibility approach or perhaps a Command pattern. You don't really care which, you know that they have a reasonable grasp of the principles involved.

Even if they don't go for a pattern based approach, just listening to the way they attempt to break the problem down into its related functionality will yield the results you're after.


I tend to pick a real world scenario, something well known to anyone† and ask them to identify the entities; the actors involved; what interactions there are between them; where common features could be abstracted; what properties need be considered.

Yes, you could ask them to sit down and draw UML, yes you could ask them searching questions on some OOP implementation specifics to see if they can "hit the ground running".

But what an employer really needs within their team is a mind that understands the concepts involved and can apply them to whatever turns up. Specifics can be learnt quickly, when concepts are embedded.

† Deep familiarity and an absence of a connection with code help: A family's use of a bathroom in the morning; cooking dinner; a bus route to work; the assembly of a car.


Something that seems to work rather well, and actually only takes a few seconds: ask them to design an object model. It doesn't matter for what. It can be absolutely trivial. In fact, it probably should be trivial, to not drag out the test unnecessarily.

If the first thing they write is an object, they are already ahead of 99% of their peers in their understanding of OO. If the first thing they write is a class, kindly ask them to go out and send the next candidate in, and contemplate about why it's called OOP and not COP.

  • While I understand what you mean I think I might be a bit careful about taking this to literally. When I'm 'free thinking' design solutions I tend to use UML class notations even if that isn't what I really mean by my diagramming. Commented Nov 24, 2010 at 1:47

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