Low-Level Design — Introduction

🟥 The 4000-line method

public class Payment {
  public void charge(String type, double amt) {
    if (type.equals("card")) {
      // 800 lines of card logic
    } else if (type.equals("applepay")) {
      // 600 lines of Apple Pay logic
    } else if (type.equals("upi")) {
      // 700 lines of UPI logic
    } // ...10 more elses
  }
}

🟩 The LLD version

interface PaymentMethod {
  Receipt charge(double amt);
}

class Card     implements PaymentMethod { ... }
class ApplePay implements PaymentMethod { ... }
class UPI      implements PaymentMethod { ... }

// Adding crypto = one new file, zero edits
class Crypto   implements PaymentMethod { ... }

① Requirements Discipline

Can you turn a vague prompt — "design a parking lot" — into a tight list of features the design must support, plus a list of things you're explicitly punting on? Candidates who skip this step always design the wrong system. The good move sounds like: "Top 3 functional features I'll focus on: (a) park a car, (b) calculate the bill on exit, (c) reserve a spot from an app. Out of scope: payment processing, valet integration, multi-tenant operators. Sound right?"

What it looks like: the candidate produces 5 functional + 3 non-functional requirements in the first 3 minutes, names what's out of scope, and gets explicit interviewer buy-in before drawing anything.

② Domain Modelling

Can you take the vocabulary of the problem (cars, spots, tickets, gates) and translate it into a coherent class model — picking the right entities, the right relationships (composition vs aggregation vs inheritance), and the right level of abstraction? This is the heaviest weight in the rubric. A great class diagram is half the interview.

What it looks like: the candidate names 5–8 entities, explains why each one is its own class (vs a field on another class), and can defend their inheritance vs composition choices with a one-line reason rooted in "what changes independently?"

③ Pattern Application

Can you spot the variation points in the design — the places where future requirements are most likely to demand change — and apply the right GoF pattern there? The senior signal isn't "I memorized 23 patterns"; it's "I picked Strategy here because pricing rules will change every quarter, and I picked State here because the booking goes through 6 distinct lifecycle stages."

What it looks like: 2–4 patterns named, each one tied to a specific class in the design, each one justified by a concrete future-change scenario the interviewer can imagine.

④ Communication & Trade-offs

Can you narrate why you're making each choice, respond to interviewer pushback without getting defensive, and articulate the trade-offs of every decision in one sentence? The interviewer is also scoring "would I want this person on my code review?" Candidates who design silently — heads down, drawing for 20 minutes — fail this pillar even when their design is correct.

What it looks like: the candidate thinks aloud, asks "is this the depth you want?" at every milestone, and when challenged with "why composition not inheritance?" answers in one sentence: "A car's engine isn't an 'is-a' — it's a 'has-a'. If we ever need a hybrid (gas + electric), inheritance forces multiple inheritance; composition just adds another field."

Step 1 · ~5 min

Requirements. Functional + non-functional. Top 3 user actions. Explicit out-of-scope list. Get interviewer sign-off.

Step 2 · ~5 min

Core Entities. List 5–8 nouns with one-sentence responsibility each. No fields yet.

Step 3 · ~10 min

Class Diagram. UML with fields, methods, and relationships (inheritance/composition/association).

Step 4 · ~10 min

Patterns + Sequence. Identify variation points, apply 2–4 GoF patterns. Sequence diagram for the primary flow.

Step 5 · ~12 min

Java Code. Enums → interfaces → entity classes → service → main(). One end-to-end happy path that compiles in your head.

Buffer · ~5 min

Trade-offs & Q&A. Cross-questions on extension points, concurrency, and "what would you change?"

S — Single Responsibility

Every class has one reason to change. The Invoice class shouldn't know how to print itself; that's the printer's job.

The test: can you describe what the class does in one sentence without using "and"? If not, split it.

O — Open/Closed

Open for extension, closed for modification. Adding a new payment method shouldn't require editing the existing payment processor.

The test: can you add a new variant by writing a new file (not editing an old one)? If not, you're missing an interface.

L — Liskov Substitution

A subclass must be usable wherever its parent is, without surprises. If Square extends Rectangle and setting width changes height, you've broken Liskov.

The test: can the caller use any subclass without checking instanceof? If they need if (obj instanceof Square), the hierarchy is wrong.

I — Interface Segregation

Many small interfaces beat one fat one. Don't force JsonReader to implement writeXml() just because it sits in the same hierarchy.

The test: does any implementation throw UnsupportedOperationException? You've combined unrelated capabilities — split the interface.

D — Dependency Inversion

Depend on abstractions, not concretions. The OrderService shouldn't new MySQLOrderRepo() — it should accept a OrderRepository interface in its constructor and let the wiring decide which implementation to inject.

The test: can you swap MySQL for an in-memory store in the unit tests without changing OrderService? If yes, you're inverted. If you have to mock the database driver, you're not.

🚨 Diving into code at minute 5

Candidate hears "design an elevator" and starts writing class Elevator { ... } without naming the requirements, the entities, or the relationships. The result is always the same: 30 minutes in, you realise you needed a Request queue but you've already wired Elevator to take a floor directly, and now you're refactoring on the whiteboard.

Fix: nothing gets written until Step 4. The first four steps are diagrams and lists.

🚨 Pattern-dropping for points

Candidate name-drops "I'll use the Visitor pattern, the Memento pattern, and the Bridge pattern" for a vending machine that needs none of them. The interviewer asks "why Visitor?" and the candidate folds. Naming a pattern you can't justify is worse than not naming one.

Fix: two to four patterns, max. Each one tied to a specific class and a specific reason in one sentence.

🚨 Inheritance-everywhere

Every relationship becomes a class hierarchy. Car extends Vehicle, SUV extends Car, HybridSUV extends SUV. By depth four nothing is overrideable without breaking a sibling. Inheritance is a one-way door — composition is reversible.

Fix: default to composition. Use inheritance only for genuine "is-a" relationships where the subclass adds behaviour, not just fields.

🚨 Forgetting concurrency

Two users hit "book this seat" at the same millisecond. Both succeed. The interview is over.

Fix: any time you have a shared mutable resource (a parking spot, a movie seat, an inventory count), say out loud — "this needs synchronisation; I'll use a per-row lock / atomic CAS / optimistic concurrency" — even if the interviewer doesn't ask.

🚨 Designing in silence

Candidate goes head-down for 20 minutes, draws a beautiful UML diagram, then turns around. The interviewer has no idea why any of those choices were made and can't grade the reasoning. It doesn't matter how good the design is — silence fails the communication pillar.

Fix: narrate every decision. "I'm putting Spot behind an interface because the parking lot has bike, car, and truck spots and they have different size constraints."

🚨 Boilerplate-heavy code

With 12 minutes for code, the candidate writes 4 minutes of getter/setter boilerplate, leaves no time for the actual logic. The interviewer learns nothing about how you'd implement parkVehicle().

Fix: say "I'll skip getters/setters and Lombok this in production." Use Java records or just write public fields on the whiteboard. Spend the time on the methods that matter.