Getting Ready: Tic Tac Toe

Tic Tac Toe is one of the most commonly asked design problems in software engineering interviews — and for good reason. Behind this seemingly simple 3×3 grid lies a surprisingly rich set of object-oriented design decisions: modeling a game board, managing player turns, detecting win conditions efficiently, and structuring code so it can scale to larger boards without rewriting everything.

Companies like Google, Amazon, and Microsoft use game design problems in interviews because they test your ability to decompose a problem into clean, interacting objects. Unlike CRUD systems, a game forces you to think about state transitions (whose turn is it?), validation (is this move legal?), and termination conditions (has someone won? is it a draw?) — all within a small enough scope to complete in 45 minutes.

What makes Tic Tac Toe especially valuable as a first design problem is its gentle learning curve. The domain is universally understood — no one needs a requirements doc to know how the game works. This lets you focus entirely on translating domain knowledge into classes, relationships, and methods, which is the core skill of Low Level Design.

By completing the Tic Tac Toe design problem, you will practice:

• 2D array modeling — representing a game board as a grid of cells, each cell tracking its state
• Turn management — alternating between players and enforcing game rules
• Win detection algorithms — checking rows, columns, and diagonals efficiently, including an O(1)-per-move optimization
• Enum usage — modeling fixed sets of values (player symbols, game status) with type safety
• Extensibility — designing the board so it can scale from 3×3 to NxN without modifying the core game logic
• Clean separation of concerns — the Board handles the grid, the Game handles the rules, and the Player holds identity
• UML Class Diagrams — you'll create the structural blueprint and then implement it in both Python and Java

Before starting this problem, make sure you're comfortable with:

• Classes and Objects — creating classes with attributes and methods (Fundamentals S1)
• Encapsulation — protecting internal state and exposing behavior through methods (Fundamentals S2)
• Enums — representing fixed sets of values like game symbols and status codes (Fundamentals S3)
• OOP Relationships — especially Composition, since the Board owns its Cells (Fundamentals S4)
• UML Class Diagrams — reading and interpreting class boxes, attributes, methods, and relationship arrows (Fundamentals S5)

You do not need prior experience with design patterns — this problem introduces pattern thinking naturally through its structure.

We will design: The core game logic — a Board, Players, turn management, move validation, and win/draw detection. We'll implement the complete game loop that two players can use to play Tic Tac Toe from start to finish.

We will also design: An extension to support NxN boards (e.g., 4×4, 5×5) with an optimized O(1) win-detection algorithm per move — a common interview follow-up question.

We will NOT design: A graphical UI, network multiplayer, AI opponents (minimax), a database for storing game history, or REST APIs. This is a Low Level Design (object-oriented) exercise, not a System Design (infrastructure) problem.

Interview context: In a 45-minute LLD interview, you'd be expected to gather requirements (3 minutes), sketch the class diagram (10 minutes), implement core classes (25 minutes), and discuss extensions like NxN support (7 minutes). Our tutorials follow this exact flow.