Checkers Game — Backend System Design

Open-ended onsite design-implementation hybrid. Build the backend for a checkers game: data model, board state, move validation, capture logic, win condition. Time is intentionally tight — the interviewer expects a working partial implementation plus a discussion of what to optimize next. Requirements Model the board (8×8) and pieces (own / opponent, regular / king). Implement move(from, to) validation: own piece, destination empty, diagonal direction respecting piece type and capture rules. Implement capture logic (jump-over-opponent), including chained captures. Implement king promotion at the back row. Implement win detection (no opponent pieces left, or no legal moves). Time pressure: candidates report finishing init + move + win-check, with capture left undone. Interviewer follow-up is "which part of your code would you optimize next, and how?" Notes The round is open-ended and has no hidden tests — the interviewer scores the data model and method boundaries, not test coverage. The expected design centers a Board class plus a Move validator; piece state can be a 2-D array of Optional[Piece]. Bring up state immutability (return a new board on each move) vs. mutation explicitly; the interviewer probes both. The follow-up about optimization is a code-quality / refactor question rather than a perf question — talk about extraction of a MoveValidator, separation of state vs. rules, and how to make the engine play-against-AI ready. Preparation Practice writing the data model in 10 minutes; the round is too short to debate it for 20. Be able to enumerate every checkers rule from memory — interviewers occasionally clarify, but the expectation is that you know the game. Have a 60-second pitch for "if I had another hour, here is what I would refactor" — the optimization follow-up is graded on conciseness.