How to choose design patterns
The most common design-pattern mistake in an interview isn't picking the wrong pattern - it's going looking for a place to use one at all. A pattern is supposed to solve a specific, already-visible kind of pain. Used the other way round - "I should probably use a Factory here somewhere" before you've noticed anything that needs factoring - it adds indirection that buys nothing and reads to the interviewer as reciting vocabulary rather than solving their problem.
Let the pattern earn its place
The design principles page's "encapsulate what varies" is the whole test: is there a piece of this design that changes shape depending on a condition, and is that condition something the prompt actually gave you reason to expect will vary? If yes, a pattern is probably the disciplined way to isolate that variation. If the honest answer is "not yet, but it might," that's YAGNI talking, not a design gap - wait for the second real case before reaching for the abstraction.
In an interview specifically, the variation is usually one of two things: something the interviewer stated directly ("later we'll add hourly and monthly pricing"), or something that showed up naturally while you were tracing use cases through your diagram, per approaching OOD interviews. Either is a legitimate trigger. "I want to demonstrate I know patterns" is not.
Quick decision cues for the patterns that come up most
These are recognition shortcuts, not full explanations - each pattern's own page in the catalog covers the mechanics.
- Strategy - an algorithm or behavior varies independently of the object using it, and you want to swap it at runtime. Multiple pricing rules, multiple sorting comparators, multiple routing algorithms.
- Observer - one change needs to notify a set of dependents that isn't fixed in advance and shouldn't be hardcoded into the thing that changed. A stock ticker updating several displays, an inventory system notifying subscribers when a spot frees up.
- Factory (Method or Abstract) - object creation logic is accumulating conditionals ("if type is X create this, if type is Y create that") that have nothing to do with what the caller actually wants to do with the object once it exists. Push the conditional into one place that specializes in deciding.
- Singleton - you genuinely need exactly one instance of something with shared state across the whole system - a config, a connection pool. Reach for it deliberately, and be ready to defend it if pushed, because it's also the pattern most often criticized for being reached for out of habit rather than necessity, as a stand-in for a global variable.
- State - behavior varies by a status field, and that status also transitions between a fixed set of well-defined states over the object's lifetime. A vending machine, an order's fulfillment stages, a traffic light.
Say the trade-off, not just the name
Naming a pattern correctly is worth less than being able to say what it costs. Every pattern in this list adds a layer of indirection - an interface here, an extra class there - in exchange for the ability to extend later without touching the caller. State the exchange out loud: "I'll pull pricing behind a Strategy interface here because we already know a second pricing tier is coming, which costs us one extra interface and one extra class today." That sentence demonstrates more design judgment than the diagram ever will on its own.
Try it yourself: a music player app plays a song differently depending on whether shuffle, repeat-one, or normal mode is active, and the user can switch between those modes mid-playback. Match that to one of the decision cues above, and say out loud what it costs you to introduce it.
Match a few more scenarios to a decision cue before the quiz:
A checkout needs to swap between three discount calculation rules depending on which promotion is active, and a fourth is already planned for next quarter.
Check yourself
Your parking lot design has exactly one pricing rule and the prompt never mentions a second one. Should you introduce a Strategy interface for pricing?