The LLD Framework: From Vision to Code

Most people go into a machine coding interview knowing they have to build something. Fewer know exactly where to start. The ones who do have a framework. Here is the one that changed how I approach every LLD problem, starting with the three lenses I use to find core classes.

The 4-Step Interview Framework

LLD interviews are time-boxed, usually 60–90 minutes. I follow a strict 4-step framework to ensure I never get stuck on a single class while the clock is ticking.

1. Overview & Goals: Align on the problem scope.
2. Requirements: Solidify the "Must-haves."
3. Design: Create the Class Diagram and identify Patterns.
4. Code: Implement the solution, focusing on the core loop first.

Rule 0: The "Outside-In" Rule

When I first started designing systems, I used to start with the smallest piece. In TicTacToe, that would be the Cell. I’d define the Cell class, then the Board, then the Player.

This is a mistake.

Starting from the inside often leads to "orphaned" code--logic you thought you’d need but never actually use. Instead, I follow the Outside-In Rule:

ExpandOutside-In Hierarchy

1. Game (The Container): Start at the very top. What is the entry point?
2. Board (The Grid): What does the Game need to manage the state?
3. Cell (The Slot): What does the Board need to track individual moves?

By starting with the Game, the dependencies discover themselves. You realize the Game needs a Board, so you create it. You realize the Board needs Cells, so you create them. This ensures every line of code has a purpose.

The Design Phase Has an Order

When an interviewer hands you a problem, the instinct is to start typing. That is the wrong move. I used to fall into this trap, only to realize twenty minutes in that my classes didn't actually support the core game loop.

Here is the order that actually works:

1. Overview: Align with the interviewer. Make sure you are both thinking about the same system before anything else.
2. Requirements: Ask which features need to be supported. Suggest features instead of waiting for them. By the end of this step, you should know exactly what you are expected to build.
3. Design: Draw the class diagram first, then the schema design. You draw the class diagram before touching the schema because the classes define what you are storing, not the other way around.
4. Code: Only now do you open the editor.

The class diagram is the first design artifact. Get it right and the rest of the interview flows naturally. Skip it and you are writing code without a map.

What to Include in a Class Diagram

Here is the thing nobody tells you: you are not expected to list every class that will exist in the final implementation. A real system has dozens of helper classes, service layers, and utility objects. None of that belongs here.

What you do want to see is two things:

1. The core entities: These are the main participants in your system. In a movie theater, it is Movie, Cinema, Hall, and Seat. In TicTacToe, it is Board, Cell, and Player.
2. Identifiable design patterns: This separates a good answer from a great one. If you recognize that a behavior has multiple variations (say, different winning conditions), that is a Strategy pattern. If creating an object requires validation, that is a Builder pattern.

Two Ways to Find the Core Classes

Once you understand what you are looking for, the next question is: how do you find it?

Method 1: Visualization

Mentally picture the system. This works best for real-world systems like a parking lot or a game board. I break this into two sub-exercises:

• Physical structure and hierarchy: What are the physical components, and how do they nest? For a parking lot: Building > Floor > Slot.
• User journey: What does a user actually do, step by step? A user in TicTacToe creates a game, waits for an opponent, and makes a move.

Method 2: Nouns in the requirements

Every noun in the requirements document is a candidate for a class. Around 90% of the time, the meaningful nouns map directly to classes. This works best for systems like Splitwise, where the requirements are dense with domain concepts.

The Outside-In Rule for Writing Classes

Once the visualization is done, there is a clear order for translating it into class definitions: go from outside to inside.

In a movie theater, the outermost container is the Cinema. Inside are Halls. Inside halls are Seats. You follow the hierarchy downward. The reason this order matters is that each class you write tells you what attributes the previous class needs. When you define Hall, you see that Cinema needs a List<Hall> attribute.

For TicTacToe, we start from Game, then Board, then Cell, and finally Piece. This sequence is both the visualization and the order in which we will define the classes.

With the framework set, the next step is to apply it to our specific problem. We will start with the overview and requirement gathering phases for TicTacToe.

The Essentials

1. The four-step approach: Overview, Requirements, Design (Class Diagram + Schema), and Code. This is the non-negotiable order for machine coding.
2. Class diagrams show core entities only: Controllers, Repositories, and Services are not expected at this stage. Focus on the domain.
3. Two methods to find classes: Visualization (physical structure + user journey) and finding nouns in the requirements.
4. Visualization finds what nouns miss: Mentally walking through the system often surfaces relationships that a static reading of requirements will not.
5. The Outside-In Rule: Follow the physical hierarchy downward, layer by layer (e.g., Game > Board > Cell). This ensures the structure writes itself.

Further Reading and Watching

• How to Approach Low Level Design Problems (System Design Primer)
• Class Diagrams: UML 2 Tutorial (Visual Paradigm)