Loading…
Design a Vending Machine is a easy low-level design interview question covering low level design, object oriented design, state pattern, design patterns, state machine — the kind asked at FAANG (Facebook/Meta, Apple, Amazon, Netflix, Google) and AI-first companies like Anthropic, OpenAI, and Nvidia.
Design the software that runs a vending machine. It has slots labelled A1 through C8, each holding one product at one price with a count. It accepts coins and notes, gives change from whatever it is currently holding, and has a coin return button that works at any point before the product drops. Model the states, the money, and what happens when the machine cannot make change.
That's it. No further details. This is intentional — your first job is to scope the problem by asking the right clarifying questions.
The standard warm-up for a low-level design round, and the one question in the set where the interviewer is explicitly looking for a named pattern. A vending machine is a state machine where the same action means different things depending on where you are — pressing a product button with no money inserted is not the same event as pressing it with two coins in — and the whole question is whether a candidate represents that with types or with a nest of booleans. The second thing being tested is far less often prepared for: making change from a finite supply of coins is not the greedy algorithm most people reach for, and noticing that is what turns an average answer into a good one.
Work through the Clarify phase by asking questions one at a time — just like a real interview.
Each answer reveals why that question matters and how it changes your design decisions.
Once you've clarified enough, unlock the full class model, the code, and the trade-off analysis.
This is the standard vehicle for the state pattern, and the interviewer is looking for it by name. The same action means different things in different states: pressing a product button with no money inserted shows a price, and pressing it with two coins in attempts a sale. Model that with one class per state (Idle, AcceptingMoney, Dispensing, OutOfService) implementing a common interface, each returning the state the machine should move to. The machine itself becomes a context holding the data - slot inventory, coin float, escrow, current state - and its public methods are one line each, delegating to the state. The giveaway that this has been done properly is that the machine class contains no conditionals at all. Adding card payment later adds a method to the interface and the compiler names every state that must answer it, which is the argument for the pattern over an enum and a switch. Two details separate a good answer from an average one. First, coins inserted for the current sale belong in an escrow separate from the machine own float, merging only when a sale commits: that makes cancellation total, because a refund returns exactly the coins that were inserted and can never fail for lack of change. Merging them creates a machine that can take a coin, fail the sale, and be unable to refund what it just took. Second, making change from a finite float is not the greedy algorithm most candidates reach for. Greedy largest-first is only optimal for canonical coin systems and is never correct once a denomination runs out, so a bounded coin-change search over the actual holdings is the correct answer, and it is trivially fast at these sizes. The ordering that matters: check stock, then funds, then whether change can actually be made, and only then dispense - because a refund is possible and taking a product back is not. Weak answers put the change check after the product drops, model money as a floating point number, or track state with a set of booleans that permit combinations the machine can never physically be in.
A full interview loop is more than one round. These are the others, each with what is on the site for it.