Design a Vending Machine

A vending machine is one of the most detailed prompts reported from VMware's low-level design round. Scale doesn't come into it. The interviewer watches whether you can turn an everyday device into a clean set of classes. Then they watch whether those classes stay correct as money goes in, a product comes out, and change is returned. The reported version arrives already loaded, which makes it a strong prompt. Accept coins or notes, hold products in slots with prices and stock, and dispense on a valid selection. Return the right change, and be ready to extend it with an operator who restocks, a second currency or a refund. The whole conversation is the modeling: which entities exist, how they relate, and where the behavior lives.

The machine earns its place because every layer of the skill shows up. There's entity modeling. Products, slots, coins and a transaction are nouns sitting in the prompt, waiting to be named. There's behavior with real ordering. You can't select before money is in, and you can't dispense while a previous sale is mid-flight. So the design has to encode a sequence, beyond a set of methods. There's arithmetic that has to be exact. Change is money owed back, and a machine that miscounts it shorts a customer. And there's extensibility, because the interviewer will add a requirement partway through and grade whether your abstractions bend or break. Model those cleanly and the design reads as production code. One giant class with a pile of boolean flags, the ordering rules smeared across it, reads like a paper sketch.

The VMware angle

VMware builds infrastructure that engineers who never met the author extend for years. So its low-level round grades whether your code survives the requirement you weren't asked for. A vending machine probes that instinct in miniature. The reported prompt is deliberately open-ended. It names an operator and an admin, product and currency management, and a central config. Then it asks you to extend it to more roles and another currency.