While I am studying for job interview, I got this kind of OOD questions a lot. But from my TDD perspective, I think it would be reasonable to ask more about use-cases of (or requirements for) the Car. Otherwise, there are tons of way of designing car. Am I missing something here? How would you handle this sort of interview questions?

  • Yes, it would be reasonable to ask more about use-cases. Because we are designing (or object orient-ing) the car for customers, and it has to adhere to their requirements. I would start asking from the outside and then get into the inner stuff. Mostly, just getting a bit of context can narrow down your choices, and then you can get on with one of them.
    – KK.
    Oct 9, 2011 at 12:10

3 Answers 3


I'm a little confused about your question. Why can't you ask questions about use-cases to try to understand the requirements? If you're asked in an interview to design a car in an object oriented manner, it would be bad not to ask about details.

The point of a question like this is to make sure you understand object oriented design. I understand that if you're just studying from a book, you can't ask questions about use cases. In this case, you should map out which questions would be useful to ask, and then practice designing a car class in an object oriented way. Maybe show them that you understand inheritance ("car" could derive from "vehicle", so that vehicle encompasses motorcycles, cars, etc.)


I don't know if the following is going to make any sense, but here goes ...

A car, in a way, could be said to be OODed. Let's start from the designers - the drawing guys, they dream up the overall design. Then it gets to the engineers, who calculate the dimensions of the suspension, the shafts, the engine, the wheels, the rear view mirror ... Since many people work on the design of one model of a car, many people develop 3d models of its parts.

Therefore, a tire-guy can do whatever he wants with the tire, as long as it fits the diameter of the shaft which is passed to him from the shaft-guy. You might think of that part as inheritance.

The shaft guy doesn't at that time know how he's gonna do the shaft. He just knows it's gotta fit to the engine at one side, and it's gotta be round at the other side to fit the tire. Interface.

The shaft guy gets the diameter from the engine guy. He can do whatever he wants with the shaft as long as it fits the diameter. He can make it a half shaft, a full shaft ... information hiding. How the shaft is really interests neither the engine guy nor the tire guy.

Polymorphism can be illustrated on the engine and its subparts.


if it's an OOD question about designing a car, they're curious about your OO modeling skills - so tell them to model every part of the car that is necessary for the desired functionality.

if it's a racing simulation, it may be the body, engine, tires, and driver

if it's a manufacturing facility, it may be everything!

once they give you a context, then show off your TDD skills by asking about stories and tests (features and use-cases)

  • 1
    +1 Context is key. The number of times this has happened to me - Client asks me to build x. I ask why they want x, and they say they need x to solve problem y. But problem y isn't solved by x, or is better solved by z, so I give them z. Oct 9, 2011 at 14:23

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