How would you evaluate object oriented design skills? [closed]

Question

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

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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

Answer 6

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?

Answer 7

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 :-)

Answer 8

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.

Answer 9

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.

Answer 10

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.