Design Snake and Ladder

When Morgan Stanley runs a design round, "design Snake and Ladder" is a machine-coding prompt about craft. The interviewer is not asking you to serve a million concurrent games. They want to see you take a board game everyone learned as a child and turn it into a clean set of classes with the right responsibilities. Then they want the design pattern each moving part deserves, named. Snake and Ladder recurs here because the domain is instantly shared, so the whole conversation is about the modeling. What are the entities, how do they relate, where does the roll of the die live, and which patterns keep the design open to the twist the interviewer is about to add?

The game earns its place because every layer of the skill shows up. There is obvious entity modeling: a board of numbered squares, players with a token on a square, a die that produces a move, and snakes and ladders that teleport a token between squares. There is a real modeling decision hiding in plain sight. A snake and a ladder are the same thing, a jump from a start square to an end square, differing only in direction. A candidate who writes two near-identical classes has missed the abstraction the prompt is testing for. There is a rule with an edge to it: a token that would overshoot the final square stays put, so the game ends on an exact landing. And there is the pattern conversation the round is built around. Put the die behind a Strategy so it can be swapped for a scripted sequence, and build the board behind a Factory so setup is one call. Model those cleanly and the design reads as someone who writes production code. One giant class with a switch statement reads as someone who has only played the game.

The Morgan Stanley angle

Morgan Stanley is an enterprise-Java bank, so this round rewards clean objects and the right pattern named out loud. The technical loop leans hard on Core Java.