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.

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

share|improve this question
    
Ask them if they dot their i's. –  Job Nov 24 '10 at 4:57

10 Answers 10

up vote 10 down vote accepted

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.

share|improve this answer
    
i like this method of interview where it is a discussion rather than a Q&A. –  bronzebeard Nov 24 '10 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.

share|improve this answer
    
Could you give me the link :) –  bronzebeard Nov 24 '10 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 Nov 24 '10 at 11:40
    
thank you –  bronzebeard Nov 24 '10 at 11:41

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.

share|improve this answer
    
That's a test of knowing how overloading works in C#, but hardly a test for OOAD design skills. –  user281377 Nov 23 '10 at 9:38
    
Your are perfectly right. I read your question too fast I change it. –  user2567 Nov 23 '10 at 9:44
3  
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 Nov 23 '10 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 Nov 23 '10 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 Nov 24 '10 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.

share|improve this answer

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

share|improve this answer

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?

share|improve this answer

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

share|improve this answer
    
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 –  bronzebeard Nov 24 '10 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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
    
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. –  Ken Henderson Nov 24 '10 at 1:47

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.