Why this matters: the vending machine looks like the friendliest prompt in the machine-coding canon — everyone has used one. That familiarity is the trap. Candidates who "know" how a vending machine works skip the requirements conversation, start typing, and discover twenty minutes in that they never decided what happens when the machine can't make change. The machine is simple; the edges are the interview.

The prompt, as given

Design the software for a vending machine.

Coins go in, a selection gets made, a product drops, change comes back. The machine you are designing is the brain behind that: it decides what the hardware should do next, keeps the money honest, and knows what is in stock.

Notice what the prompt hands you and what it withholds. You get the happy path in one sentence. You get nothing about cancellation, sold-out products, insufficient money, or — the sharpest edge in the whole problem — what happens when the buyer has paid and the machine cannot return the difference.

The organizing question: walk the machine through one purchase

The single best opening move in this round is to narrate a purchase out loud and let the narration surface the states: "The machine sits idle. A coin arrives — now it's collecting money. A selection is pressed and the balance covers it — now it's dispensing. Product drops, change returns, back to idle."

That little story just did structural work: it produced a state enumeration, and every question that follows is really a question about states and the transitions between them. Interviewers notice candidates who organize the conversation this way, because the alternative — a pile of disconnected edge-case questions — produces a pile of disconnected if statements later.

"What are all the exits from a purchase?" Cancellation (buyer changes their mind) and sold-out (selection unavailable) are the two non-happy exits. Both end with money returned — ask and confirm.

"How does money work?" Cash, and this matters twice: which denominations exist (a fixed, configured set), and what unit amounts are stored in. The second one you should volunteer rather than ask: money is integers in minor units, never floats — saying it unprompted is a signal, because interviewers watch for the float mistake specifically.

"What if the machine can't make change?" This is the question that separates preparation from familiarity. The buyer inserts 20 for a 15 item; the machine holds no 5s. Something has to give: shortchange the buyer, swallow the difference, or refuse the sale and return the money. Our machine refuses and refunds — never shortchanges, never swallows. Whatever answer your interviewer gives, notice that it must be known before dispensing, which quietly shapes the transition logic you'll design next lesson.

"Can the buyer cancel mid-purchase?" Yes, any time before dispensing, with a full refund of everything inserted. Cancellation is a first-class transition, not an exception handler.

"Who restocks it?" An operator exists — restocking, cash collection, a service mode that locks buyers out. Scope it: acknowledge it needs to exist, place it out of v1, and move on. Volunteering that boundary saves ten minutes.

"Where does the hardware end and my software begin?" The best version of this question earns real points: you are designing the brain, not the coin reader. Hardware arrives as events (coin inserted, selection pressed) and your software issues commands (dispense, return coins). That boundary makes the whole design testable without a physical machine.

The requirement set this chapter builds against

States        idle -> collecting -> dispensing -> idle;
              cancelled and sold-out as exits back to idle
Money         cash only; fixed denominations (1, 2, 5, 10, 20);
              integer minor units everywhere
Exact change  cannot make change => REFUSE the sale, return money
Cancel        any time before dispensing; full refund
Inventory     per-product stock counts; sold-out blocks selection
Operator      exists (restock, collect cash, service mode) — out of v1
Hardware      abstracted: events in (coin, selection), commands out
              (dispense, return coins)

As with every chapter in this course: a live interviewer's answers may differ — maybe their machine holds the sale pending while a display asks for exact change, or their denominations differ. The conversation is the skill; this particular answer sheet is just the one we build against.