पाठ 24 / 25
Patterns in Interviews and Code Review
Recognise, name and justify.
Naming patterns with judgement
In design interviews and reviews, patterns are useful as shared vocabulary: "this is a Strategy keyed by payment method" says a lot in a few words. Strong answers follow a shape: name the problem (what varies, what must stay stable), propose the pattern, explain the trade-off, and mention the simpler alternative ("a map of functions would also work here"). Interviewers often probe when not to use a pattern, the difference between look-alikes (Decorator vs Proxy vs Adapter, Strategy vs State, Factory vs Builder), and modern equivalents (DI containers, middleware, event emitters). In code review, prefer questions to labels: "Do we expect another implementation soon?" is more helpful than "this violates SOLID". Recognising patterns in frameworks you already use (middleware, hooks, iterators, observers) is a good way to practise.
Telling look-alikes apart
Compare intent, not structure.
Adapter vs Decorator changes the interface vs keeps it, adds behaviour
Decorator vs Proxy adds behaviour vs controls access (cache, lazy, auth)
Facade vs Adapter new simpler interface vs match an existing expected interface
Strategy vs State client picks algorithm vs object switches behaviour as state changes
Factory vs Builder decides which class vs assembles one complex object in steps
Observer vs Pub/Sub subject knows listeners vs broker decouples publisher and subscriber
Command vs Strategy a request to run/undo vs an interchangeable algorithmLead with the problem
Saying "we have three ways to calculate shipping that change per campaign" before "let us use Strategy" keeps the discussion grounded and shows you are not pattern-hunting.
त्वरित जाँच: What distinguishes Strategy from State?
- They solve unrelated problems and look nothing alike
- Strategy requires inheritance and State does not
- With Strategy the client chooses the algorithm; with State the object changes behaviour as its own state changes
- State is creational and Strategy is structural
Answer
With Strategy the client chooses the algorithm; with State the object changes behaviour as its own state changes — Same structure, different intent.