LLD delivery framework (35 min)

01Why a framework

021) Requirements (~5 minutes)

• Primary capabilities — What operations must the system support?
• Rules and completion — What counts as success, failure, or a state transition?
• Error handling — How should invalid inputs or illegal actions be rejected?
• Scope boundaries — What’s in (core logic, rules) vs out (UI, storage, networking, concurrency, future features)?

Requirements (Tic-Tac-Toe):
1. Two players alternate placing X and O on a 3x3 grid.
2. Win = complete a row, column, or diagonal.
3. Draw = all nine cells filled with no winner.
4. Reject invalid moves (occupied cell, move after game over).
5. Support querying game state and resetting.

Out of scope:
- UI / rendering
- AI opponent
- Networked multiplayer
- NxN boards
- Undo / redo

032) Entities and relationships (~3 minutes)

Entities:
- Game
- Board
- Player

Relationships:
- Game -> Board
- Game -> Player (2x)

043) Class design (~10–15 minutes)

Game — State:
- board: Board
- player_x / player_o: Player
- current_player: Player
- state: IN_PROGRESS | WON | DRAW
- winner: Player | None

Game — Behavior:
+ make_move(player, row, col) -> bool
+ get_current_player() -> Player
+ get_game_state() -> GameState
+ get_winner() -> Player | None
+ get_board() -> Board

054) Implementation (~10 minutes)

1. Happy path first — inputs, steps, collaborator calls, return/state change.
2. Edge cases next — invalid inputs, illegal operations, wrong state.
3. Write readable structure — language you use daily if they want real code.

def make_move(self, player, row, col) -> bool:
    if self.state != GameState.IN_PROGRESS:
        return False
    if player is not self.current_player:
        return False
    if not self.board.can_place(row, col):
        return False

    self.board.place(row, col, player.mark)

    if self.board.check_win(row, col, player.mark):
        self.state = GameState.WON
        self.winner = player
    elif self.board.is_full():
        self.state = GameState.DRAW
    else:
        self.current_player = (
            self.player_o if player is self.player_x else self.player_x
        )
    return True

boolean makeMove(Player player, int row, int col) {
    if (state != GameState.IN_PROGRESS) return false;
    if (player != currentPlayer) return false;
    if (!board.canPlace(row, col)) return false;

    board.place(row, col, player.mark);

    if (board.checkWin(row, col, player.mark)) {
        state = GameState.WON;
        winner = player;
    } else if (board.isFull()) {
        state = GameState.DRAW;
    } else {
        currentPlayer = (player == playerX) ? playerO : playerX;
    }
    return true;
}

Initial: empty board, current = X
make_move(X, 0, 0) → X at [0][0], current = O
make_move(O, 1, 1) → O at [1][1], current = X
…

065) Extensibility (~5 minutes, if time and level allow)

• Junior: little or no extensibility discussion.
• Mid: one or two small follow-ups.
• Senior: several “what if we…” questions in a row.

07Next

08Worked mini-example: 35 minutes on Tic Tac Toe

def session_skeleton():
    spec = clarify()           # 5m
    entities = nouns(spec)     # 3m
    api = verbs(entities)      # 10m  (make_move)
    implement(api.core_path)   # 10m
    if time_left():
        show_extension_seam()  # 5m

void sessionSkeleton() {
    Spec spec = clarify();           // 5m
    List<Entity> entities = nouns(spec);     // 3m
    Api api = verbs(entities);      // 10m  (makeMove)
    implement(api.corePath());   // 10m
    if (timeLeft()) {
        showExtensionSeam();  // 5m
    }
}

09Framework anti-patterns

• Spending 20 minutes on perfect UML with zero API.
• Implementing helpers before the main verb (make_move/enter/allow).
• Extensibility essay before a working happy path.
• Restarting design when asked a twist instead of pointing at a seam.

10Minute-by-minute checklist

1. Minute 5: v1 bullets written.
2. Minute 8: 3–6 entities with owners.
3. Minute 18: public methods named; one class sketched deeper.
4. Minute 28: happy + one failure traced.
5. Minute 33: one extension seam named (only if level asks).

11Common interview pitfalls

• Skipping requirements because the prompt “seems obvious.”
• Entity soup — twenty classes, no orchestrator.
• Implementing everything except the main user verb.
• Extensibility first, working path never.
• Freezing when twisted instead of pointing at a seam.

12Interview script (say this)

1. I’ll take five minutes to lock in/out of scope.
2. Then nouns that own changing rules — not every noun in the story.
3. Class design centers on the primary APIs.
4. I implement one happy path deeply.
5. I trace failure before I decorate with patterns.
6. If time and level allow, I show one extension seam.
7. I manage the clock out loud so we finish.
8. Ask me a twist whenever you want — I’ll absorb it at the seam.

13Extra verification traces

14Staff-level follow-ups

• Too slow on requirements? — Template questions; force-lock at minute 5.
• Interviewer hostile to patterns? — Use plain classes; introduce pattern only if asked.
• Ran out of time? — Narrate remaining methods; don’t silently code forever.

15Where concurrency fits in the 5-step spine

1. Clarify — ask: single-threaded OK, or must be thread-safe? Same machine only?
2. Model — mark which objects own shared mutable state.
3. APIs — note which methods are synchronized / need locks.
4. Implement — write the locked critical section, not just the happy path.
5. Verify — always narrate one two-thread race + the fix.