Why Most Candidates Fail LLD Interviews

Learn the four recurring mistakes that sink LLD interviews — and the small mental shift that fixes each one.

The four killers

Across thousands of LLD interviews, the same four anti-patterns show up over and over. Memorize them as the things to not do:

1. Killer #1 — Jumping straight to code. Writing classes before you've identified the entities, their responsibilities, and the API. You end up coding the first idea instead of the right one.
2. Killer #2 — Missing abstractions. Hard-coding behavior with if/else on a type or string, instead of modeling it as an interface with implementations.
3. Killer #3 — Overengineering. Reaching for five design patterns, factories of factories, and a config DSL for a problem that needed three classes.
4. Killer #4 — Ignoring extensibility. A design that works for today's requirement but forces you to rewrite existing classes the moment the interviewer says "now also support X."

Notice the tension: #2 and #3 pull in opposite directions. Great candidates abstract exactly the axis that will change — no more, no less. That judgment is the whole game.

Killer #1 — Jumping straight to code

The fix is a 3-minute ritual before any class: list the entities (nouns), the actions (verbs), and the public API the caller wants. Say it out loud. Only then type.

Killer #2 — Missing abstractions

Before — pricing logic switches on an enum. Every new ride type forces you to edit this method (and you'll forget a branch).

enum RideType { POOL, REGULAR, PREMIUM }

class FareCalculator {
    double fare(RideType type, double km) {
        if (type == RideType.POOL)    return km * 0.8;
        if (type == RideType.REGULAR) return km * 1.0;
        if (type == RideType.PREMIUM) return km * 1.5 + 50;  // base fee
        throw new IllegalArgumentException("Unknown type: " + type);
    }
}

After — the thing that varies (the pricing rule) becomes an abstraction. Adding a ride type means adding a class, never touching FareCalculator.

interface PricingStrategy {
    double fareFor(double km);
}

final class PoolPricing implements PricingStrategy {
    public double fareFor(double km) { return km * 0.8; }
}

final class RegularPricing implements PricingStrategy {
    public double fareFor(double km) { return km * 1.0; }
}

final class PremiumPricing implements PricingStrategy {
    private static final double BASE_FEE = 50;
    public double fareFor(double km) { return km * 1.5 + BASE_FEE; }
}

final class FareCalculator {
    double fare(PricingStrategy pricing, double km) {
        return pricing.fareFor(km);   // no branching, ever
    }
}

The if/else chain on a type is the single loudest "missing abstraction" smell an interviewer listens for.

Killer #3 — Overengineering

Before — a candidate "designs for the future" with a factory, a builder, and an abstract base, to produce one kind of object.

abstract class AbstractNotificationFactory {
    abstract NotificationBuilder newBuilder();
}

class EmailNotificationFactory extends AbstractNotificationFactory {
    NotificationBuilder newBuilder() { return new EmailNotificationBuilder(); }
}

class EmailNotificationBuilder {
    private String to;
    private String body;
    EmailNotificationBuilder to(String t)   { this.to = t; return this; }
    EmailNotificationBuilder body(String b) { this.body = b; return this; }
    Notification build() { return new EmailNotification(to, body); }
}
// ...and we only ever send emails.

After — model what the requirement actually asked for. You can always introduce a strategy interface when a second channel appears.

record Notification(String to, String body) {}

final class EmailSender {
    void send(Notification n) {
        // hand off to SMTP client
        System.out.println("Email to " + n.to() + ": " + n.body());
    }
}

Rule of thumb: abstract on the second occurrence, not the first. Patterns are a response to real variation, not a way to look senior.

Killer #4 — Ignoring extensibility

This is the inverse of #3: under-abstracting on the axis the interviewer is about to stress. They will always add a requirement. A design passes when the new requirement is "add a class," and fails when it's "rewrite this method." The class diagram below shows the extensible shape from Killer #2 — a new ride type plugs in with zero edits to existing code.

When the interviewer says "now add surge pricing," you write one SurgePricing class and you're done. That moment — adding a feature without editing old code — is what earns the offer.

class ParkingLot {
    int park(String vehicleType, int spotId) {
        if (vehicleType.equals("CAR"))   return spotId * 2;
        if (vehicleType.equals("BIKE"))  return spotId;
        if (vehicleType.equals("TRUCK")) return spotId * 3;
        return -1;
    }
}