Why this matters: most candidates prepare for two interviews — LeetCode and the whiteboard — and then meet a third one they never rehearsed. The LLD round sits exactly between the other two, and it fails people who are good at both, because it grades something neither of them measures: whether your code has a shape that survives change.

What an LLD round is

A low-level design interview hands you a system small enough to build in 45 minutes and asks you to actually build it — not sketch boxes on a whiteboard, not solve a puzzle with a known trick, but model it, code its core, and then defend your choices under pressure.

The unit of evaluation is different from the rounds you know. In a DSA round, the interviewer mostly grades a path: did you find the insight, was the complexity right. In a system design round, they grade a map: components, flows, trade-offs at scale. In an LLD round they grade a structure: where responsibilities live, what the pieces promise each other, and — above everything — what happens to your design when something about the problem moves.

That last part is worth saying plainly, because it is the round's open secret: the design you produce matters less than how it absorbs change. Interviewers engineer this. Somewhere past the midpoint, the requirements will shift under you, deliberately.

The two flavors

LLD comes in two distinct flavors, and companies rarely label which one you'll get.

Machine coding is the object-design flavor: design a parking lot, a rate limiter, Splitwise. The raw materials are classes, interfaces, and responsibilities. The interviewer watches how you carve the problem into parts — whether pricing logic ends up owned by one thing or smeared across four, whether adding a new vehicle type touches one file or every file. This flavor dominates product-company loops, and in India it is a standard round at essentially every SDE-2+ interview.

Systems programming is the primitive-building flavor: implement a memory allocator, a thread pool, a ring buffer. The raw materials are bytes, pointers, and threads. The interviewer watches whether you think in invariants — the properties your structure must never violate — and whether your claims about memory and concurrency survive being pressed. This flavor rules at infrastructure companies, trading firms, and anywhere the product is the low-level software.

                 machine coding              systems programming
material         classes, interfaces         bytes, pointers, threads
core question    where do responsibilities   which invariants hold,
                 live?                       and what breaks them?
the twist        "requirements just          "what happens under
                 changed — extend it"        contention / exhaustion?"
typical problems parking lot, Splitwise,     allocator, thread pool,
                 rate limiter                ring buffer, spinlock

Different materials — but the same skeleton underneath, which is why one course covers both.

The four-act shape

Nearly every LLD round, in either flavor, runs through the same four acts. Knowing the shape in advance is a real advantage, because each act is graded separately and candidates routinely ace one while sleepwalking through another.

Act one: requirements. The prompt you receive is deliberately thin — "design a parking lot" and little else. That is not laziness; the first thing being measured is whether you notice the thinness and start asking. What operations exist? What's out of scope? What does "good" mean here? Candidates who jump straight to classes have already lost points before writing a line.

Act two: design in words. Before code, the interviewer wants the model stated out loud: the entities and what each one owns, or the memory layout and what must always be true of it. This is where structural choices get made and — critically — justified. "I'll use the strategy pattern" earns nothing; "assignment policy will change, so I'm isolating it behind an interface" earns a lot, and they are describing the same code.

Act three: implementation. You build the core. Not all of it — the parts that carry the design. The grading here is quieter than you'd expect: interviewers mostly leave you alone and watch whether the code matches the words.

Act four: the twist. The requirements change, or the load changes, and your design meets reality. A good structure bends in one place; a poor one cracks everywhere at once. This act is the reason the round exists, and it has a whole lesson of its own later in this chapter.

How to use this course

The rest of this module teaches the four acts as skills — requirements gathering, design-in-words, principles-as-behavior, the twist, and complexity talk. The two problem modules then work every interview problem end to end in exactly that order, so by the time you've read a few chapters, the shape becomes reflex.