Strategy
Swapping an algorithm at runtime, without a conditional that grows forever.
You have one job to do and several ways of doing it — sorting by different comparators, pricing an order under different discount rules, compressing a file with different codecs. The naive version is a conditional inside the method that picks the approach, and the problem with it is not ugliness, it's that every new approach edits a method that already works. Strategy pulls each approach out into its own object behind a shared interface, and lets the caller hold whichever one it needs.
What it costs is object count and indirection. You have turned one readable method into an interface plus N classes plus whatever decides which to hand over, and a reader chasing behaviour now has to find the wiring before they can find the code. That trade is worth it when the approaches genuinely vary independently and are added often. It is not worth it for two branches that have never changed.
The pattern it is confused with is State, and the structures are nearly identical — an interface, several implementations, an object holding one of them. The distinguishing question is who decides which implementation is active. In Strategy the *caller* chooses and the choice is stable for the operation. In State the object transitions itself, usually as a consequence of the very method you just called. If your implementations reach back to swap themselves, you wrote State.
What they ask, and what to say
What problem does Strategy actually solve?
Choosing between interchangeable ways of doing one job without editing the code that does it. Each approach becomes an object behind a common interface, so adding a fifth pricing rule adds a class instead of another branch inside a method that already works.
Why they ask: Separates people who've read the pattern from people who can say what it buys — the open/closed argument is the whole point.
Strategy and State look identical on a class diagram. What separates them?
Who chooses. In Strategy the caller picks an implementation and it stays put for the operation. In State the object moves itself to the next state as a result of handling a request. Same shape, opposite direction of control.
Why they ask: The single most common confusion in pattern interviews, and answering it proves you understand both rather than having memorised two diagrams.
When is Strategy the wrong choice?
When there are two branches that have been stable for years. You'd trade one readable conditional for an interface, two classes and a factory, and a reader now has to find the wiring before they can find the behaviour.
Why they ask: Interviewers are wary of candidates who apply patterns reflexively. Naming the cost is what shows judgement.
Do you still need Strategy classes in a language with first-class functions?
Often not. A function parameter is a strategy — Java's Comparator, a callback, a lambda passed into a sort. Reach for full classes when the strategy carries state, needs several methods, or has to be discoverable by name for configuration.
Why they ask: Shows you know patterns describe shapes, not ceremony, and that a language feature can supply the shape for free.
Where it shows up
Designs on this site that reach for Strategy naturally, rather than for decoration.