Design interview guide: Low-level OOD to Advanced System Design

This article was written by Educative's Co-founder and CEO, Fahim ul Haq.

Visualize designing an intricate distributed relational database system such as Google Cloud Spanner. Now consider doing this while under pressure from an interviewer. What if you were asked to design a specific module or component within that architecture, like a load balancer or cache?

These scenarios are possible during one portion of the modern technical interview loop: the design interview. You can use these interviews to send hireable signals and stand out in a competitive field, but they can be challenging to prepare for if you don't know the format.

Understanding the different types of design interviews, whether they focus on low-level implementation details or more advanced System Design concepts, can give you the best chance of providing an answer that gets you hired.

Unlike coding interviews, technical design interviews require thinking in broader, systemic terms. For these interviews, you must learn to weigh different tradeoffs between possible solutions and then provide justifications for the solutions you choose.

But, as I mentioned earlier, the type of design interviews out there can vary, and each will have its own set of expectations and standards for what constitutes an ideal or complete solution. The type of design interview you perform will depend mostly on the size of the company, the role you're applying for, and your current experience level. Later on, I'll clarify what particular roles and companies are most likely to conduct certain types of interviews.

So, for today, I'd like to walk you through two types of design interviews that exist at the opposite ends of the spectrum: Low-Level Object-Oriented Design (OOD) and Advanced System Design (ASD).

We'll cover what interviewers are looking for in OOD and ASD interviews, key differences between the types to help you prepare for the right one, and my best advice for your preparations for both.

Low-Level Object-Oriented Design (OOD) vs. Advanced System Design (ASD)

System Design interviews have been a part of the technical interviewing process for a relatively shorter period than low-level design interviews. In the software industry, it was always important for engineers to demonstrate the ability to design efficient and effective software at a granular level. System Design only caught on once complex distributed systems became more commonplace in the 2010s.

The greater complexity of these systems meant we needed highly scalable and reliable architectures and, consequently, people who could design them. Now, System Design is a cornerstone of modern software development.

At the same time, the Low-Level OOD interview remains one of the most common types of design interviews you'll encounter during tech interviews. Coming into these interviews with a solid grasp of object-oriented design patterns will put you at a massive advantage.

"All well-structured object-oriented architectures are full of patterns."
Grady Booch
Chief Scientist, Rational Software Corporation

Here, the focus is on the implementation details of a specific module or component within a more extensive system. More specifically, it's focused on the details of individual classes and objects within that software system and their relationships, methods, and properties. Your interviewers are going to determine how well you can design an efficient implementation that satisfies all of the functional requirements.

System Design interviews, on the other hand, take a broader look at the big picture. Here, your concerns are with an entire system's overall architecture and design. Your interviewers expect you to develop a robust, high-level architecture that meets functional and non-functional requirements alike. You may need to consider properties like scalability, availability, and security in your decision-making process.

Advanced System Design (ASD) interviews test your understanding of the principles of System Design through a more rigorous lens. These interviews often hold your solutions to far more exacting standards, as the interviewers will expect you to use more sophisticated techniques and methodologies that are often seen in enterprise-level applications. At this level, your designs must provide elegant, efficient solutions that reflect practical experience with real-world system design and implementation. While non-functional requirements like scalability are important to consider in System Design, they often become essential in ASD, being treated as existing properties of a complex, large-scale system to be optimized and improved.

Returning to Google Cloud Spanner, this system represents the type of case study that could turn up in an Advanced System Design interview. A globally distributed relational database system designed to provide strong consistency, high availability, and horizontal scalability, Google Cloud Spanner showcases the system complexity that an interviewer could challenge you with at this level.

At the same time, Spanner could also be used effectively within low-level design interviews to assess a candidate's understanding of the underlying architecture of a distributed system, and how more specific components like databases and caches might interact.

Quick Differences: ASD vs Low-Level OOD

To review, here are some major differences between the interviews to remember.

Advanced System Design

• Focuses on the overall architecture of a system.

• Concerned with designing a scalable, performant, and fault-tolerant system.

• Requires a deep understanding of distributed systems, and system design principles.

• Encompasses large-scale, complex systems with many components and stakeholders involved.

Low-Level OOD

• Focuses on designing individual classes, objects, and their relationships.

• Deals with solving problems related to implementation and programming.

• Requires a deep understanding of object-oriented programming concepts and design principles.

• Is applied to components within larger systems.

Now that we've covered the key differences, let's look at how you can determine the style of design interview you should expect.

Who needs to know ASD vs OOD?

The style of design interview you will receive depends on a number of factors. Here is a quick overview of when you might encounter each type.

Advanced System Design

• More frequently used when interviewing for senior software engineer and engineering leadership roles.

• Interviewers expect candidates to be aware of major examples of current and older distributed systems.

• Interviewees will need to know how to pick and combine the building blocks of a modern system's design.

• Discussions will revolve around system architecture and high-level features like scalability or fault tolerance.

Low-Level Object-Oriented Design

• More dependent on the role and company you're applying for. For example, the mobile application team at Spotify would focus on OOD questions because they want to know how well you can optimize single processes.

• Interview questions focus on creating classes and objects, as well as defining their attributes and behavior at the component level. You can expect to encounter coding exercises and algorithmic questions at this level.

Unless you're set on a particular role, preparing for both extremes of the design interview is the wisest course of action. In that spirit, let's look more closely at each type of interview and my best advice for succeeding in them.

Low-Level OOD: Leverage design patterns to build components

