Tic-Tac-Toe — OOD Interview Walkthrough

Phase 1: Requirements & Use Cases

Interviewer: "Design a Tic-Tac-Toe game."

Candidate: "Let me confirm the scope. I'm modeling the software for the classic 3×3 two-player Tic-Tac-Toe game — players alternate placing marks, and we detect wins, losses, and draws. I'll design the OOD model: the classes, their relationships, and the turn flow. This is a single-game model, not a platform with accounts and matchmaking. Does that match your intent?"

Interviewer: "Yes. What actors and use cases do you see?"

Candidate: "Actors: two Players — could be human or AI. The Game acts as the orchestrator.

Core use cases:

1. Players are registered with their mark (X or O)
2. A player makes a move by choosing a cell
3. The board is updated and displayed after each move
4. The game detects win conditions after each move
5. The game detects a draw when the board is full with no winner
6. The game announces the result and ends"

Interviewer: "Should the board be configurable — say, NxN instead of 3×3?"

Candidate: "Good question. I'll parameterize the board size so the Board class takes an n parameter, and the win-detection logic uses n as the required sequence length. This adds minimal complexity while making the design future-proof. Win-in-a-row count would also be configurable for games like Connect Four variants."

WHY: Parameterizing board size costs almost nothing now and prevents a full rewrite if the interviewer asks "what if we want 4×4?" as a follow-up.

Interviewer: "What about AI players?"

Candidate:…