Types of LLD interviews

"LLD round" covers two different formats that share a prompt style and diverge completely in what you have to produce. Knowing which one you are walking into changes how you should spend your time.

Object-oriented design (OOD) rounds

The classic version: "design a parking lot," "design a vending machine," "design a chess game." You talk through the problem, sketch classes on a whiteboard or a shared doc, draw the relationships between them, and narrate how a request flows through your design. Code is optional and, when it appears, it is usually a short snippet to prove a point - not something that has to run.

What is actually being scored:

• Requirements gathering - do you ask what "parking lot" means before designing one? Multiple vehicle types? Multiple floors? Reserved spots? Skipping this step and diving straight into classes is the single most common way this round goes wrong.
• Entity modeling - did you find the right nouns and give each one a single, coherent job, or did you invent five classes that all do a bit of everything?
• Use of patterns and principles - does a Strategy show up naturally where pricing varies by vehicle type, or did you force a pattern in because you knew its name? Interviewers notice both directions.
• Communication - can you defend a design decision out loud when pushed on it?

Machine coding rounds

Same family of prompts, but now you have a fixed block of time - typically 45 to 90 minutes - to produce code that actually compiles and runs, often with an interviewer watching or reviewing the result afterward. Talking through your design still matters, but it is no longer the deliverable; working, testable code is.

This changes the shape of the problem itself. A machine coding prompt is usually a narrower slice of the OOD version - "design a parking lot" becomes "design a parking lot that supports two vehicle types and prints a receipt on exit" - because there simply isn't time to model and implement an unbounded system.

What is actually being scored:

• Code quality - naming, structure, whether a method does one thing, whether the code you already know from this site's clean-code pages actually shows up under pressure.
• Correctness - does it compile, does it run, does it handle the cases you were asked to handle.
• Design under constraints - the same entity-modeling and SOLID judgment as an OOD round, except now a bad early decision costs you time you don't have to unwind it in.
• Extensibility, sometimes tested live - a common twist is the interviewer asking you to add one more requirement in the last fifteen minutes, specifically to see whether your design absorbs the change or requires a rewrite.

Same skill, different depth of output

Neither format is testing a different skill from the other - both want to see whether you can turn a vague requirement into a coherent object model. The difference is entirely in how far you have to carry that model: an OOD round rewards a design that is correct on paper, and a machine coding round only rewards a design that survives being actually typed out and run. Prepare for the second and you are automatically ready for the first; the reverse is not guaranteed.

Try it yourself: "design a tic-tac-toe game, playable by two people, with a result printed at the end" was handed to you as an interview prompt. Does the phrasing read more like an OOD round or a machine coding round, and what in the wording gave it away?

Check yourself

Question 1 of 3

What is the sharpest distinction between an object-oriented design round and a machine coding round?