Template Method
Fixing the order of steps in a base class, letting subclasses fill in some of them.
Several procedures share a skeleton and differ in a few steps — parse, validate, transform, write, where only transform really changes. Template Method puts the sequence in a base-class method and leaves the varying steps as abstract hooks. The order is stated once and subclasses cannot reorder it, which is the point: the invariant part is protected from the variable part.
The price is inheritance, and it's a steep one. A subclass is bound to its parent forever, you get one parent only, and hooks create fragile coupling — changing what the base class calls, or when, can break every subclass silently. A subclass that has to override half the hooks to do anything useful is telling you the skeleton was wrong.
The alternative is Strategy, and the choice is inheritance versus composition. Template Method is right when the sequence is genuinely fixed and the variation is small and closed — few implementations, all yours. Strategy is right when implementations are numerous, come from elsewhere, or need to change at runtime, since an object can swap a strategy but can never swap its superclass. Modern guidance leans toward composition, and being able to say why is the answer.
What they ask, and what to say
What does Template Method protect?
The order of steps. The skeleton lives in the base class and only the varying steps are overridable, so a subclass can change what a step does but not rearrange the sequence — the invariant is written down once.
Why they ask: The protective framing is the reason the pattern exists; without it it sounds like ordinary inheritance.
Template Method or Strategy?
Inheritance versus composition. Template Method suits a fixed sequence with small, closed variation you own. Strategy suits many implementations, external ones, or anything that must change at runtime — you can swap a strategy, you can't swap a superclass.
Why they ask: The canonical pairing, and 'chosen at compile time versus runtime' is the crispest way to put it.
What's the danger with hook methods?
Fragile base class coupling. Subclasses depend on which hooks get called and in what order, so changing the skeleton can break them silently. If a subclass must override most hooks to be useful, the skeleton wasn't the right abstraction.
Why they ask: Naming the inheritance cost is what makes the composition argument credible.
Where it shows up
Designs on this site that reach for Template Method naturally, rather than for decoration.