Start with a decision, not a diagram
An interview answer becomes useful when another engineer can see why a design exists and how to test it. Naming Strategy, Observer or Mediator is only a starting point. Use these five questions to turn vocabulary into a concrete argument.
1. What must always be true?
Write one invariant in ordinary language. For an order, it might be that a confirmed booking owns a valid reservation. For pricing, it might be that a discount never produces a negative total. A class diagram cannot compensate for an unclear rule.
2. What actually varies?
Distinguish interchangeable calculations from lifecycle-dependent behavior. Several shipping-price policies can be a Strategy problem. The legal operations on a dispatched order are a state-transition problem. If there are just two stable branches, a readable conditional may be sufficient.
3. Who owns the dependency?
Independent screens reacting to a reading are different from a workflow that must persist before billing. Put required ordering in an explicit owner rather than relying on subscribers happening to run in a convenient sequence. Explain which component chooses the next action and which component owns each local rule.
4. What happens when a boundary fails?
Walk through one thrown exception, a slow dependency and a duplicate request. A timeout is not evidence that the first attempt had no effect. State whether an operation can be retried safely, what identity identifies the same logical work, and how a user learns the eventual result.
5. What is the smallest design that meets the need?
Compare your proposal with a direct function call or a small application service. Extra indirection earns its place only if it makes a real variation or dependency easier to understand, test or change. Explain what evidence would make you simplify the design later.
A worked answer
Imagine a dashboard with a temperature chart and a logging panel. Both independently react to updates, so a subscription-based design is reasonable. Each screen owns its subscription lifetime. Now introduce a rule that a reading must be stored before an invoice is created. That dependency belongs in a workflow with an explicit failure policy; it should not be hidden in the relative registration order of two panels.
A strong answer describes both relationships and the point where they differ. It also names the tests: closing a screen removes its subscription; a failed persistence step prevents invoicing; retrying a completed operation does not create another invoice.
Practice
Apply the checklist to the Observer and Mediator workshop, then attempt the free design workbook. Write a short answer before drawing any classes.