Object-Oriented Design of a Chess Game with Full Move Legality

Read the full interview experience this question came from →

Quick Overview

Design a chess game as an object model covering the board, pieces, players, moves and game state. It tests separating piece movement patterns from position-level legality, handling check, checkmate, stalemate, castling, en passant and promotion, and supporting undo, move history and future extensions cleanly.

Object-Oriented Design of a Chess Game with Full Move Legality

Company: Oracle

Role: Software Engineer

Category: Software Engineering Fundamentals

Difficulty: medium

Interview Round: Onsite

Design a chess game. The report gives only this one-line prompt, so settle the scope with the interviewer first. In its usual object-oriented form: model the board, the pieces, the players and the moves so that two players can play a complete game, every move is checked against the rules of chess, and the program knows when and how the game has ended. ```hint Where does move logic live Decide which object knows how a piece may move and which object knows whether a move is legal in the current position; they are not the same question. ``` ```hint Reachable is not the same as legal A move that a piece can geometrically make may still be illegal. Think about which rule causes that, and how to check it without duplicating movement logic. ``` ### Constraints and Clarifications - Not given: the interface (console, graphical, networked), whether there is a computer opponent or a clock, and which draw rules must be enforced. Ask, or state your assumptions. ### Clarifying Questions - Is the goal an object model for the game logic, or an online service where players are matched and play over the network? - Two people on one device, or also a computer opponent? Is there a clock? - Which rules must be enforced: castling, en passant and promotion; check, checkmate and stalemate; draws by repetition or the fifty-move rule? - Must the game support undo, saving and loading, or replaying a game from its move list? ### What a Strong Answer Covers - Settles the scope (local model or online service, opponents, clock, rule set) before designing - A cohesive class model: game, board and squares, pieces, players, moves and move history - Clean separation of piece movement patterns from position-level legality (never leaving one's own king in check) - Special moves and the state they need: castling rights, the en passant square, promotion - End-of-game detection: checkmate, stalemate, resignation and the agreed draw rules - Extensibility and testability: undo, replay, variants, and tests for each rule ### Follow-up Questions - How would you implement undo, and what must each move record so that undo is exact? - How would you add a chess clock, or a variant with different piece rules, without rewriting the core? - How would you detect a draw by threefold repetition efficiently? - If the two players play online, what changes, and which component decides whether a move is legal?

Overview: Design a chess game as an object model covering the board, pieces, players, moves and game state. It tests separating piece movement patterns from position-level legality, handling check, checkmate, stalemate, castling, en passant and promotion, and supporting undo, move history and future extensions cleanly.

Read the full Oracle Software Engineer interview experience this question came from

Oracle logo
Oracle
Oct 10, 2026
mediumSoftware EngineerOnsiteSoftware Engineering Fundamentals
1
0

Design a chess game. The report gives only this one-line prompt, so settle the scope with the interviewer first. In its usual object-oriented form: model the board, the pieces, the players and the moves so that two players can play a complete game, every move is checked against the rules of chess, and the program knows when and how the game has ended.

Constraints and Clarifications

  • Not given: the interface (console, graphical, networked), whether there is a computer opponent or a clock, and which draw rules must be enforced. Ask, or state your assumptions.

Clarifying Questions Guidance

  • Is the goal an object model for the game logic, or an online service where players are matched and play over the network?
  • Two people on one device, or also a computer opponent? Is there a clock?
  • Which rules must be enforced: castling, en passant and promotion; check, checkmate and stalemate; draws by repetition or the fifty-move rule?
  • Must the game support undo, saving and loading, or replaying a game from its move list?

What a Strong Answer Covers Guidance

  • Settles the scope (local model or online service, opponents, clock, rule set) before designing
  • A cohesive class model: game, board and squares, pieces, players, moves and move history
  • Clean separation of piece movement patterns from position-level legality (never leaving one's own king in check)
  • Special moves and the state they need: castling rights, the en passant square, promotion
  • End-of-game detection: checkmate, stalemate, resignation and the agreed draw rules
  • Extensibility and testability: undo, replay, variants, and tests for each rule

Follow-up Questions Guidance

  • How would you implement undo, and what must each move record so that undo is exact?
  • How would you add a chess clock, or a variant with different piece rules, without rewriting the core?
  • How would you detect a draw by threefold repetition efficiently?
  • If the two players play online, what changes, and which component decides whether a move is legal?