Preview — Pro guide
You are seeing a portion of this guide. Sign in and upgrade to unlock the full article, quizzes, and interview answers.
LLD Case Study: Chess Game System Design
Design a fully-featured chess engine covering piece hierarchy, move validation, check/checkmate detection, and special moves. Covers the exact tradeoffs interviewers probe at senior level: where move validation lives, how undo works, and how to extend the system for AI opponents without rewriting the core.
Why Chess Is the Ideal LLD Interview Problem
Chess is a FAANG LLD favorite because it tests everything simultaneously: inheritance hierarchy design, move validation architecture (where does the logic live?), state machines (game lifecycle), and design patterns (Command for undo, Observer for UI). A shallow answer describes six piece classes. A strong answer explains why validation is split between the Piece and the Board, how check detection forces a simulate_move abstraction, and how the Command pattern makes undo trivially safe.
The counterintuitive insight most candidates miss: Piece should not validate the full move. A Rook knows it moves in straight lines, but it cannot know if the path is blocked — that requires board occupancy data the Piece doesn't own. The cleanest architecture splits responsibility: Piece generates candidate moves for its movement pattern, Board filters them for legality (path blocked? own piece at destination? leaves king in check?). This separation is what enables clean check/checkmate detection without circular dependencies.
This problem is asked in LLD rounds at Google, Microsoft, Amazon, and Atlassian. It directly tests whether you understand the difference between syntactic legality (the Rook moves in straight lines) and semantic legality (this specific move is blocked or would expose your king).
What Interviewers Are Evaluating
Mid-level: Can you model the Piece hierarchy correctly? Do you reach for abstract classes? Can you implement basic move validation for a Rook?
Senior-level: Do you know where move validation responsibility belongs (Piece vs Board vs Validator)? Can you implement check detection without circular dependencies? Do you handle special moves (en passant, castling, promotion)?
Staff-level: Do you apply Command for undo with full undo correctness (including captured pieces)? Do you reason about adding AI (minimax + alpha-beta pruning) as an extension without breaking the core Game class? Do you identify concurrency requirements for online play?