How would you implement Tic Tac Toe in React?

Tic Tac Toe is the canonical "implement this from scratch in 30 minutes" frontend interview prompt. It looks trivial but is actually a great signal of clean React state design, immutability, win-condition modeling, and how you handle extension questions ("now make it 4x4", "add undo/redo", "support two-player online"). The wrong way is to dive into JSX immediately; the right way is to pin down state shape, derived state, and win logic in your head first, then code.

Clarifying questions to ask first (signals product instinct):

• Single device hot-seat, or networked multiplayer?
• 3×3 only, or generalize to N×N with K-in-a-row?
• Should there be a status line ("X's turn", "X wins", "Draw")?
• Reset button? Move history / undo?
• Accessibility (keyboard nav, screen reader)?

For a 30-minute coding round, scope to: 3×3, hot-seat, status line, reset. Mention the other axes when you take the assignment so the interviewer knows you saw them.

State design. Three pieces of state. Don't store anything derivable.

• board: ("X" | "O" | null)[] — length 9 (or [N][N]), immutable updates only.
• xIsNext: boolean (or turn: "X" | "O") — whose move.
• Optional: history: typeof board[] for undo / time-travel.

Derived state (compute on each render, don't store):

• winner — calculateWinner(board) returns "X", "O", or null.
• isDraw — board.every(Boolean) && !winner.
• status — string built from winner / isDraw / xIsNext.

Putting winner in state is a common mistake: now you have two sources of truth and have to remember to update both. Always derive what can be derived.

Win-line generation. For 3×3, the 8 winning lines are hardcoded:

const LINES = [
  [0,1,2],[3,4,5],[6,7,8],   // rows
  [0,3,6],[1,4,7],[2,5,8],   // cols
  [0,4,8],[2,4,6],           // diagonals
];
function calculateWinner(b: Board): Player | null {
  for (const [a,b2,c] of LINES) {
    if (b[a] && b[a] === b[b2] && b[a] === b[c]) return b[a];
  }
  return null;
}

For an N×N variant with K-in-a-row, generate lines programmatically — every (row, col) is the start of up to 4 lines (right, down, diag, anti-diag) of length K. The senior follow-up usually is "now make it 5-in-a-row on a 15×15 board" — having the generator pattern in your back pocket is a strong signal.

Component structure.

function Game() {
  const [board, setBoard] = useState<Board>(Array(9).fill(null));
  const [xIsNext, setXIsNext] = useState(true);

  const winner = calculateWinner(board);
  const isDraw = !winner && board.every(Boolean);
  const status = winner ? `Winner: ${winner}` : isDraw ? "Draw" : `Next: ${xIsNext ? "X" : "O"}`;

  function handleClick(i: number) {
    if (board[i] || winner) return;             // guard
    const next = board.slice();
    next[i] = xIsNext ? "X" : "O";
    setBoard(next);
    setXIsNext(v => !v);
  }

  function reset() {
    setBoard(Array(9).fill(null));
    setXIsNext(true);
  }

  return (
    <div role="grid" aria-label="Tic Tac Toe">
      <div aria-live="polite">{status}</div>
      <div className="grid grid-cols-3 gap-1">
        {board.map((cell, i) => (
          <button
            key={i}
            role="gridcell"
            aria-label={`cell ${i + 1} ${cell ?? "empty"}`}
            onClick={() => handleClick(i)}
            disabled={!!cell || !!winner}
          >{cell}</button>
        ))}
      </div>
      <button onClick={reset}>Reset</button>
    </div>
  );
}

Things to surface as you code (this is the rating signal):

• Immutability — never board[i] = ...; always board.slice() or [...board] then mutate the copy. Without this, React doesn't see the change.
• Guards in the click handler — ignore clicks on filled cells and after a winner is declared.
• Accessibility — role="grid" / role="gridcell", aria-live status, aria-label per cell so screen readers can announce "cell 5, empty" and updates.
• Keyboard support — arrow keys to navigate, Enter / Space to play. Optional but a great senior touch.
• Lift state only as far as needed — board state in <Game>, each <Square> is a controlled child.
• Don't store derived values. Compute winner and status on render.
• Strict types — type Player = "X" | "O", type Cell = Player | null, type Board = Cell[].

Likely extension questions and how to handle them:

• Undo / time travel. Store history: Board[] instead of just board; track currentMove. The board is history[currentMove]. xIsNext can be derived from currentMove % 2 === 0.
• N×N board, K in a row. Move LINES to a generator function; calculateWinner iterates lines.
• AI opponent. Minimax with alpha-beta pruning for 3×3 (game tree is tiny; precompute the optimal move). For larger boards, depth-limited search or MCTS.
• Multiplayer. Lift state to a server (WebSocket or Firestore); each move is an action; clients render from server state. Discuss conflict resolution if both players click simultaneously (server is the arbiter; use turn tokens).
• Highlight winning line. Return the line indices from calculateWinner, not just the winner. Style those squares differently.
• Animations / haptics. Reach for Framer Motion or CSS transitions on cell fills.

Common mistakes interviewers note:

• Mutating the board array (board[i] = "X"; setBoard(board)) — React skips the render because the reference is the same.
• Storing winner in state and forgetting to update it.
• No guard for clicking after game over → state desync.
• Building 9 separate useStates for each cell. Don't.
• Ignoring accessibility entirely.
• Hardcoding "3×3" everywhere — fine for the base, but be ready to refactor.

Time budget for a 30-minute round: 3 min clarify + state design, 12 min core implementation, 5 min styling and accessibility, 5 min extension discussion / bug-finding, 5 min buffer. Code less, narrate more — the interviewer is grading the thinking, not the keystrokes.