The Runtime Theory
mediumSystemInternals#explain-the-model#reason-about-tradeoffs

Explain Design Patterns as Named Tradeoffs

Explain the model, execution steps, complexity, and limits of design patterns as named tradeoffs.

TRT practice prompt — not a verified question from a named employer.

The Runtime Theory Team6 min read

Interview prompt

Explain design patterns as named tradeoffs to an engineer who understands the surrounding system but has not used this technique. Walk from its contract to a concrete operation, then discuss where it fails or becomes expensive.

A strong answer

A design pattern names a recurring structure for solving a family of design problems. It is useful when it communicates roles and tradeoffs faster than a bespoke explanation. A pattern is not a rule to apply whenever its name sounds familiar.

The Strategy pattern lets a caller choose among interchangeable algorithms behind a common interface. For example, a shipping quote service can select a carrier strategy based on destination and package characteristics. Tests can exercise each strategy independently and verify the selection policy separately.

A complete answer also calls out the assumptions that control correctness. An abstraction becomes costly when it hides one simple behavior behind many interfaces or forces callers to understand irrelevant extension points. Prefer the smallest seam that supports a real variation. Patterns can guide a design review, but local constraints decide whether their structure helps.

Close by describing one representative test or measurement. You have two pricing rules and expect a third soon. Compare a conditional statement with a strategy interface, identifying what new requirement would make the interface worthwhile.

Follow-up questions

Answer the follow-ups in the frontmatter. Use the linked article for the concept and the trace to make the explanation concrete.

This answer walks

Practice follow-ups

  1. 01Which assumption is essential for the approach to be correct?
  2. 02What is the worst case, and how does it change the resource cost?
  3. 03How would you adapt the design if the input or workload became much larger?
  4. 04What boundary test would give you the most confidence in the implementation?

One dispatch a week

The trace behind each question, the tradeoff that explains it, and one technical dispatch per week — no noise.

One technical dispatch per week. No noise.

Not started

Sign in to save your learning progress.

Sign in to save