Requirements checklist

The rule edges are the conversation — surface all of them:

□ board configurable            size (default 100) + jump pairs as config
□ placement validity            nothing starts/ends on cell 1 or final cell
□ chains                        ladder onto snake head? YES — resolve fully
□ overshoot                     stay put, turn passes — house rule, swappable
□ players & turns               2-6, fixed order, all start at 0 (off-board)
□ win condition                 first to reach the final cell; game over
□ die                           one six-sided; a six is just a six in v1

The core model

Board          size + ONE jump map (snakes and ladders: same shape)
               constructor validates -> existing board = valid board
               resolve(cell): follow jumps until plain cell, cycle-guarded
MovementRule   target(pos, roll, size) -> cell | none (= stay put)
               strategy, because overshoot is a house rule with variants
Die            interface, one method -> tests inject a scripted die
Game loop      roll -> target -> resolve -> win-check; pure sequencing,
               contains NO rules; positions stored post-resolution only

Principles, at their decisions

• Cohesion: the jump map and chain resolution live together on the board; the chain rule exists in exactly one place.
• Validate at the boundary, then trust: the constructor throws on bad config; nothing downstream re-checks — plus a cheap cycle guard in resolve.
• Open/closed, with judgment: one MovementRule interface, one v1 implementation — a seam justified by known variants, not a rule-class zoo.
• Dependency inversion: randomness behind Die, because the game is untestable through a real die.

Complexity facts

turn            O(chain length) — worst case O(jumps), typically O(1)
resolve guard   bounded by jumps.size() hops, then loud failure
memory          O(jumps + players); positions are 6 integers
validation      O(jumps) at construction, once

What earns points, per report dimension

• Requirements & interface — you asked the chain question unprompted, pinned overshoot as a swappable house rule, and confirmed board configurability.
• Core design & invariants — four owners with one rule each; positions only ever stored post-resolution; a loop whose diff is empty under rule changes.
• Extension probe — the round will move the rules; name the seam that absorbs it (constructor-validator, Die, MovementRule) and what provably doesn't change.
• Complexity honesty — turns are chain-length bounded; the cycle guard's limit stated, not hand-waved.
• Communication — narrating roll → target → resolve → win-check while writing it, and voicing the terminal-state choice.

Ready? Sit the live mock → — the interviewer will run a twist this chapter deliberately hasn't shown you.