Observer
Telling interested parties something happened, without knowing who they are.
Something changed and other things need to react — a cell recalculates, a UI redraws, an audit log records. Wiring the subject directly to each reactor means the subject imports all of them and gains a new dependency every time somebody cares about a new thing. Observer inverts it: listeners register themselves, the subject keeps a list, and publishing means walking that list and calling one method.
The costs are real and interviewers know them. Notification order is usually unspecified, so anything that depends on it is a bug waiting for a refactor. A listener that throws can take out the whole publish loop unless you isolate it. Worst of all, a registered listener is a strong reference — forget to unregister and the subject keeps the listener, and everything the listener holds, alive forever. "Lapsed listener" leaks are the classic production consequence of this pattern.
It gets confused with publish/subscribe, and the difference matters at scale. Observer is in-process and direct: the subject holds the observers and calls them, usually synchronously. Pub/sub puts a broker in between, so publishers and subscribers never meet, delivery can be asynchronous and buffered, and the two sides can live in different processes. If there's a queue in the middle, you're describing pub/sub.
What they ask, and what to say
What does Observer decouple, exactly?
The thing that changes from the things that care. The subject knows only an interface and a list, so adding a fourth listener touches nothing the subject owns — the dependency points from listener to subject instead of the other way round.
Why they ask: The direction of the dependency is the entire value, and it's the part people leave out.
What's the classic memory leak in Observer?
The lapsed listener. Registering stores a strong reference, so a listener that's never unregistered can't be collected — and neither can anything it holds. Long-lived subjects with short-lived listeners are where it bites; the fixes are explicit deregistration or weak references.
Why they ask: Distinguishes people who've shipped the pattern from people who've only drawn it.
Observer or pub/sub — what's the difference?
A broker. Observer is in-process and direct: the subject holds observers and calls them, usually synchronously. Pub/sub routes through a middleman, so the two sides never reference each other and delivery can be async, buffered and cross-process.
Why they ask: Comes up constantly once system design enters the conversation, and conflating them makes scaling answers incoherent.
One observer throws during notification. What happens?
Naively, the loop dies and every later observer is silently skipped — and which ones depends on registration order. Serious implementations catch per listener, and don't let observers assume any ordering in the first place.
Why they ask: A good probe for whether you think about partial failure, which is the difference between LLD and diagram-drawing.
Where it shows up
Designs on this site that reach for Observer naturally, rather than for decoration.