## 1. 🍕 What is a pizza price calculator? A pizza price calculator works out what a pizza costs as you build it up. You start from a size and a crust, which sets a base price, and then you add toppings one at a time. Every topping you add raises the running total and extends the description, and the price of a topping can change with the size of the pizza, so pepperoni on a large costs more than the same pepperoni on a small. In a real ordering flow the calculator does more than price one pizza. A customer puts several things into an order at once, a couple of pizzas plus a drink and a side of wings, and the order reports the cost of everything together. A coupon might then take a fixed amount off, take a percentage off, or give one item free when you buy another. The job is to price each item correctly, add them up, and apply the right discount to the whole order in a way that stays predictable as new toppings, new item kinds, and new coupon types keep arriving. ## 2. Requirements Before modeling a single class, it is worth pinning down what the calculator must do and where the boundary sits. The core tension is not the menu, it is that a topping costs different amounts on different sizes and that new toppings, item kinds, and coupons keep arriving. ### Clarifying Questions ::::qa-item :::you[You] "Are we pricing a single pizza, or a whole order that can hold other things like drinks and snacks alongside pizzas?" ::: :::interviewer[Interviewer] "Both. A pizza reports its own cost, but an order can hold several items, including non-pizza ones, and report the total of everything in it." ::: :::takeaway[Takeaway] A pizza cannot be the only thing the system totals, so we need a shared notion of a priced thing that an order can hold uniformly. ::: :::: ::::qa-item :::you[You] "Does a topping have one flat price, or can the same topping cost more on a large than on a small?" ::: :::interviewer[Interviewer] "The topping price can depend on the size. Pepperoni on a large costs more than pepperoni on a small." ::: :::takeaway[Takeaway] A topping is not a dumb number, it has to know the size it is being priced against. That single answer decides whether a topping is a plain value or something that reads the pizza it sits on. ::: :::: ::::qa-item :::you[You] "Will new toppings, item kinds, and coupon types keep getting added, and should adding one avoid editing the existing pricing code?" ::: :::interviewer[Interviewer] "Yes. Adding a new topping or a new coupon should not mean rewriting how a pizza or an order already prices itself." ::: :::takeaway[Takeaway] This makes open-for-extension the headline pressure: new toppings and coupons should avoid rewiring the core pizza or order pricing flow, even if the baseline topping model extends shared enums and price metadata. ::: :::: ::::qa-item :::you[You] "For a buy-one-get-one-free coupon, does the discount need to look at the actual items, or is the running total enough?" ::: :::interviewer[Interviewer] "It has to look at the real items. A buy-one-get-one-free coupon discounts a specific item, the cheapest one, so the running total alone is not enough." ::: :::takeaway[Takeaway] At least one coupon must see the whole item list, not just a number, so a discount cannot live on a single pizza. It has to apply where the full set of items is visible. ::: :::: ::::qa-item :::you[You] "What should happen on bad input, like an unknown topping or a coupon that would push the total below zero?" ::: :::interviewer[Interviewer] "Reject it with a clear error rather than a wrong price. A discount can take the total to zero but never below, and totalling an empty order is an error." ::: :::takeaway[Takeaway] Pricing has guarded edges: unknown inputs fail at the point of misuse and the total is floored at zero. These checks belong where the relevant state lives. ::: :::: ### Functional requirements - A pizza is built from exactly one size and one crust type and can report its running cost and a human-readable description. - A pizza can have zero or more toppings added, and each added topping raises the cost and extends the description. - A topping's price can depend on the pizza size, so the same topping costs a different amount on a small vs. a large. - An order holds one or more items and reports its total by summing the cost of every item it contains. - An order can hold non-pizza items such as a drink or a snack alongside pizzas, and totals them the same way. - A coupon can be applied to an order to reduce its total, covering at least a fixed-amount and a percentage discount. - A buy-one-get-one-free coupon inspects the actual items in the order and discounts the cheapest one. - Invalid input, such as an unknown size or topping, an empty order, or a discount that would drive the total below zero, is rejected with a clear error. ::::collapse[Out of scope]{variant="warning"} - Persistence, databases, or schema design (this is an in-memory object model). - Networking, REST, distributed coordination, sharding, or horizontal scaling. - Concurrency and thread-safety (an order is built and totalled in one thread). - Real payment-processor integration (payment is named as a seam only, not built). - Tax and delivery-fee computation as built features (named as order-level extension points). - Membership, loyalty points, and combo-meal bundling (named as extension points). - Half-and-half and per-slice spatial topping allocation (named as an extension point). - Inventory, kitchen workflow, order tracking, checkout, accounts, and admin tooling. - User interface, rendering, and menu presentation. :::: ## 3. Choosing the Core Objects With scope settled, the move before any code is to turn this menu of nouns into the handful of objects that actually carry price and behavior. Which candidates earn a class, which collapse into an enum or a parameter, and which we drop? A few nouns jump out of the requirements: pizza, base pizza, topping, size, crust type, item, order, coupon, drink, snack, store, and money. Some are real objects, some only look like objects on first read. Let us test them one at a time. - `Pizza` is the shared contract every layer answers, since a fully built pizza must report a cost and a description just like the base it started from. It stays. - `BasePizza` is the starting point of any pizza: it holds the size and crust and knows the size-based base price, the bottom of the build-up, so it earns its own object. - `ToppingDecorator` is the part that makes this problem interesting. A topping wraps a `Pizza` and adds its own size-dependent price on top, pricing itself in the context of the pizza it sits on. - `Item` is the abstraction that lets an order hold pizzas, drinks, and snacks side by side and total them the same way. A shared "knows its own price" contract earns its place, and `Pizza` will implement it. - `Order` is the natural orchestrator. It is the only thing that knows the full set of items, so totalling them and applying a coupon is its job. - `CouponStrategy` survives as a seam because the requirements expect discounts to vary (fixed, percentage, and the item-inspecting buy-one-get-one-free). That leaves the candidates that look like entities but are not. `Size` (`SMALL`, `MEDIUM`, `LARGE`) and `CrustType` (`THIN`, `HAND_TOSSED`, `DEEP_DISH`) are closed sets with no behavior, so they become enums that key into the base price. `ToppingType` (`PEPPERONI`, `MUSHROOM`, `OLIVE`) is also a closed set keyed to a per-size price table, so one `ToppingDecorator` covers every topping instead of a class per topping. `Money` is just a numeric amount the methods return, not a rich class at the baseline. `Store` is config we inject as a price source for the store-pricing extension. `Drink` and `Snack` are real, but we introduce them in extensibility to prove the `Item` seam works. `Customer`, `Cart`, and `Payment` drop out entirely. One candidate is worth slowing down on, because most people reach for it first: a flat `Pizza` class that just holds a `List` field and prices the list itself. The trouble is that a flat pizza has to own a topping-by-size price matrix and learn about every new topping, which breaks open-closed the moment a new topping or a size-specific rule arrives. ::::collapse[Bad Solution: A flat Pizza with a list of toppings the pizza prices]{variant="bad"} This approach makes `Pizza` a single class with a `size` field, a `crust` field, and a `List`. To price itself, `Pizza.getCost` loops the list and looks up each topping's price in a topping-by-size table the pizza owns. It breaks because the pizza now knows about every topping in existence. Adding pepperoni-on-large pricing or a brand-new topping forces an edit to the pizza class and its table, exactly the open-closed violation the requirements warned about. Worse, a fully built pizza is a special shape with a list inside it, not the same kind of object as a plain base, so it is awkward to treat as just another priced item in an order. :::: ::::collapse[Good Solution: Each topping wraps a Pizza and prices itself]{variant="good" open} This approach keeps one shared `Pizza` contract every layer answers. `BasePizza` is the bottom layer carrying size and crust, and each topping is a thin wrapper around a `Pizza` that adds its own size-aware price on top of whatever is inside. Cost becomes a recursion down the chain rather than a loop the pizza owns. It wins because the variation lives where the variation actually is. Each topping carries its per-size pricing data and reads the size from the pizza it wraps, so adding a new topping extends the topping catalog and price table without changing how `Pizza`, `BasePizza`, or `Order` work. Every layer answers the same cost-and-description contract, so a fully built pizza is just another priced thing an order can hold next to a drink. :::: That one decision shapes everything downstream: the toppings compose rather than sit in a list, and the order treats a pizza as just another item. Here is the kept set and each object's role. | Entity | Role | |--------|------| | `Order` | Orchestrator. Holds the list of items, sums their cost, and applies one coupon. | | `Pizza` | The shared contract every base and topping layer answers (cost and description). | | `BasePizza` | The bottom of the chain. Owns size and crust and returns the size-based base price. | | `ToppingDecorator` | Wraps a `Pizza` and adds its own size-dependent topping price and description. | | `Item` | The abstraction that lets an order hold pizzas, drinks, and snacks uniformly. | | `CouponStrategy` | The order-level discount seam (fixed, percentage, buy-one-get-one-free). | ::img[Entity relationship map]{src="https://assets.hack2hire.com/post/6a22e5c9981072682a6f22da/cbf1946c-30d9-4363-9290-421a79231df2_20260605.svg"} ## 4. Shaping the Class Design The objects are named, so the real work now is deciding how a pizza builds up its price as toppings get added, and where a whole-order discount belongs. We start with the pizza, because the way toppings attach is the decision everything else leans on. Even before any pattern vocabulary the plan is simple: a pizza begins as a base with a size and a crust, and adding a topping should make it cost a little more and read a little longer. We work top-down, settling how a topping attaches first, then the size-aware twist, then the order and the coupon on top. ### The pizza contract and the base A pizza has to answer two questions at any point in its build-up: what does it cost so far, and what is on it. The base pizza is where that build-up starts. Pull the state straight from the requirements: a pizza is built from exactly one size and one crust, and the size sets the base price. So the base owns a `Size` and a `CrustType` and nothing else, and the two questions become two methods on a shared contract every later layer also answers. We name that contract `Pizza`, because both the plain base and a fully topped pizza are, from the outside, just a thing that knows its cost, its size, and its description. ```js interface Pizza: + getCost() -> Money + getSize() -> Size + getDescription() -> String class BasePizza: - size: Size - crust: CrustType + BasePizza(size, crust) + getCost() -> Money + getSize() -> Size + getDescription() -> String ``` `BasePizza.getCost()` is a single lookup of the base price for its size, and `getDescription` reads back the size and crust. Keeping the base this thin matters: it is the only layer that knows about base pricing, so every other concern, especially toppings, attaches from the outside rather than reaching in. ### Adding a topping as a layer Anchor the simplest mental model: a pizza is a base plus some toppings, so keep a list of toppings on the pizza and loop them when pricing. That works for the smallest version of the problem, but it breaks the moment the prompt's two real pressures arrive at once. Size-dependent pricing would force the pizza to own a topping-by-size table, and open-for-extension would force an edit to the pizza for every new topping. Both point the same way: the topping, not the pizza, should own how it prices itself. The escalation is to make each topping a thin layer wrapped around a `Pizza` that adds its own price on top of whatever is already inside. This is the *Decorator Pattern*, worth naming because it is doing real work here, not decoration for its own sake. In the shipped code, that pattern shows up as one reusable `ToppingDecorator` plus topping enums and per-size price metadata, so the main open-closed win is that pizza-pricing flow stays stable even as the topping catalog grows. Its benefit over the flat list is uniform composition, every layer is just a `Pizza`, so cost becomes a recursion down the chain. ```js class ToppingDecorator: - innerPizza: Pizza - topping: ToppingType + ToppingDecorator(innerPizza, topping) + getCost() -> Money + getSize() -> Size + getDescription() -> String ``` The one field that does the work is `innerPizza`, the `Pizza` this topping wraps. Because the wrapped thing is itself a `Pizza`, a `ToppingDecorator` can wrap a `BasePizza` or another `ToppingDecorator` without caring which, and that is what lets toppings stack. ### The size-aware twist So far a topping could just add a flat number. But the prompt says pepperoni costs more on a large than a small, so a single number is wrong. The topping needs the size, which lives on the base pizza buried inside the chain. The decorator already holds a reference to the `Pizza` it wraps, so it reads the size from there and looks up its own per-size price. Concretely, each topping type carries a small per-size price table, and `ToppingDecorator.getCost()` reads the wrapped pizza's size, looks up its price for that size, and adds it to the wrapped pizza's cost. This is the distinctive decision of the problem: the per-size price is intrinsic to the topping, read against the pizza it sits on. > [!TIP] > In the interview I would say: "A topping reads the size from the pizza it wraps and carries per-size pricing data, so pepperoni-on-large is just a table lookup through the topping layer. The pizza and order logic never learn special-case pepperoni rules, which is why the topping catalog can grow without rewriting those classes." To recap before we widen out: the base owns size, crust, and base price, and each topping is a wrapper that reads that size and adds its own size-priced amount. That is the whole pizza model, two small classes behind one contract, and cost is recursion down the wrappers. Everything from here treats a finished pizza as a single priced thing. :::img[Why pricing lives in decorators and discounts live on the order]{src="https://assets.hack2hire.com/post/6a22e5c9981072682a6f22da/e7271066-70ce-436b-a234-78e21b9e26f3_20260607.svg"} ### Treating a pizza as just another item The next requirement is that an order can hold drinks and snacks next to pizzas and total them the same way. Special-casing each kind on the order means its total logic changes every time a new kind shows up. The cleaner move is a shared contract that says "this thing knows its own price," so the order holds a mixed list and treats every element identically. That contract is `Item`. A `Pizza` already knows its cost, so making `Pizza` an `Item` costs nothing, and a drink or snack is just another `Item` that returns its own price. The order then depends only on `Item`, never on the concrete kinds inside it. ```js interface Item: + getCost() -> Money + getDescription() -> String // Pizza realizes Item, so a fully built pizza is one Item among many. ``` We use this seam because the requirements explicitly promise new item kinds will arrive. Naming `Item` now means the order's total logic is closed to that change before the change shows up, which is the payoff we cash in during extensibility. ### The order: totalling and one coupon `Order` is the orchestrator. It owns the one piece of state nothing else can hold honestly, the full list of items, plus the single coupon applied to that list. From the requirements, it adds items, sums their cost, and applies a discount to the whole order, rejecting an empty order and never returning a total below zero. ```js class Order: - items: List - coupon: CouponStrategy + addItem(item: Item) -> void + applyCoupon(coupon: CouponStrategy) -> void + getItems() -> List + subtotal() -> Money + calculateTotal() -> Money ``` The order holds `items` because it is the only object that sees the whole set, so totalling and discounting are its job and each item only knows how to price itself. It holds at most one `coupon` as a swappable policy rather than baking discount rules into the total, which sets up the last and most interesting decision: where a discount is even allowed to live. ### Where should a discount live? A discount has to reduce the order's total, but the question is which object owns that logic. The naive move is to subtract from a pizza's cost or fold the discount into an item's `getCost`. That falls apart the moment you look at the two coupons the prompt actually requires. ::::collapse[Bad Solution: Discount logic on the pizza or inside each item]{variant="bad"} This approach puts the discount where the price is: a pizza or an item knows how to discount itself, so `getCost` returns an already-reduced number. The appeal is locality, the thing that has the price also takes the cut. It breaks on both required coupon kinds. A percentage discount is naturally whole-order, but a single item cannot see the order total, so a percent-off rule has nowhere honest to live. Worse, a buy-one-get-one-free coupon has to compare items to find the cheapest one to give away, and an item pricing itself in isolation cannot see the others. Pushing discounts down to the item also means every new coupon kind risks editing every item, the open-closed problem again. :::: ::::collapse[Good Solution: An order-level CouponStrategy that sees the whole order]{variant="good" open} This approach makes the coupon a swappable rule the order runs over its items: a `CouponStrategy` that takes the whole `Order` and returns the discounted total. Fixed-amount, percentage, and buy-one-get-one-free are all just different strategies plugged into the same seam. It wins because the discount finally sits where it can see what it needs. A percentage rule reads the running total, and a buy-one-get-one-free rule scans the actual items, both only possible at the order level. New coupon kinds land as new strategies without touching the order or any item, the open-for-extension promise honored where the requirements demanded it. This is the *Strategy pattern*, earned because the prompt expects discount policy to vary and buy-one-get-one-free forces whole-order visibility, not added speculatively. :::: > [!TIP] > In the interview I would introduce the coupon seam only after the buy-one-get-one-free requirement, because that is the moment it becomes obvious a discount must see the whole order. I would say: "Fixed and percentage could almost live anywhere, but buy-one-get-one-free has to inspect the items, so I am putting all discounts behind one order-level strategy." That settles the discount seam. A `CouponStrategy` exposes one method, `applyDiscount(order)`, and the concrete coupons differ only in how they compute the cut. ```js interface CouponStrategy: + applyDiscount(order: Order) -> Money class FixedAmountCoupon: - amount: Money + applyDiscount(order: Order) -> Money class PercentageCoupon: - percent: int + applyDiscount(order: Order) -> Money class BogoCoupon: + applyDiscount(order: Order) -> Money // [New] Scans the order's items, so it needs the whole order, not just the total. ``` ### Final class design Pulling it together, here is the full baseline design in one place: the pizza contract and its two layers, the `Item` seam, the order, the coupon seam with its three variants, and the enums. The diagram that follows renders the same set as a full *Unified Modeling Language (UML)* class diagram so the fields, methods, and relationships are visible at a glance. ```js interface Pizza: + getCost() -> Money + getSize() -> Size + getDescription() -> String interface Item: + getCost() -> Money + getDescription() -> String class BasePizza: - size: Size - crust: CrustType + getCost() -> Money + getSize() -> Size + getDescription() -> String class ToppingDecorator: - innerPizza: Pizza - topping: ToppingType + getCost() -> Money + getSize() -> Size + getDescription() -> String class Order: - items: List - coupon: CouponStrategy + addItem(item: Item) -> void + applyCoupon(coupon: CouponStrategy) -> void + getItems() -> List + subtotal() -> Money + calculateTotal() -> Money interface CouponStrategy: + applyDiscount(order: Order) -> Money class FixedAmountCoupon: - amount: Money + applyDiscount(order: Order) -> Money class PercentageCoupon: - percent: int + applyDiscount(order: Order) -> Money class BogoCoupon: + applyDiscount(order: Order) -> Money enum Size: SMALL MEDIUM LARGE enum CrustType: THIN HAND_TOSSED DEEP_DISH enum ToppingType: PEPPERONI MUSHROOM OLIVE ``` ::img[Full UML class diagram]{src="https://assets.hack2hire.com/post/6a22e5c9981072682a6f22da/63987b3a-0518-4f2d-927f-36223c54f3ec_20260605.svg"} ## 5. Key Flow Walkthroughs The class boundaries are set, so now we trace what runs when a pizza is asked for its price and an order for its total. Only four moments are worth walking: a topping pricing itself down the chain, the description building up the same way, the order summing its items, and a coupon taking its cut at the end. The one discipline throughout is guard before you compute, so the failure checks come before any arithmetic. > [!TIP] > Before diving in, check with your interviewer. Some want working code, others prefer pseudocode, and some just want you to talk through the logic. We will use reader-friendly structural pseudocode here, then give a complete compilable reference implementation at the end. ### Pricing a topping down the chain This is the heart of the design, worth the most interview time. A `ToppingDecorator` does not own the full price, it adds its slice and asks the layer it wraps for the rest. Walking it shows the recursion and the exact spot where size-dependent pricing happens. - read the size from the wrapped pizza, since the topping prices itself against that size - reject an unknown topping or an unpriced size with a clear error - add this topping's size-priced amount to whatever the wrapped pizza already costs ```js getCost() innerCost = innerPizza.getCost() size = innerPizza.getSize() price = priceTable.lookup(topping, size) if price == null throw error("No price for " + topping + " on " + size) return innerCost + price ``` The non-obvious choice is that the decorator reads `size` from `innerPizza` rather than storing its own. That is what makes the chain work: every wrapper delegates inward until `BasePizza` returns the base price, and each layer adds its size-aware slice on the way back out. ::img[Responsibility flow: getCost down the decorator chain]{src="https://assets.hack2hire.com/post/6a22e5c9981072682a6f22da/e0993480-6cac-49a1-a273-1226c3dbe222_20260605.svg"} ### Reading back the description The description is the companion recursion, worth a quick look because it proves the same composition shape carries more than price. Each layer appends its own contribution to whatever the inner layer already describes, so the readout builds up in the order the toppings were added. ```js getDescription() return innerPizza.getDescription() + ", " + topping ``` The lesson here is small but important for the interview: cost and description travel the exact same path. If you can explain one recursion, you have explained both, and that is a sign the decorator is carrying the design rather than being decoration. ### Totalling an order with a coupon This method is where the `Item` seam pays off. It sums heterogeneous items, then hands the order to its coupon, with the empty-order and never-below-zero edges handled before anything is returned. - reject an empty order, since totalling nothing is a misuse, not a zero - sum `getCost` over every item, treating a pizza, a drink, and a snack identically - if a coupon is set, let it compute the discounted total, then floor the result at zero ```js calculateTotal() if items.isEmpty() throw error("Cannot total an empty order") subtotal = 0 for item in items subtotal = subtotal + item.getCost() if coupon == null return subtotal discounted = coupon.applyDiscount(order) if discounted < 0 return 0 return discounted ``` The choice worth defending is that `calculateTotal` never looks inside an item or a coupon. It loops the `Item` contract and delegates the discount to the `CouponStrategy`, so a new item kind or a new coupon kind changes nothing here. The floor-at-zero guard lives at the order level because that is the only place that knows the final number. ### A buy-one-get-one-free coupon The fixed and percentage coupons only need the running total, so they are nearly trivial. The buy-one-get-one-free coupon is the one with teeth, because it has to inspect the actual items to find the cheapest one to give away free. Walking it shows why the coupon seam takes the whole order instead of just a number. - compute the subtotal so the discount has a baseline to reduce - it takes two items to give one away, so return early when the order holds fewer than two - scan the items for the cheapest one, then subtract its cost from the subtotal ```js applyDiscount(order) subtotal = order.subtotal() items = order.getItems() if items.size() < 2 return subtotal freeItem = cheapest(items) return subtotal - freeItem.getCost() ``` The teaching point is the loop over `order.getItems()`. A fixed or percentage coupon could work off `order.subtotal()` alone, but buy-one-get-one-free cannot, and that single difference is the whole argument for putting discounts at the order level. If the coupon only received a total, this coupon would be impossible to write. ::img[Responsibility flow: Order.calculateTotal()]{src="https://assets.hack2hire.com/post/6a22e5c9981072682a6f22da/c1b6ec8f-820a-4f79-a44c-e8689b5f2940_20260605.svg"} ### A concrete example Before moving on, it is worth running one order end to end, because this is where the two recursions and the order-level discount stop being theoretical and you can see them line up on a single example. Watch how the same `getCost` call drives both the pizza chain and the order sum, and where the coupon enters only once, at the very end. - build a large thin-crust `BasePizza`, then wrap it in a pepperoni `ToppingDecorator`, then a mushroom one - ask the outer pizza for `getCost`: mushroom adds its large price, delegates to pepperoni, which adds its large price, which delegates to the base for the large base price - the order holds that pizza plus a `Drink`, and `calculateTotal` sums both through the same `Item.getCost` call, never knowing one is a three-layer chain and the other a flat drink - apply a `PercentageCoupon` of ten percent: only now does the discount run, against the full subtotal, and the floor-at-zero guard stands ready The ordering is the lesson. The pizza's price is fully resolved by recursion before the order sums anything, and the coupon runs exactly once after the subtotal exists, never per item. Reverse that, applying the discount inside the item loop, and a percentage coupon would silently compound per item. That single ordering is the payoff of the earlier decision to keep pricing on the layers and discounting at the order. ### Complete code implementation Here is the full baseline implementation in Java and Python, covering the decorator chain, the `Item` seam, the order, and the fixed, percentage, and buy-one-get-one-free coupons. ::::code :::java import java.util.*; enum Size { SMALL, MEDIUM, LARGE } enum CrustType { THIN, HAND_TOSSED, DEEP_DISH } enum ToppingType { PEPPERONI, MUSHROOM, OLIVE } // Shared contract for any priced thing an order can hold. interface Item { int getCost(); String getDescription(); } // Shared contract every base and topping layer answers. interface Pizza extends Item { Size getSize(); } // Base price per size, in cents. class BasePrices { static final Map BASE = Map.of( Size.SMALL, 800, Size.MEDIUM, 1000, Size.LARGE, 1200); } // Per-size price table for each topping, in cents. class ToppingPrices { static final Map> TABLE = Map.of( ToppingType.PEPPERONI, Map.of(Size.SMALL, 150, Size.MEDIUM, 200, Size.LARGE, 250), ToppingType.MUSHROOM, Map.of(Size.SMALL, 100, Size.MEDIUM, 125, Size.LARGE, 150), ToppingType.OLIVE, Map.of(Size.SMALL, 80, Size.MEDIUM, 100, Size.LARGE, 120)); static int lookup(ToppingType topping, Size size) { Map bySize = topping == null ? null : TABLE.get(topping); if (bySize == null) { throw new IllegalArgumentException("Unknown topping: " + topping); } Integer price = bySize.get(size); if (price == null) { throw new IllegalArgumentException("No price for " + topping + " on " + size); } return price; } } class BasePizza implements Pizza { private final Size size; private final CrustType crust; BasePizza(Size size, CrustType crust) { Integer base = size == null ? null : BasePrices.BASE.get(size); if (base == null) { throw new IllegalArgumentException("Unknown size: " + size); } this.size = size; this.crust = crust; } public Size getSize() { return size; } public int getCost() { return BasePrices.BASE.get(size); } public String getDescription() { return size + " " + crust + " pizza"; } } // Each topping wraps a Pizza and adds its own size-dependent price. class ToppingDecorator implements Pizza { private final Pizza innerPizza; private final ToppingType topping; ToppingDecorator(Pizza innerPizza, ToppingType topping) { this.innerPizza = innerPizza; this.topping = topping; } public Size getSize() { return innerPizza.getSize(); } public int getCost() { return innerPizza.getCost() + ToppingPrices.lookup(topping, innerPizza.getSize()); } public String getDescription() { return innerPizza.getDescription() + ", " + topping; } } // A plain non-pizza item that knows its own price. class Drink implements Item { private final String name; private final int price; Drink(String name, int price) { this.name = name; this.price = price; } public int getCost() { return price; } public String getDescription() { return name; } } // Swappable order-level discount policy. Returns the discounted total. interface CouponStrategy { int applyDiscount(Order order); } class FixedAmountCoupon implements CouponStrategy { private final int amount; FixedAmountCoupon(int amount) { this.amount = amount; } public int applyDiscount(Order order) { return order.subtotal() - amount; } } class PercentageCoupon implements CouponStrategy { private final int percent; PercentageCoupon(int percent) { this.percent = percent; } public int applyDiscount(Order order) { int subtotal = order.subtotal(); return subtotal - (subtotal * percent) / 100; } } // Buy-one-get-one-free must inspect the actual items, not just the total. class BogoCoupon implements CouponStrategy { public int applyDiscount(Order order) { int subtotal = order.subtotal(); List items = order.getItems(); if (items.size() < 2) { return subtotal; } Item cheapest = items.get(0); for (Item item : items) { if (item.getCost() < cheapest.getCost()) { cheapest = item; } } return subtotal - cheapest.getCost(); } } class Order { private final List items = new ArrayList<>(); private CouponStrategy coupon; void addItem(Item item) { items.add(item); } void applyCoupon(CouponStrategy coupon) { this.coupon = coupon; } List getItems() { return Collections.unmodifiableList(items); } int subtotal() { int subtotal = 0; for (Item item : items) { subtotal += item.getCost(); } return subtotal; } int calculateTotal() { if (items.isEmpty()) { throw new IllegalStateException("Cannot total an empty order"); } if (coupon == null) { return subtotal(); } int discounted = coupon.applyDiscount(this); return Math.max(0, discounted); } } ::: :::python from abc import ABC, abstractmethod from enum import Enum class Size(Enum): SMALL = "SMALL" MEDIUM = "MEDIUM" LARGE = "LARGE" class CrustType(Enum): THIN = "THIN" HAND_TOSSED = "HAND_TOSSED" DEEP_DISH = "DEEP_DISH" class ToppingType(Enum): PEPPERONI = "PEPPERONI" MUSHROOM = "MUSHROOM" OLIVE = "OLIVE" # Base price per size, in cents. BASE_PRICES = {Size.SMALL: 800, Size.MEDIUM: 1000, Size.LARGE: 1200} # Per-size price table for each topping, in cents. TOPPING_PRICES = { ToppingType.PEPPERONI: {Size.SMALL: 150, Size.MEDIUM: 200, Size.LARGE: 250}, ToppingType.MUSHROOM: {Size.SMALL: 100, Size.MEDIUM: 125, Size.LARGE: 150}, ToppingType.OLIVE: {Size.SMALL: 80, Size.MEDIUM: 100, Size.LARGE: 120}, } def lookup_topping_price(topping, size): by_size = TOPPING_PRICES.get(topping) if by_size is None: raise ValueError(f"Unknown topping: {topping}") price = by_size.get(size) if price is None: raise ValueError(f"No price for {topping} on {size}") return price # Shared contract for any priced thing an order can hold. class Item(ABC): @abstractmethod def get_cost(self): ... @abstractmethod def get_description(self): ... # Shared contract every base and topping layer answers. class Pizza(Item): @abstractmethod def get_size(self): ... class BasePizza(Pizza): def __init__(self, size, crust): if size not in BASE_PRICES: raise ValueError(f"Unknown size: {size}") self._size = size self._crust = crust def get_size(self): return self._size def get_cost(self): return BASE_PRICES[self._size] def get_description(self): return f"{self._size.value} {self._crust.value} pizza" # Each topping wraps a Pizza and adds its own size-dependent price. class ToppingDecorator(Pizza): def __init__(self, inner_pizza, topping): self._inner_pizza = inner_pizza self._topping = topping def get_size(self): return self._inner_pizza.get_size() def get_cost(self): return self._inner_pizza.get_cost() + lookup_topping_price( self._topping, self._inner_pizza.get_size() ) def get_description(self): return f"{self._inner_pizza.get_description()}, {self._topping.value}" # A plain non-pizza item that knows its own price. class Drink(Item): def __init__(self, name, price): self._name = name self._price = price def get_cost(self): return self._price def get_description(self): return self._name # Swappable order-level discount policy. Returns the discounted total. class CouponStrategy(ABC): @abstractmethod def apply_discount(self, order): ... class FixedAmountCoupon(CouponStrategy): def __init__(self, amount): self._amount = amount def apply_discount(self, order): return order.subtotal() - self._amount class PercentageCoupon(CouponStrategy): def __init__(self, percent): self._percent = percent def apply_discount(self, order): subtotal = order.subtotal() return subtotal - (subtotal * self._percent) // 100 # Buy-one-get-one-free must inspect the actual items, not just the total. class BogoCoupon(CouponStrategy): def apply_discount(self, order): subtotal = order.subtotal() items = order.get_items() if len(items) < 2: return subtotal cheapest = min(items, key=lambda item: item.get_cost()) return subtotal - cheapest.get_cost() class Order: def __init__(self): self._items = [] self._coupon = None def add_item(self, item): self._items.append(item) def apply_coupon(self, coupon): self._coupon = coupon def get_items(self): return list(self._items) def subtotal(self): return sum(item.get_cost() for item in self._items) def calculate_total(self): if not self._items: raise ValueError("Cannot total an empty order") if self._coupon is None: return self.subtotal() discounted = self._coupon.apply_discount(self) return max(0, discounted) ::: :::: ## 6. Extensibility and Tradeoffs A clean pizza and a working order are the easy part. The real test is what happens when the interviewer adds drinks, coupons, and per-store prices, because that is where the seams either pay off or get exposed. You usually show where the change lands and which classes stay untouched rather than implementing it. ### Add drinks and snacks to an order The payoff being tested here is whether the `Item` seam was worth naming at the baseline. The requirement is to let an order hold a drink and a side of wings next to pizzas and total them uniformly. This lands in two brand-new classes and nothing else. A `Drink` and a `Snack` each implement `Item` and return their own price, and `Order.calculateTotal()` never changes because it only depended on the `Item` contract. ```js class Drink: - price: Money + getCost() -> Money // [New] Returns its own price with no chain involved. + getDescription() -> String ``` The boundary payoff is that `Order`, `Pizza`, `BasePizza`, `ToppingDecorator`, and every `CouponStrategy` stay closed. The polymorphic uniformity we paid for earlier means a new item kind is a leaf addition, not a ripple through the total logic. ### Add new coupon kinds If the interviewer asks for a new promotion, this is where the Strategy seam earns its keep. Say they want a "spend over thirty dollars, get five off" coupon on top of the ones already built. A new coupon is one new `CouponStrategy` implementation and an apply call, full stop. The order and items do not change, because the discount seam already takes the whole order. ```js class ThresholdCoupon: - threshold: Money - discount: Money + applyDiscount(order: Order) -> Money // [New] Reads the subtotal, applies discount if over threshold. ``` The important thing to say here is why no pattern escalation is needed: the Strategy pattern was already earned when buy-one-get-one-free forced whole-order visibility, so every later coupon is just another strategy. Reaching for a rules engine would be over-engineering this scope. ### Support free toppings as a promotion This scenario looks like it belongs on the pizza, and resisting that is the whole lesson. The requirement is a promotion that makes one topping free, and the tempting move is to teach `Pizza` about promotions. The better placement is the order level, a promotion that credits back a topping's price, modeled as another `CouponStrategy`. That keeps the decorator chain a pure cost-and-description object: the pizza still prices every topping honestly, and the order-level promotion subtracts the credit afterward. ```js class FreeToppingCoupon: - freeTopping: ToppingType + applyDiscount(order: Order) -> Money // [New] Credits back one topping's size-priced amount. ``` The reason this matters is responsibility placement. If free-topping logic lived on `Pizza`, every promotion would force an edit to the pizza and the toppings. Keeping it at the order level means `Pizza`, `BasePizza`, `ToppingDecorator`, and the order's core total all stay closed. ### Support per-store pricing The boundary tested here is whether prices can vary by store without the structure changing. The requirement is that the same item types cost different amounts at different stores. The fix is dependency injection of a price source, not a subclass per store. Inject a store-specific price source into construction so `BasePizza` and `ToppingDecorator` read prices from it instead of a hardcoded table. ```js class BasePizza: - size: Size - crust: CrustType - prices: PriceSource // [New] Injected per store instead of a hardcoded table. + getCost() -> Money ``` The payoff is that `Pizza`, `Order`, and `CouponStrategy` are untouched, and there is no `DowntownStore` or `AirportStore` subclass explosion. Injecting a price source keeps the behavior identical and swaps only the configuration, the right tradeoff whenever the variation is data rather than logic. ### Named but not built A few extensions are worth naming so the interviewer knows you see them, but building them would balloon scope without teaching more about the core composition. Half-and-half and double toppings push quantity and spatial allocation onto the chain, best handled with a quantity field on the decorator. Tax and a delivery fee are order-level concerns that slot in beside the coupon. A Builder or Factory could assemble standard pizzas like a Margherita instead of raw decorator stacking. Payment, membership points, and coupon stacking are each a separate seam, and bolting on a stacking engine or a full point-of-sale flow would trade the clean Decorator-plus-Strategy lesson for a pile of scope. ## 7. Interviewer Expectations ### Junior A junior candidate gets a pizza priced at all, the real baseline here. They produce a `Pizza` with a size, a crust, and toppings, write a `getCost` that adds the base price and each topping, and build an `Order` that sums its items. They usually keep toppings as a flat list and miss that the same topping should cost more on a large than a small, so the size-dependent pricing nuance only appears with a direct hint. The clearest signal at this level is a working total: build a pizza, add a couple of toppings, and have the order sum it correctly. ### Intermediate An intermediate candidate filters the nouns cleanly and reaches the right object set without much prompting: `Pizza`, `ToppingDecorator`, `Item`, `Order`, and a `CouponStrategy`. They get a topping adding its price on top of the pizza it wraps, compute an order total over a heterogeneous item list, and handle a fixed or percentage coupon correctly. Where they often need a nudge is the size-dependent pricing detail and the realization that buy-one-get-one-free cannot work off the total alone. You are passing here if you reach a correct layered pizza model and the `Item` seam on your own, with the decorator framing being a strong answer rather than the only acceptable wording. ### Senior A senior candidate drives the two decisions that define this problem before being asked. They reach for the decorator-shaped pizza chain and justify it out loud against the flat topping list, naming size-dependent pricing and topping-catalog growth as the pressures behind that choice. They name exactly the three seams that pay off, `Pizza`, `Item`, and `CouponStrategy`, without over-abstracting, and they place discounts at the order level specifically because buy-one-get-one-free must inspect the items. The clearest signal of senior thinking here is showing that a new item kind and a new coupon each land in one new class while `Order.calculateTotal()` and the pizza chain stay untouched, and that new toppings fit by extending the topping metadata carried by the shared decorator structure rather than rewriting that flow.