The short answer
A low-level design (LLD) mock interview is a practice round where you turn a small problem, like a parking lot, an elevator or a rate limiter, into classes, interfaces and working code while an experienced engineer plays the interviewer. It is also called object-oriented design or a machine coding round. On Revvox it lasts 60 minutes on video with a shared code pad, and you are marked 1 to 5 on requirements, object model, design patterns, extensibility and communication. The written report arrives within 24 hours. A single round costs ₹2,499 ($32).
What a low-level design round tests
System design asks how many servers you need. Low-level design asks what the code inside one of them looks like. The interviewer gives you a small, familiar problem and watches you decide what the objects are, what each one is responsible for, how they talk to each other, and whether the result is easy to change.
Many companies run this as a machine coding round: you are expected to write code that compiles and runs, not only draw class diagrams. Others keep it on a whiteboard and focus on the model. Either way, the interviewer will add a requirement halfway through, such as a new vehicle type or a new pricing rule, to see whether your design absorbs it or has to be torn apart. That moment decides most rounds.
How it is scored
After the 60-minute round, the interviewer marks each line below 1 to 5 in your written report, due within 24 hours, with notes on what you said and wrote behind each mark. The verdict is one of Strong hire, Hire, Lean hire, Lean no hire or No hire.
| Skill (1 to 5) | What the interviewer looks for |
|---|---|
| Requirements | You pin down what must work, what can wait and what is out of scope before designing, and you write the core use cases down. |
| Object model | Classes with one clear job each, sensible relationships, and data that lives where it is used. No god class. |
| Design patterns | Patterns appear where they solve a real problem in this design, and you can say what they buy you and what they cost. |
| Extensibility | When a new requirement arrives, it fits by adding code rather than rewriting it. Interfaces and composition do the work. |
| Communication | You explain the model before coding, narrate trade-offs, and keep the interviewer with you to the end. |
Low-level design practice questions
Problems in the style of real LLD and machine coding rounds, written by us. In a mock, the interviewer picks one at your level and changes the requirements as you go.
- Design a parking garage with floors of different sizes, an entry ticket, and a fee that depends on vehicle type and time parked.Separating spots, vehicles, tickets and pricing, and adding a new vehicle type without editing every class.
- Design an in-memory cache with a size limit that removes the least recently used item when full.A hash map plus a doubly linked list, constant-time operations, and how you would make it safe across threads.
- Design a meeting room booking system for an office, where two people can try to book the same room at once.A clean booking model, overlap checks, and how you stop double booking under concurrency.
- Design an app that splits shared expenses among friends and shows who owes whom.Expenses, splits (equal, exact, percentage) as swappable strategies, and simplifying balances.
- Design the controller for a bank of lifts in a tall building.Lift state, request queues, a scheduling policy you can replace, and what happens when a lift is out of service.
- Design a rate limiter class that different API routes can configure with their own limits.An interface for the limiting algorithm, per-key state, and thread safety.
- Design a simple library system where members borrow, reserve and return books, with late fees.Clear entities, a reservation queue, and fee rules kept out of the core borrowing flow.
How a Revvox LLD mock runs
- Five minutes: the problem. The interviewer names a system in a sentence. You ask what it must support, who uses it and what is out of scope.
- Ten minutes: the model. You name the main classes, their responsibilities and relationships, and sketch the key interfaces before writing code.
- Twenty-five minutes: the code. You implement the core flow in a shared code pad in the language you choose, keeping it runnable and readable.
- Ten minutes: the change. A new requirement arrives. You show where it fits, what you would change, and what stays untouched. Concurrency questions often come here.
- Ten minutes: feedback out loud. The interviewer tells you how it went while it is fresh. The written report, with marks and next steps, follows within 24 hours.
How to prepare
- Revise the SOLID principles until you can say, for each one, what goes wrong in code that breaks it.
- Know a handful of patterns by their purpose, not their name: strategy for swappable rules, observer for notifications, factory for creating related objects, state for objects whose behaviour depends on their status.
- Design four or five classic problems end to end in code: a parking lot, an LRU cache, a rate limiter, a library system, a bill-splitting app. Time each one to 45 minutes.
- After each one, add a requirement yourself and see how much code you had to change. That is the test the interviewer will run.
- Learn the basics of thread safety in your language: locks, atomic counters and when shared state needs protecting.
Common mistakes we see
- Starting with a dozen classes, most of which never get used. Fewer, clearer objects score better.
- Using patterns to show you know them, not because the problem needs them.
- Putting all the logic in one manager class, so every change touches the same file.
- Running out of time with no working code in a machine coding round.
- Ignoring concurrency when two users can book the same slot or take the same item.