Low-level design is graded on two things at once: whether your classes would survive the next requirement, and whether you can turn them into working code before the clock runs out. This chapter explains both round formats, what the interviewer writes on the scorecard, a minute-by-minute plan for each, and one complete worked example, a vending machine, taken from requirements to tested code to the extensions an interviewer adds halfway through.
Two rounds under one name
Companies use "LLD" for two different exercises. Ask the recruiter which one you are getting, because the preparation and the time plan differ.
| Aspect | Object-oriented design (OOD) | Machine coding |
|---|---|---|
| Length | 45–60 min, one interviewer | 60–120 min of coding, often followed by a 15–30 min review of your code |
| Medium | Whiteboard, shared doc or CoderPad; code is partial | Your own IDE or a shared editor; the code must run |
| Output | Requirements, class diagram, interfaces, a few method bodies, trade-offs said out loud | A runnable project with a driver (a main that exercises the use cases), sometimes tests |
| Interviewer | Present throughout, steers and adds requirements | Often present only at the start and at the review; you work alone in between |
| Where you meet it | Amazon loops (an OO design round, or a project deep dive, in the SDE III loop), Microsoft and Atlassian (Atlassian's "Code Design" coding interview, alongside a separate data-structures one), many US-style loops | Indian product companies: Flipkart, Swiggy, Razorpay, Uber India and others; reported as 90 minutes at Flipkart and Swiggy |
| Typical prompts | Parking lot, elevator, library, chess, file system, LRU cache | Splitwise, BNPL (buy now, pay later) wallet, inventory with reservations, rate limiter, job scheduler, cab booking |
At Flipkart, recent candidate reports (2025–26) describe the problem arriving as a shared document, a short walk-through by an engineer, 90 minutes of coding in any language in your own editor, a zip upload, and then a separate session where an engineer reads the code with you and asks for a change. Uber's India loop has been reported with a machine-coding round on a concurrent job scheduler. Treat these as reports, not policy: formats differ by team and change between hiring drives.
If the invite says "machine coding", "LLD round with laptop", or "bring your own IDE", expect a working-code round. If it says "object-oriented design" or "low-level design discussion", expect the 45-minute format. If it says nothing, ask: "Will I be expected to produce running code, and in which language?"
Low-level design is a different exercise from system design. System design draws boxes that are services and asks about scale. LLD draws boxes that are classes inside one process and asks about change.
What is graded
Interviewers grade against a rubric that is close to the same everywhere. The left column is what goes on the scorecard; the right two are what earns a strong mark and what loses it.
| Dimension | Strong signal | Weak signal |
|---|---|---|
| Requirement gathering | A written list of use cases, with "in scope" and "out of scope" marked, and two or three numbers (how many slots, how many users) | Starts drawing classes in the first minute; discovers a requirement at minute 40 |
| Entities and responsibilities | Each class has one job you can say in a sentence; data and the behaviour that uses it live together | A Manager class that does everything; data-only classes with all logic in one service |
| Relationships | Says which objects own which (composition) and which only refer to each other; multiplicities are right | Everything holds a reference to everything; cycles nobody can explain |
| Interfaces | Small interfaces at the points that will vary (payment, pricing, notification); callers depend on the interface | No interfaces, or one interface per class "for flexibility" |
| Extensibility | The interviewer's new requirement lands as a new class or a new entry in a table | The new requirement means editing if/elif chains in five places |
| SOLID and patterns | Patterns appear because a requirement asked for them, and you name what each costs | Patterns named to impress; a factory for one product |
| Correctness | Invariants stated and kept: money never negative, a seat never sold twice, state changes only after every check passes | Half-updated objects after an exception |
| Concurrency | Names what is shared, protects it, explains the lock's scope | "I'd make it thread-safe" with no detail; or locks everywhere |
| Testability | Dependencies are passed in (clock, repository, payment); a driver or tests show the use cases running | Hidden datetime.now() and globals; nothing runs |
| Code quality | Clear names, short methods, typed signatures, custom exceptions, no dead code | One 200-line function; magic strings; printing instead of returning |
| Finishing | Every must-have use case runs end to end before any bonus | A beautiful framework with no working use case |
In machine coding, working code beats elegant code. Several Flipkart candidate reports say this plainly: a run that demonstrates every required use case with a plain design scores better than a pattern-rich design that does not run. Design quality decides between two working submissions; it does not rescue a broken one.
You run interviews yourself, so you know the interviewer is filling in boxes while you talk. Make each box easy to fill: say "requirements done", "here are the entities", "this is the extension point for X". You also know one real state machine deeply, the order lifecycle from new to filled or cancelled, and how a retry must not create a second trade. Use it as the example whenever the interviewer asks "where have you used the State pattern?"
The 45-minute OOD plan
This is the plan for the discussion format. Write the timestamps at the top of your sheet and glance at them.
- 0–5 min
- Clarify. Write the use cases as a numbered list of verbs ("park a vehicle", "pay at exit", "show free spots per floor"). Mark two or three out of scope out loud. Ask for one or two numbers that change the design (number of floors, concurrent entry gates).
- 5–12 min
- Entities. Nouns from the use cases become candidate classes; verbs become methods. For each class say its one responsibility. Drop nouns that are only attributes (a "colour" is a field, not a class).
- 12–20 min
- Class diagram in text: classes, key fields, public methods, relationships with multiplicity. Mark the interfaces at the points that will vary and say why each one exists.
- 20–35 min
- Code the core path: the main service class and the two or three methods behind the most important use case, plus the interfaces. Signatures for everything else.
- 35–42 min
- Walk one scenario through the objects, call by call. Answer "what if two people do this at once?" Take the extension the interviewer adds and show where it lands.
- 42–45 min
- Summarise trade-offs and what you would build next. Leave the last minute for their questions.
"Before I draw anything I'd like to pin down scope. I'll list the use cases I think matter, you tell me what to add or drop, and then I'll go entities, relationships, interfaces, and code for the main flow. I'll keep extension points where I expect change and say what each one costs."
The 90-minute machine-coding plan
In machine coding the interviewer is usually absent, so the plan is about protecting working code. The rule: a vertical slice that runs, then the next slice. Never write all the models, then all the services, then discover at minute 80 that nothing runs.
- 0–10 min
- Read the whole statement twice. Copy every requirement into a checklist at the top of your
READMEor main file, split into must-have and bonus. Note the input format (command lines? method calls?) and the exact output format if one is given. Ask the interviewer every question now; you may not see them again. - 10–20 min
- Model. Write the entity classes (dataclasses), the exceptions, the interfaces, and empty service methods. Run the file once so imports and syntax are known good.
- 20–55 min
- Implement must-have use cases one at a time. After each one, add two lines to the driver that exercise it and run it. Commit (or copy the file) after each green run, so a late mistake never costs a working version.
- 55–70 min
- Error paths: invalid input, not found, insufficient balance, duplicate request. Each raises a named exception that the driver catches and prints.
- 70–82 min
- Bonus requirements, in the order the statement lists them. Thread safety if the statement mentions concurrent users.
- 82–90 min
- Stop adding features. Clean names, delete dead code, run the full driver one last time, write five lines of notes: assumptions, how to run, what you would add next.
60-minute variant: cut modelling to 5 minutes, skip bonus features, keep the last 5 minutes for a clean run. 120-minute variant: add a small test file (plain asserts are enough) at minute 60 and spend the extra time on concurrency and one extension.
The review session. Expect three kinds of question: "walk me through the flow of this use case", "why this class and not that one", and "add this feature now". The last one is the real test of your design. If it lands as one new class plus one line of wiring, you have shown extensibility without having to claim it.
Gathering requirements
Most prompts are deliberately vague: "design a parking lot". The interviewer wants to see you turn it into a finite list. Use the same five headings every time so you never forget one.
| Heading | Questions that change the design |
|---|---|
| Actors | Who uses it? A customer, an admin, an operator, another system? Do different actors see different operations? |
| Use cases | What are the five to eight verbs? Which three are the core? Is there a history or reporting requirement? |
| Rules | Pricing rules, limits, priorities, what happens on ties, what is forbidden (double booking, negative balance)? |
| Variation | What kinds of thing exist (vehicle types, payment methods, split types)? Which list is likely to grow? That list is where an interface goes. |
| Operational | Concurrent users? Persistence (in memory is usually fine)? Input format: method calls, a command-line protocol, or a file? |
Write the result as a short scope block. Here is the one for the worked example below:
IN SCOPE
1. Customer inserts notes/coins (₹1, 2, 5, 10, 20, 50, 100)
2. Customer selects a slot code ("A1"); machine vends and returns change
3. Customer cancels; machine returns exactly what was inserted
4. Operator puts machine in maintenance, restocks, takes it out
5. Errors: unknown slot, sold out, not enough money, cannot make change
OUT OF SCOPE (said out loud)
card/UPI payment (extension), multiple items per transaction,
persistence across restarts, a hardware driver
Class diagrams in text
This playbook draws class diagrams in plain ASCII, because that is what you can type into a shared doc or CoderPad in an interview. These are the conventions. They follow UML closely enough that an interviewer reads them without a legend.
+----------------------+ | VendingMachine | a class: name, then fields, then methods +----------------------+ | - state: State | - private + public # protected | - cash: Counter | +----------------------+ | + insert(note) | | + select(code): Vend | +----------------------+ <<interface>> ChangeMaker stereotype: interface / abstract / enum Child ----|> Parent inherits from, or implements Car <*>---- Engine composition: Car owns Engine; it dies with Car Team <>----- Player aggregation: Team groups Players; they outlive it Order ------> Customer association: Order keeps a reference Report - - -> Clock dependency: Report uses Clock in a method only Lot 1 <*>---- 1..* Floor multiplicity at each end: 1, 0..1, *, 1..*
Draw only the classes that carry a decision. A class carries a decision when you had a real choice about it and the interviewer might ask why: a mode that changes behaviour (a state), a rule you may swap later (a strategy such as change-making), or a thing that owns data others must not touch. Plain data holders and helpers can stay out of the picture.
A diagram with eight boxes and labelled relationships beats one with twenty boxes and unlabelled lines. If you forget the exact symbols, write the word beside the line ("inherits", "owns", "uses"). The meaning matters more than the notation.
Terms. Interface: a promise of methods with no code, which several classes can keep. Inherits: one class reuses and extends another. Composition: the whole creates and owns the part, and the part goes when the whole goes. Multiplicity: how many of one thing relate to the other ("1..*" means one or more).