Template Method in Interviews: Common Questions and Pitfalls

Interviewers frequently ask candidates to design systems using Template Method Pattern to assess understanding of inheritance, abstraction, and algorithmic decomposition. Knowing common variations and pitfalls is crucial for success.
Common Interview Question: "Design a game engine where different game types (Chess, Tic-Tac-Toe, Checkers) share the same game loop but have different rules and win conditions."
Key Design Considerations:
First, Identify Invariant vs Variant Steps: The game loop structure is invariant: initialize game, while not game over, get player move, execute move, check win condition, switch player. The variant steps are move validation, win checking, and board initialization. Make variant steps abstract and keep the game loop template method final.
Second, Decide Between Abstract Methods and Hooks: Move validation and win checking must be implemented by all games (abstract methods), but rendering the board could be a hook with a default console implementation that graphical games can override.
Third, Handle State Management: The base class should manage shared state (current player, move history, game status) while subclasses manage game-specific state (board configuration). Use protected methods to expose necessary state to subclasses without breaking encapsulation.
Interview Tip: Always clarify whether methods should be abstract (must implement) or hooks (optional). Saying "I'll make all methods abstract" shows poor understanding. Some steps like logging or rendering often have sensible defaults.
Common Pitfall: Overusing Inheritance
Candidates often create deep inheritance hierarchies: Game ▲ BoardGame ▲ TwoPlayerBoardGame ▲ Chess. This violates the Liskov Substitution Principle (LSP) and makes the system brittle. Keep hierarchies shallow (maximum two levels). If you need more specialization, use composition. For example, inject a BoardRenderer strategy instead of subclassing GraphicalBoardGame.
Common Pitfall: Not Making Template Method Final
If you don't mark the template method as final, subclasses can override it and break the algorithm structure. Interviewers specifically test this: "What prevents a subclass from changing the game loop order?" Answer: "The playGame() template method is final, so subclasses cannot override it. They can only implement the abstract hook methods."
Common Pitfall: Exposing Too Much State
Making all fields protected allows subclasses to access and modify anything, leading to tight coupling. Instead, provide protected methods like getCurrentPlayer(), recordMove(move), and isGameOver() that encapsulate state access.
Extension Question: "How would you add multiplayer support?" Use composition: inject a PlayerManager into the base class instead of subclassing MultiplayerGame. This follows the principle of favoring composition over inheritance.
Machine Coding Considerations:
Testing Strategy: Write tests for the template method using mock subclasses. Verify that the template method calls primitive operations in the correct order. Test each concrete subclass implementation separately to ensure they provide valid implementations of abstract methods.
Error Handling: If a primitive operation can fail (e.g., invalid move), decide whether the template method should catch exceptions or propagate them. For validation errors, catch in the template method and return error states. For system errors (I/O failures), propagate to the caller.
Performance: Template Method uses virtual method dispatch, which has minor overhead compared to direct calls. This is negligible for most applications. If you're implementing a high-frequency trading system, measure and consider inlining critical paths, but for typical applications like game engines or document processors, the overhead is acceptable.
Interview Tip: When coding, always start with the base class template method, then implement one concrete subclass completely before adding others. This ensures your abstraction is correct before proliferating it.

💡 Key Takeaways

✓Identify invariant game loop structure versus variant rule implementations

✓Mark template method as final to prevent subclasses from breaking algorithm structure

✓Use protected accessor methods instead of exposing fields directly

✓Keep inheritance hierarchies shallow; use composition for orthogonal concerns

✓Write tests that verify template method calls primitive operations in correct order

📌 Examples

1Game engine with Chess, TicTacToe, Checkers sharing game loop template

2Data migration pipeline with different source and target adapters

3Report generation system with PDF, Excel, HTML output formats

← Back to Template Method Pattern Overview