Requirements checklist

Ask by narrating one purchase — the story surfaces the states:

□ states + exits                  idle/collecting/dispensing; cancel & sold-out exits
□ money: denominations + units    fixed set; INTEGER minor units — volunteer this
□ exact-change scenario           refuse & refund, never shortchange — volunteer it
□ cancel semantics                any time before dispense; full refund
□ inventory & sold-out            per-slot stock; blocks selection at zero
□ operator scope                  restock/collect/service mode — name it, defer it
□ hardware boundary               events in (coin, selection), commands out

The core model

State machine     IDLE -> COLLECTING -> DISPENSING -> IDLE
                  one transition layer; states handle ONLY their legal events
Ledgers (x3)      inserted (refundable) | change float | cash box
                  one CoinBundle type, three never-blurred instances
ChangeMaker       make(amount, from) -> coins | empty (= refuse sale)
                  feasibility and execution are the SAME call
Dispense invariant  stock > 0  AND  balance >= price  AND  change makeable
                    — all three BEFORE the point of no return
Inventory         consulted by collecting; owns stock; restock lands here

Principles, at their decisions

• Single responsibility (behavioral): each state answers only for its own legal events; illegal pairs have nowhere to hide.
• Separation of concerns: change-making is a component with an algorithm and a correctness caveat — greedy is denomination-dependent — not three lines in dispense.
• Make illegal states unrepresentable: explicit states instead of boolean soup; Dispensing has no cancel method to call incorrectly.

Complexity facts

event handling   O(1) — a state dispatch
change-making    greedy O(denominations); DP fallback O(amount x denoms)
                 greedy is CORRECT only for canonical denomination sets — say it
memory           O(denominations + slots)

What earns points, per report dimension

• Requirements & interface — you narrated a purchase to surface states, volunteered the integer-money and exact-change rules, and scoped the operator.
• Core design & invariants — explicit states, three ledgers, the three-part dispense invariant stated unprompted.
• Extension probe — the round will move the requirements; locate the change at a seam, narrate what transitions/components change and what provably doesn't.
• Complexity honesty — the greedy caveat named with its trigger for the DP upgrade.
• Communication — money rules and refusal semantics said out loud before anyone asked.

Ready? Sit the live mock → — the interviewer will run a twist this chapter deliberately hasn't shown you.