TicTacToe: Overview and Requirements

The first thing I do in any LLD interview is not sketch a class. It is not even ask about the features. The first thing I do is make sure the interviewer and I are thinking about the same system. That alignment step is what separates a confident start from one that feels like it is going in circles.

The Essentials

1. Alignment before requirements: Getting requirements for the wrong system is worse than getting no requirements at all.
2. Three clarifying questions: What kind of system? Is persistence needed? What is the input mechanism?
3. Suggest, do not just ask: You propose features and ask if they should be supported. You do not wait for the interviewer to list them for you.
4. Core features for TicTacToe: Configurable board size, N-1 players, bots with difficulty levels, configurable winning strategies, and undo support.
5. Shuffled turn order: The game starts with a random player order that remains fixed.

The Overview: Aligning on the Domain

When the interviewer says "design TicTacToe," I briefly describe the game and confirm our understanding. Something like:

"It is a 3x3 grid where two players alternate turns placing their symbol (X or O). First to get three in a row, column, or diagonal wins. Is that the system you have in mind?"

This simple question invites the interviewer to correct any assumptions before I build on them.

Three Questions Before Requirements

Before diving into features, I ask three "meta-questions" that shape the entire design:

1. What kind of system? Is it a web app with APIs, or a desktop program? For TicTacToe, it is a software system, but desktop-only.
2. Is persistence needed? No. When the game ends, the data disappears. This means I can skip the database layer for now.
3. How is input taken? Command-line input only. No UI or API layer needed.

Requirement Gathering: Suggest, Do Not Ask

The mistake I used to make was waiting for the interviewer to tell me the features. Now, I visualize the system and propose features one at a time. I suggest 5-8 core features, then check in to see if they want more or if I should move to the class diagram.

The TicTacToe Requirements

Here are the requirements we will use for this series:

Board:

• Configurable size (NxN). The design should handle any dimension.

Players:

• Number of players is N-1. Minimum 2.
• Shuffled turn order: The list of players is randomly ordered at the start and remains fixed.
• Distinct symbols: Every player chooses a unique character symbol at the start.

Bots:

• Support for bot (computer) players.
• Bots have different difficulty levels (Easy, Medium, Hard).
• At most one bot per game.

Game Flow:

• The game ends as soon as one player wins or the board is full (Draw).
• Winning Strategies: These should be configurable. You can add row win, column win, or corner win strategies without changing core game logic.
• Undo: Any player can undo the last move. It reverts the state and turn order. Undo can happen multiple times.
• Replay: A way to replay the full sequence of moves after the game ends.

The configurable winning strategy requirement is the most interesting one here. It is a clear trigger for the Strategy Pattern. Identifying this connection out loud is exactly what interviewers are looking for.

With the requirements locked in, the next step is translating them into a class diagram. But first, we need to decide what kind of classes we need. We will look at designing entities using abstract classes and enums in the next post.

Further Reading and Watching

• How to Crack Machine Coding Rounds (Gaurav Sen)
• The Art of Asking the Right Questions in System Design (Martin Fowler)