Now, we will start with the lowest level of the design interview, the Low-Level OOD interview. As defined earlier, OOD involves implementing specific modules or components and their classes within a more extensive system, such as Google's Chrome browser.

When I first started interviewing for software engineer positions, Low-Level OOD interviews were the only type of design interview you'd find yourself in. System Design and scalable systems weren't as integral as they are today because large-scale distributed systems were relatively uncommon.

We can think of OOD similarly to building a Formula 1 race car. If the entire car is a distributed system, then the engine's design would be considered a low-level process within that system.

The OOD interview will primarily measure two things:

• Can you design a component that successfully interacts with other components in the system?
• Can you use design patterns to create this component efficiently?

Understanding the various design patterns of OOD should be a primary focus of your preparation for the low-level design interview.

“Design Patterns: Elements of Reusable Object-Oriented Software” (1994) by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, collectively known as the "Gang of Four," is considered a seminal work in the field of object-oriented design. It was instrumental in popularizing the use of design patterns at a time when object-oriented design was reaching new heights of popularity.

This book highlighted 23 fundamental design patterns of OOD organized into three categories: creational, structural, and behavioral patterns.

• Creational patterns deal with the process of object creation and are used to abstract the process of object creation.

  • Structural patterns deal with class and object composition. These patterns provide ways to organize or combine classes and objects to form larger structures.
  • Behavioral patterns focus more on object interaction and how objects communicate with each other. These patterns deal with how responsibilities are delegated across different objects.

Each category represents a set of design patterns meant to solve a specific type of object-oriented design problem. By using these patterns, developers can significantly improve their software's coherence, modularity, and maintainability.

Of the 23 design patterns, these are the most frequently used in technical design interviews:

• Singleton: Restricts the instantiation of a class to a single object.

• Factory: Doesn't require the use of a constructor to create objects (aka, the new keyword).

• Constructor: Uses the constructors present in the class to create specific types of objects.

• Iterator: Iterates a collection of objects without exposing the underlying form.

• Facade: Simplifies a client’s interaction with the system by hiding the underlying complex code.

• Adaptor: Allows an object to cooperate with a class that has an incompatible interface.

• Visitor: Allows new operations to the objects without changing the structure of the objects themselves.

Ultimately, the best pattern to use depends on the question asked. For example, if your software is generating IDs for your desktop app, you only want a single class generating those IDs, especially if you have more than one thread working off that class. The Singleton pattern is extremely relevant here as it ensures that each process in the software will have only one instance of your class.

OOD is the oldest among the stages of tech design interviews, but it is not going away anytime soon. System Design can only be effective with individual processes also being optimized. Nobody will use a web app if their web browser software provides a bad user experience. Scalability only matters if customers want to stick around in the first place.

Advanced System Design: Build on past designs

Looking at case studies and analyzing patterns found in distributed systems built in the past is a great way to identify successful strategies for designing resilient, long-lasting systems. It's a practice that I encourage all engineers to invest some time in because so many high-level distributed systems, like Amazon's DynamoDB, are modeled on past systems. In turn, these systems tend to influence the design of future distributed systems.

So, in a way, you can understand the heart of modern distributed systems by studying the strengths and limitations of older systems. Advanced System Design interviews require a deep understanding of distributed systems, particularly their history and evolution.

While being Advanced in System Design does not mean you are expected to start totally from scratch with every design. It does mean you can efficiently utilize pre-existing structures to quickly diagram the optimal version of a system while weighing any inherent strengths or flaws against the final design. Analyzing successful strategies and designs used in older distributed systems for later use is also known as pattern sharing.

An excellent example of pattern-sharing in the real world can be found in Amazon DynamoDB. In 2004, Amazon published “The Dynamo Paper,” which documented the creation of their in-house database. This led to the development of DynamoDB a few years later. DynamoDB would go on to significantly influence the overall design of Apache Cassandra.

In 2008, Facebook released Apache Cassandra, a database that aimed to replicate Dynamo’s distributed storage and replication techniques while integrating the ability to handle large analytical and operational workloads like Google’s Bigtable database. In fact, Avinash Lakshman, one of the lead developers on the Cassandra project, was also one of the authors of “The Dynamo Paper.”

I think it's safe to bet he didn't start completely from scratch on Cassandra.

The lesson I want to impart here is the importance of leveraging previous knowledge and building upon existing design patterns to innovate new, and effective solutions. Lakshman's experience working on DynamoDB allowed him to incorporate proven techniques to improve and expand an existing design. You'll need to practice this general approach as you prepare to solve various problems in the System Design interview.

Dive deeper into design interview prep

High-level versus low-level. Abstract patterns versus concrete examples. Focused versus expansive. These are just some of the differences between these two opposite ends of the design interview, Low-Level OOD and ASD. In a future newsletter, I will take a look at all the different flavors of design interviews, including API Design, to help you lock in your interview prep. Stay tuned!

For your next steps toward mastering these two ends of the design interview, I suggest checking out our brand new courses on the subject:

• Grokking the Low-Level Design Interview Using OOD Principles: Start programming software for low-level processes using the full roster of OOD patterns and walk-throughs of practice design problems, like designing an elevator system.

• Grokking the Principles and Practices of Advanced System Design: Continue learning high-level, real-world systems such as Google Cloud Spanner and DynamoDB.

• And if you need to brush up on your System Design fundamentals, check out our best-selling course Grokking the Modern System Design Interview for Engineers and Managers.

Best of luck, and happy learning!