Why this matters: snake and ladder is the machine-coding prompt most likely to make a candidate relax — everyone played it as a child, the rules feel obvious, and the model is tiny. That comfort is the danger. The interview isn't about knowing the game; it's about noticing that "the rules feel obvious" hides half a dozen genuinely ambiguous decisions, and that a configurable board opens a whole category of invalid inputs the childhood version never had.

The prompt, as given

Design the game of snake and ladder.

Players take turns rolling a die and moving along a numbered board. Landing at the bottom of a ladder carries you up; landing on a snake's head slides you down. First player to the final cell wins.

Three sentences, and every one of them is underspecified. "A numbered board" — how big, and is that fixed? "First to the final cell" — what if your roll takes you past it? "Carries you up… slides you down" — what if a ladder deposits you directly onto a snake's head? None of this is in the prompt, and all of it changes the code.

The questions — and why each one matters

"Is the board configurable?" Yes — size (100 by default) and the snake/ladder placements both arrive as configuration. This single answer reshapes the problem: a hard-coded classic board needs no validation, but a configured board can be nonsense — a ladder starting on the final cell, a snake ending below cell 1, two jumps sharing a start. Configuration is where the defensive-design points in this problem live.

"What placements are legal?" No snake or ladder may start or end on cell 1 or on the final cell. Ask this even if you suspect the answer, because it defines the validator you'll write.

"Can jumps chain?" The sharpest question in the round: a ladder drops you on a cell that is also a snake's head — do you slide? Yes, chains resolve fully — you keep following jumps until you land on a plain cell. This turns "apply the jump" into "apply jumps until stable," a loop rather than a lookup, and it's exactly the kind of rule that silently breaks single-lookup implementations.

"What happens on overshoot?" You're on 98 and roll a 5. Our rule: the move doesn't happen — you stay put and the turn passes. Flag, while you're there, that this is a house rule with variants (some tables bounce you back off the end), so it deserves to be swappable rather than buried in the movement code.

"How many players, and how do turns work?" Two to six, taking turns in a fixed order, everyone starting off the board at position 0. Win is reaching the final cell; the game ends there in v1.

"How many dice?" One standard six-sided die. Rolling a six is just a six — no special turn rules in v1. Worth confirming explicitly, because many house versions differ here, and the die count itself is a classic extension axis.

The requirement set this chapter builds against

Board        size configurable (default 100); snakes & ladders are
             configured (start, end) pairs
Validity     no jump may start or end on cell 1 or the final cell;
             validate at setup, guard defensively in play
Chains       allowed — jumps resolve repeatedly until a plain cell
Overshoot    roll past the final cell => stay put, turn passes
             (house rule; keep it swappable)
Players      2-6, fixed turn order, all start at position 0 (off-board)
Win          first to reach the final cell; game over in v1
Die          one six-sided die; a six carries no special turn rules in v1

As with every chapter in this course: a live interviewer's answers may differ — their table might bounce on overshoot or forbid chains outright. The conversation is the skill; this answer sheet is just the one we build against.