This chapter lays out a 5-step framework that works for any OOD problem. We will walk through each step using Stack Overflow as the running example.

Here are the 5 steps:

Step 1: Clarify Requirements (3-5 minutes)

Most candidates hear "Design Stack Overflow" and immediately start thinking about classes and methods. Do not do that. "Design Stack Overflow" could mean very different things depending on the interview, and you have no way of knowing the expected scope until you ask.

OOD interviews are typically 45-60 minutes. You cannot design all of it. Clarifying questions help you identify the right scope and focus on what matters.

So, start with a conversation. Ask questions. Narrow down what the interviewer actually wants you to build.

What to Ask

There are four categories of questions you should cover:

After this conversation, you have a clear picture of what to build.

The biggest mistake at this stage is making assumptions. If you assume the system needs a full notification engine, badge system, and search functionality without asking, you will waste precious time building things the interviewer never asked for. Always confirm scope before moving forward.

Step 2: Identify Core Entities (3-5 minutes)

With requirements locked down, shift from features to objects. What are the "things" in this system?

The Noun Extraction Technique

A simple and effective technique is to go back to your requirements and underline every noun. These nouns are your candidate entities.

From our Stack Overflow requirements:

That gives us six core entities: User, Question, Answer, Comment, Tag, and Vote.

Tips for Identifying Entities

One helpful trick is to write your entities first, then draw arrows between them showing how they relate. This gives the interviewer a visual anchor and gives you a roadmap for the class design ahead.

You now have a list of entities and a rough sketch of how they connect. Next: formalize these into a proper class structure.

Step 3: Design Classes and Interfaces (20-25 minutes)

This step is the core of the interview. You will take the entities from Step 2 and turn them into a class structure with attributes, relationships, interfaces, and a clean API. This step carries the most weight in the session, so do not rush it.

We will break this into three parts: defining classes and relationships, extracting interfaces, and creating a central manager class.

3.1 Define Classes, Attributes, and Relationships

Start by converting each entity into a class with its key attributes.

For each class, ask yourself:

For our Stack Overflow example:

When presenting this to the interviewer, it helps to briefly explain your relationship choices. For example: "I am using composition here because a Question owns its Answers. If we delete a question, its answers should go with it. But Tags are shared across questions, so that is an association, not composition."

You can draw a UML class diagram to illustrate the relationships between classes or code the class structure directly in an object oriented programming language of your choice.

Note: Drawing UML diagrams in a LLD interview is not mandatory but it’s good to check with the interviewer.

3.2 Define Interfaces and Core Methods

Now look at your classes and find shared behavior. The verb extraction technique works well here: go through your requirements and pull out every action.

Users can comment on both questions and answers. Users can vote on both questions and answers. This shared behavior is a strong signal that you should extract interfaces.

Code Example

With these interfaces, Question and Answer both implement Commentable and Votable. No duplicated method signatures. If the interviewer later asks "What if we want to add voting to comments too?", you just have Comment implement Votable without touching existing code. That is the Open-Closed Principle at work.

Why interfaces instead of putting the methods directly on Question and Answer? Interfaces give you a contract. Any class that implements Votable is guaranteed to have vote(). This makes the system easier to extend and test.

3.3 Define a Central Manager Class

Every LLD problem benefits from having a central class that acts as the entry point for the system. This is essentially the Facade pattern: one class that coordinates all the major operations and hides the internal complexity.

For Stack Overflow, this is the StackOverflow class. It is responsible for user registration, posting questions, posting answers, and searching. Think of it as the API layer that the outside world interacts with.

The key methods on this manager class would include:

Here is an example implementation of askQuestion to show how the classes collaborate. In an OOD interview, this level of detail is usually sufficient. You do not need fully compilable code.

Your class structure is now on paper with clear relationships, shared interfaces, and a clean API surface. The next step is identifying where design patterns fit into this structure, if they fit at all.

Step 4: Apply Design Patterns (5-7 minutes)

Do not force patterns into your design to impress. Apply them where they solve a real problem. One or two well-placed patterns with clear reasoning beats listing five you do not actually use.

For our Stack Overflow design, three patterns are worth mentioning.

Strategy Pattern: Reputation Calculation

Stack Overflow's reputation rules are non-trivial: +10 for an answer upvote, +5 for a question upvote, -2 for a downvote, and so on. These rules could change. You might want a simplified scheme for a new community, or boosted rewards during a promotional event.

By extracting reputation calculation into a strategy interface, you can swap implementations without modifying the core classes.

When explaining this, keep it simple: "Reputation rules will probably change. With a strategy interface, I can add new rules without modifying User or StackOverflow."

Observer Pattern: Notifications

When someone answers a question or comments on an answer, the question author might want to be notified. Rather than having the StackOverflow manager class directly call notification logic (which would violate single responsibility), you can use the Observer pattern.

You do not need to implement a full notification system. Simply mentioning "I would use the Observer pattern here so that the Question class can notify subscribers when a new answer is posted" is enough to demonstrate the concept.

How to Discuss Patterns With the Interviewer

When applying patterns in an OOD interview, always cover three things:

A common pattern table for LLD interviews:

Do not try to use all of these. Pick 1-2 that genuinely improve your design and explain them clearly. Clear reasoning beats pattern name-dropping.

Step 5: Walk Through Use Cases and Edge Cases (5-10 minutes)

Walking through a use case end-to-end proves that your classes actually work correctly together. You can also use a sequence diagram here to cover the workflow.

Use Case 1: User Asks a Question

Walk the interviewer through the flow verbally while pointing to your class diagram:

Use Case 2: User Votes on an Answer

This flow is more interesting because it touches multiple classes:

Key Edge Cases to Discuss

You do not need to handle every possible edge case in code. What matters is that you think about edge cases. Mention 3-4 key ones and show validation code for 1-2:

The self-voting validation in code:

Final Note

These steps should guide you to remain on track and cover the different aspects when answering a OOD interview problem.

But you may skip some of these due to limited time in interviews.

It’s always a good idea to check with the interviewer on what all is expected from the design.