Videos
Hi all,
I’m currently preparing for Object-Oriented Design (OOD) interviews and would appreciate recommendations on the best resources. I’m aiming to strengthen my understanding of key OOD principles and concepts, as well as improve my problem-solving strategies.
Specifically, I’m interested in:
-
Core OOD principles (e.g., SOLID)
-
Commonly asked design patterns
-
System design and architecture interview questions
-
Hands-on exercises or platforms for practicing
-
YouTube resources
What books, online courses, or websites have you found most helpful for OOD interview preparation? Any tips or insights to ensure I’m fully prepared would be much appreciated!
Thanks so much!
To some degree, yes. Anyone can recite syntax or copy/paste their way through a solution. We want to hire people who can solve problems.
They expect you to document the design sufficiently that they can understand it (and no more than that).
I ask people how they would solve XYZ problem, yes. Usually they just describe it verbally. I want to see if they ask questions to clarify requirements. I want to see how they communicate with other programmers. I want to see if they can think on their feet.
It has been helpful for me. I don't want code monkeys, I want software engineers.
I find these questions rather silly. The true answer is "what are the use cases?" Without a use case, there is no need for any design. For example, here is a perfectly reasonable answer to the parking lot question:
class ParkingLot {
boolean isFull();
void carEntered();
void carExited();
}
It satisfies one obvious use case.
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.
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.
Well, here's one good one that I came up with - utilizing OOP overriding, subclass and superclass:
namespace Animals{
// base class Animal
class Animal{
public void eat(Food f){
}
}
class Carnivore extends Animal{
public void eat(Meat f){
}
}
class Herbivore extends Animal{
public void eat(Plant f){
}
}
class Omnivore extends Animal{
public void eat(Food f){
}
}
}
namespace Food{
// base class Food
class Food{
}
class Meat extends Food{
}
class Plant extends Food{
}
}
I create subclasses Herbivore, Carnivore and Omnivore from the superclass Animal and override the eat method with the type of food that it can actually eat.
So:
Plant grass = new Plant();
Herbivore deer = new Herbivore();
deer.eat(grass); // ok
Plant grass2 = new Plant();
Carnivore tiger = new Carnivore();
tiger.eat(grass2); // not ok.
Meat deer2 = new Meat();
tiger.eat(deer2); // ok
Well, the final problem is that, when you specify that deer is a Herbivore, you can't make it a Meat for tiger to eat. However at the end of the day, this should be sufficient for solving the interview problem whilst not putting the interviewer to sleep.
There's a wonderful poster for the Liskov Substitution Principle that says, "If it looks like a duck, quacks like a duck, but needs batteries, you've probably got the wrong abstraction." And that's the quick answer - some of the objects can be both animals and food, so unless you're willing to go the route of multiple inheritance, then the classification schema is all wrong.
Once you've cleared that hurdle, the rest is open-ended, and you can bring in other design principles. For instance, you could add an IEdible interface that allows objects to be consumed. You might go aspect-oriented, and add decorators for carnivore and herbivore, and that would allow consumption of only the right class of objects.
The point is to be able to think on your feet, to see and explain various aspects of a problem, and to communicate well. And perhaps not to get stuck on a "one right answer" limitation.