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.

This is a question where I seek guidance from fellow/senior developers to get into my dream company - it's a pioneer in OOP and Agile.

I've already failed once to clear an interview. One part I feel most challenging is to come up with a proper Object Oriented design(classes, interfaces, methods, interactions etc.) in a very short time for certain situations like Pacman, Game Of Life and so on. As the problems are unprecedented ones - my approach is mostly to try different things and then make decisions - which they feel is not clear and not what they expect from a developer with 5+ years of experience.

I've already studied a few books on patterns, OOP - it didn't help me much and I think it'll take a bit more than that. Could some one please guide on what specifically shall I practice so that I can do better at design problems as above. I want to refine my approach and have a better thought process.

share|improve this question

migrated from stackoverflow.com Aug 14 '11 at 8:38

This question came from our site for professional and enthusiast programmers.

Side note: drop that 'S', it has no meaning. OOP is enough. –  Péter Török Aug 12 '11 at 15:15
oops.. done :-) –  haps10 Aug 12 '11 at 15:25

7 Answers 7

up vote 13 down vote accepted

There are no resources that will help you come up with a good OO design for an unfamiliar topic in a very short time.

If they're really expecting you to do so, you don't want to work there.

What they're likely looking for is the techniques you use to to get there.

I'd recommend reading up on CRC cards, then practicing breaking the problem down into nouns (sometimes classes) and verbs (sometimes methods), drawing some ad hoc class diagrams, scrawling in some relationship arrows, then throwing it all away and starting over. Don't bother with UML, it'll just make you cry.

Read up on Test Driven Design. If they're really into OO and Agile, they'll expect you to know TDD. Do not mistake TDD for unit testing. TDD is testing to drive design. Any actual unit tests that get created and are worth keeping are a bonus.

Read the works of Ward Cunningham, Kent Beck, and Martin Fowler. Familiarity with those will get you interview credit.

Also be aware that if you get the job, there's a good chance you'll be sent to a client site where good OO design and Agile practices are thrown out the window.

share|improve this answer
+1 for the UML comment and last paragraph. –  Daz Lewis Aug 14 '11 at 17:23
Sometimes the client is in on Agile as a collaborator :) –  Cervo Aug 15 '11 at 2:54

Woah woah waoh. Before you start name-dropping "Design Pattern X" for your Pac-Man test, take a step back.

You first understand the problem. To get started look at the problem and identify things(objects) and their behaviors. It's that simple.

Now that you have identified things and behaviors you can start looking for a pattern. Here is a "Strategy Pattern" example. Consider implementing behaviors as objects themselves. You identified a "chase pac-man" behavior. Make an interface IChase and implement each way of chasing; DirectChase, RandomChase, etc. (each ghost chases a little differently). The object is like a proxy over the method. So it would call like:


instead of the traditional


It's a subtle difference and hard to explain in a post but using a proxy over the direct method gives the ability to easily change behavior at runtime. Maybe there is a power-up that makes all ghosts wander randomly instead of direct chase. You can do this easily with this pseudo code:

for each Ghost: Ghost.ChaseBahavior = new WanderRandomly(); Ghost.ChaseBahavior.chase(pacMan.Location);

share|improve this answer

I recommend reading Domain Driven Design - it deals thoroughly with formulating and successively refining design.

share|improve this answer
the link is available at amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/…. Excellent book if you are lucky to work at a place where you are given enough time/resources to build a domain model. –  Cervo Aug 15 '11 at 2:55

I recommend Object Thinking by David West. It starts out slow with a bunch of arguments about formalism versus object thinking, etc... But the main idea of behavior driven design seems to work for me. I haven't had many job interviews lately, but I totally bombed one on Object Oriented design about 6 months ago. Fast forward about three months and a company invited me to Seattle to interview in person and they had several object oriented design questions in the phone screen. So I'd definitely say behavior driven design is a great idea.

For getting things done quickly, as was mentioned, the CRC cards are a great idea. But the real power of CRC comes from knowing how to do a behavioral design. One other thing, you won't be an expert in it after that book. i can clear object oriented technical interviews, but when I try to apply that knowledge to real projects, I end up with too complicated a design still. Also refactoring and even Domain Driven Design (I highly recommend the book Domain Driven Design by Eric Evans) sometimes break with pure behavior oriented approaches. But it's definitely a step in the right direction.....

i'd recommend you know what a Domain Driven Design is (more popular in Java but some of the best .NET shops are using it as well) and a table module (often .NET shops employ this by making objects represent database tables and passing around record sets). Some places will go all formal UML and approach object design by modeling the data (E/R Modeling like for a database). Others will just say verbs = methods and nouns = classes. So it depends because there are many different approaches. Others procedural program with objects...e.g. throw some methods and data together splitting apart the program as separate namespaces.

Personally I feel behavioral driven design does seem to simplify a lot of things and to split up the control better. E.g. instead of having one super object/method controlling everything, tasks are delegated more. This also ends up easier to debug and reason about.

share|improve this answer

Usually OOP questions in interviews are tough, interviewer doesn't expect you to provide a full working solutions that you can pass for a developer and boom it's working. He wants to understand how do you analyze the problem? The main thing to take care of and bare in your mind is to make your design flexible. As it's an easy words to say but hard to apply, you need to practice a lot. Once I got a question; with one of the largest corporation in the world to design a restaurant reservation system. This was easy, but after that, depending on your design things can be complicated if your design is not flexible to handle changes. He asked me to add lots of features, and I did almost all of them. And I got a very positive feedback out of him. The key thing here is to use design patterns but don't over reuse them. Just remember the intent of each design pattern and with practice, your mind will automatically pick the right pattern in the problem. In OOP questions you should always talk with the interviewer and explain to him your idea and your point of view so he can understand how do you think. Don't just tell him give me 5 min and then draw a bunch of UML boxes and that's it! Also listen carefully to his comments because he may give you hints that help you to solve the problem.

share|improve this answer

I recommend Design Patterns by Erich Gamma et al; The book applies each design pattern on a sample design problem. For me, the best way to understand well and become good at design and OOP is to write sample code of the problem yourself and then referring back to the book to see how the authors approach it.

share|improve this answer

In my very limited experience of interviews, what they want is, in order:

  1. honesty
  2. enthusiasm
  3. ingenuity
  4. knowledge

And as for programming problems, they're more interested in your ability to solve the problem, and possibly evidence that you've experienced the problem before, than a totally correct academic understanding of the problem. Design patterns only really help when you really understand a problem domain very well.

So I would suggest you try writing or maintaining code of the type the job's going to need. Find an open-source project and contribute to it.

And in the interview, be confident, and if they ask you a question about design patterns ask for a concrete example and then just tell them honestly how you would go about achieving the desired result.

share|improve this answer

Your Answer


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.