(Some background: I’ve interviewed hundreds of candidates for software engineering jobs at Facebook and Microsoft. I’ve also failed several coding interviews myself when I wasn’t prepared.)
Object-Oriented Design (OOD) skills are a major plus for software engineers. They give interviewers an idea about the following:
- Whether the candidate can translate a complex problem into a concrete set of objects and identify interactions among those objects to solve the problem at hand.
- Whether the candidate can identify patterns while designing and, wherever applicable, effectively apply time-tested solutions instead of re-inventing the wheel.
If you are looking for a complete course on Object-Oriented design for interviews, please take a look at following resources:
Object-Oriented Design Interviews are essential if you want to succeed as a software engineer, but plenty of engineers dread OOD interview questions (including myself when I was interviewing!). There are a few main reasons for this:
- They can get very abstract, very quickly. OOD problems require the ability to “zoom out” of a problem and really think about the component parts on a high level (but not too abstract).
- There isn’t usually just one correct answer to a given question. Problems can be thought about or solved in a multitude of different ways.
- Many beginner developers haven’t yet had a chance to design a complex system from scratch.
- Object-Oriented design is usually taught in colleges in a way that makes it look like a boring theoretical course, because you can’t appreciate the value of such a design until the system is really complex — and it’s difficult to keep track of all the objects and interactions in your head.
The good news is that at Educative, we’ve talked to hundreds of candidates, and our authors have teamed up with hiring managers at top tech companies like Google, Amazon, Microsoft, and Facebook to tackle common interview problems in detail.
In addition to covering some of the most popular OOD interview questions these companies are likely to ask, I’ll touch on what the general approach should be to solving such problems, so you can apply your skills to other questions as well.
The approach to OOD interview questions:
In Object Oriented Design questions, interviewers are looking for your understanding of the nuances of complex problems and your ability to transform the requirements into comprehensible Classes.
In fact, OOD questions generally will all follow a very similar pattern. You will be provided with a vague problem and a set of constraints for a system to design, and very little else. It is then up to you, the candidate, to figure out the “level” of solution that the interviewer is looking for, what kind of functionality will be needed, and come up with a workable solution.
Interviewers are looking for one main thing: finding the right balance between a solution that works immediately and is also adaptable to change in the future.
To simplify things, you can take the following approach for any OOD question you encounter:
- Clarify the requirements: Make sure you understand the expectations of the interviewer. Ask clarifying questions if at all necessary — the interviewer will not mind, and will likely appreciate it. For example, “are you looking for me to demonstrate the structure of a solution, or to fully implement it?” Doing this here will take about 5–10 seconds, but save tremendous amounts of time later.
- Hash out the primary use cases: Think about, and then talk through, use cases. Make sure you understand all the different functionality your system is expected to have. Talking about it out loud can also help you to come across expectations or ideas you might not have realized if you just jumped right in.
- Identify key Objects: Now, identify all the objects that will play a role in your solution. For example, if you’re designing a parking lot, these will be things like vehicles, parking spots, parking garages, entrances, exits, garage operators, etc.
- Identify Operations supported by Objects: Work out all the behaviors you’d expect each object that you identified in the previous step to have. For example, a car should be able to move, park in a given spot, and hold a license plate. A parking spot should be able to accommodate a two-wheeled vehicle or a four-wheeled vehicle — and so on.
- Identify Interactions between Objects: Map out the relationships between the different objects that will need to interface with each other. This is where it all comes together. For example, a car should be able to park in a parking spot. Parking garages should be able to fit multiple parking spots, and so on.