What an LLD round really tests

Part of the free Low-Level Design course on LogicWiz, in the chapter: How LLD interviews work. The class-diagram exercises run in the app.

Week 1: The mock round that ran but did not pass

"Your code works. I still would not hire you on this round."

Priya, reviewing Arjun's mock machine-coding solution

Two rounds, one skill underneath

Arjun is an SDE-1 at SwiftKart, a quick-commerce app that delivers groceries in 10 minutes. He has interviews coming up at two product companies. Both have an LLD round. LLD means low-level design: the classes inside one program, their data, their methods and how they connect.

Companies run this round in two forms:

  • Machine coding. You get a problem such as "build a parking lot" and about 90 minutes. You write a working program on your own laptop. Then the interviewer reads it and asks for a change.
  • Design discussion. You draw a class diagram on a whiteboard or a shared document. The interviewer changes a requirement and watches how your design copes.

The skill underneath is the same. Can you turn a vague problem into small classes with clear jobs? Can you change them without breaking everything else?

The ideas in this course apply to any object-oriented language, such as C++, Python, Kotlin or C#. The code is shown in Java. Most interview panels in India accept it, and its explicit types make the design easy to see.

What Arjun wrote in his mock

Priya gave Arjun a practice problem: "Build a cart for SwiftKart. Add items, apply a coupon, and print the total." He finished in 50 minutes. Everything ran. Here is the heart of it.

import java.util.*;

public class Main {
    static Map<String, Integer> cart = new HashMap<>();
    static Map<String, Integer> prices = new HashMap<>();

    public static void main(String[] args) {
        prices.put("milk", 30);
        prices.put("bread", 45);
        cart.put("milk", 2);
        cart.put("bread", 1);
        int total = 0;
        for (String item : cart.keySet()) {
            total += prices.get(item) * cart.get(item);
        }
        String coupon = "FLAT50";
        if (coupon.equals("FLAT50") && total > 100) {
            total -= 50;
        } else if (coupon.equals("SAVE10")) {
            total = total - total / 10;
        }
        System.out.println("Total: " + total);
    }
}

Arjun believed what many candidates believe: "If my code runs and gives the right answer, I pass." Priya disagreed. The output was correct. But there was no Cart, no Coupon and no Product. Products were strings used as map keys. Every new coupon meant another else if inside main.

Interviewers do not hire you for one correct output. They hire you for the next ten changes. In a machine-coding round, the interviewer will ask for at least one of those changes before the time is up.

What interviewers grade

Most companies use a rubric, a written list of what to score. It usually looks like this. Working code matters, but it is one line out of four.

  • Working code. It compiles, runs and handles the main cases. A short demo in main proves it.
  • Clear classes. Each class has one job you can say in a sentence. Cart holds items. Coupon knows its own discount.
  • Extensibility. Extensibility means how easily a design accepts new features. A new requirement should mean adding a class, not editing ten if blocks.
  • Naming. applyCoupon(code) tells the reader what happens. process(s) tells them nothing.

Interviewers also listen to how you think. They want to hear you ask questions, state assumptions and explain trade-offs. A trade-off is a choice where you gain one thing and give up another. Arjun's code scored well on the first line of the rubric and poorly on the other three.

💡 Tip: Say your assumptions out loud and write them as comments at the top of your file. If the interviewer disagrees, you find out in minute 5, not minute 80.

The five steps

Priya gave Arjun a routine for every LLD problem. It works for a parking lot, for Splitwise and for a SwiftKart cart. You will meet those interview problems again in the problem library.

flowchart LR
  A["1 Clarify"] --> B["2 Find entities"]
  B --> C["3 Draw classes"]
  C --> D["4 Code the core"]
  D --> E["5 Extend"]
  1. Clarify. Ask what is in scope. Which coupon types exist? Is it one coupon per order, or many? Spend about 5 minutes here.
  2. Find entities. An entity is a thing the system must track. Here they are product, cart, cart item and coupon. Most entities become classes.
  3. Draw classes. Sketch boxes with their key fields and methods, and the lines between them. Ten minutes on a diagram can save forty minutes of rewriting.
  4. Code the core. Write the main flow first: add to cart, apply a coupon, get the total. Keep data in memory, in maps and lists, instead of a database.
  5. Extend. The interviewer says "now add a percentage coupon with a cap". A good design takes this as one new class. A weak design needs edits everywhere.

Arjun redid the problem with these steps. His second version had a Cart class holding CartItem objects, a Product with a price, and a Coupon that worked out its own discount. When Priya asked for the percentage coupon, he added one small class. The rest of the code did not change.

Try it: break up the class that does everything

A class that does everything is called a god class. It has so many fields and methods that every change touches it, and two people editing it at once get in each other's way. Below, SwiftKart's code is drawn as one god class called SwiftKartApp.

Split it into smaller classes with one job each. Click a class to edit its name, fields and methods. Module 3 teaches the full drawing notation, so for now plain names are enough.

📌 Summary: LLD rounds grade working code, clear classes, extensibility and naming. Use five steps every time: clarify, find entities, draw classes, code the core, then extend.

What Arjun learns next

Step 2 sounded easy: list the entities. But how do you get from a paragraph of requirements to the right classes? In the next lesson, Priya shows him, using SwiftKart's new coupon feature.

Check your understanding

  1. Arjun's mock solution prints the right total, but all the logic sits in main with maps of strings. Where does it lose the most marks?
  2. At minute 70 the interviewer says "now add a 10% coupon capped at ₹150". What does a good design let you do?
  3. You have 90 minutes for a machine-coding problem. What should the first five minutes go on?
  4. How does the design discussion round differ from the machine-coding round?