Chess Game

Classic Board Game

Design a two-player chess game: the board, the six piece types and their moves, legal-move checking, and check, checkmate and stalemate detection.

Overview

Chess is played on an 8 by 8 board by two players, White and Black, who move in turn. Each of the six piece types moves in its own way. A move is legal only if the piece can make it, nothing blocks it, the target does not hold a friendly piece, and the mover's own king is not left under attack. The game ends in checkmate when the player to move is in check and has no legal move, or in stalemate, a draw, when they are not in check and have no legal move.

The problem is a favorite for senior interviews because it has a clean shape with real depth. The piece rules are a textbook case for polymorphism. Legal-move checking forces you to try a move, look at the board, and take the move back, which is the Command pattern with a real reason to exist. Check and checkmate detection is a small algorithm on top of everything else, and it only works if the pieces below it are right.

There are three things interviewers watch for. Whether each piece owns only its geometry and leaves blocking, turn order and check to the board and the game. Whether you can undo a move exactly, including a capture and a promotion. And whether you know the difference between a pseudo-legal move (the piece can go there) and a legal move (and the king is safe afterwards).

Scoping the problem

The full rules of chess are long. Agree on a subset first.

All six pieces with their real moves? — This is the core; anything less is not chess — Yes
Check, checkmate and stalemate? — Needs attack detection and a try-and-undo loop — Yes
Castling and en passant? — Each needs extra state (has the king moved, what was the last move) — Design for them, code them if time allows
Pawn promotion? — Needs a choice of piece and an exact undo — Yes, promote to a queen
Draw by repetition or the fifty-move rule? — Needs position hashing and a counter — Out of scope
Undo and move history? — Falls out of the Move object if you design it that way — Yes
A clock, players, or a user interface? — Not the design's core — Out of scope

Core entities

Every piece type is a subclass of Piece with one method that yields the squares it could move to, given the board. The Board holds the grid and answers questions about it: what is on a square, is a square attacked, is a king in check. The Game owns the turn, the history and the status, and is the only class that knows what a legal move is.

A pawn is the one piece whose attacks differ from its moves: it moves straight ahead but captures diagonally. That is why Piece has both moves and attacks, and only Pawn overrides the second. Check detection uses attacks; move generation uses moves.

How a move is validated

The game generates every pseudo-legal move for the side to move, tries each one on the board, keeps it only if the mover's king is not attacked afterwards, and undoes it. The requested move is legal if it is in that list.

The status after a move is decided from the opponent's point of view.

No — Yes — Ongoing
Yes — Yes — Check
Yes — No — Checkmate, the mover wins
No — No — Stalemate, a draw

What you will be able to do

Write the six piece classes so that each holds only its own geometry, with sliding pieces sharing one helper.
Explain pseudo-legal versus legal moves and code the try-and-undo loop that separates them.
Make Move a command that Board can apply and undo exactly, including captures and promotion.
Detect check, checkmate and stalemate from one small status function.
Say what state castling and en passant need and where it lives.

Functional requirements

An 8 by 8 board with the standard starting position: White on ranks 1 and 2, Black on ranks 7 and 8
All six piece types move by the real rules: king one square, queen and rook and bishop slide until blocked, knight jumps in an L, pawn moves forward and captures diagonally
A move is refused if the piece cannot reach the square, a piece is in the way, the target holds a friendly piece, it is not that color's turn, or the mover's own king would be left in check
A pawn that reaches the last rank is promoted (to a queen in this implementation)
After every move the game reports ongoing, check, checkmate or stalemate, and refuses moves once the game is over
Every move is recorded with what it captured so it can be undone exactly

Non-functional requirements

Adding a piece type (a chess variant) means adding one subclass and one map entry; Board and Game do not change
Legality checking uses apply and undo on one board, never a copy of the board per candidate move
The rules of the game live in Game and Board; no piece knows about turns, check or the history
Coordinates are one type everywhere: (row, col) with a helper that reads algebraic names such as e4

Interview questions

Why one class per piece instead of a switch on the piece type?
How does undo work, and why does legal-move generation depend on it?
Where should move validation live: in the piece, the board or the game?
How would you add castling and en passant?
Is generating every legal move on every turn too slow?