Vending Machine – Low Level Design Interview Practice
Practise the Vending Machine low level design problem the way an LLD round actually runs. You are asked for requirements first, then a class model, and then to extend the design when a new requirement lands part way through – the follow-up that separates a design that was memorised from one that was understood.
The round checks the things interviewers grade: whether your classes carry single responsibilities, whether you reached for a design pattern or reinvented one, whether the design absorbs a new requirement without rewriting what exists, and whether you can explain a trade-off out loud. Feedback covers class modelling, SOLID principles, use of patterns, extensibility and communication.
What this question is really testing
The canonical State pattern interview. The grade is whether illegal transitions are impossible by construction or merely guarded by conditionals.
Requirements to establish first
- Accept coins and notes, and track the amount inserted so far.
- Select a product, reject the selection if the balance is short or the slot is empty.
- Dispense the product and return change, or refund everything on cancel.
- Track inventory per slot and refuse a sold-out selection.
- Return change in the fewest coins the machine actually holds, not the fewest in theory.
Core classes
- VendingMachine – Holds the current state and delegates every action to it.
- State – Idle, HasMoney, Dispensing, OutOfService - each implementing insert, select, dispense, cancel.
- Inventory – Slot to product and count. The one place stock is decremented.
- Product / Slot – Code, price and the physical position holding it.
- ChangeDispenser – Owns the coin float and the change-making decision.
Design patterns that apply
- State – The whole problem. Insert-coin means something different in Idle than in Dispensing, and the point of the pattern is that the second case cannot be reached by accident.
- Strategy – Change-making: greedy is correct for standard denominations and wrong for arbitrary ones. Making it swappable is the honest answer.
- Factory – Creating states, if you want the machine to depend on the interface rather than on every concrete state class.
Follow-up questions to expect
- The machine cannot make exact change. Does it refuse the sale before or after taking the money, and which state is that?
- Add card payment. Is that a new state, a new Strategy on the existing states, or neither?
- Power is lost mid-dispense. What does your state model say about recovery?
Where candidates lose marks
- An enum plus a switch statement. That is a state machine written as conditionals, and it is the thing the question is checking for.
- Greedy change-making presented as correct without naming the denominations it holds for.
- Decrementing stock on selection rather than on successful dispense, so a failed vend loses a unit.