Implement 2048-Style Tile Slides and Merges for All Four Board Directions

Implement the move logic of a sliding-tile game played on a square board of numbered tiles. A move pushes every tile as far as it can go in one direction, and two equal tiles that meet merge into a single tile holding their sum. The interview built this in stages: first a move to the left, with tests that run, then all four directions. The planned follow-up, deciding whether the game is won or lost, was not reached and appears below as a follow-up question. The report does not spell out the rules. The left move, the four directions and the win-or-lose follow-up match the well-known 2048 game, so this question assumes its standard move rules: - The board is an `n × n` grid of integers; `0` is an empty cell and every other value is a tile. - A move slides every tile toward the side of the move, closing all gaps. - After the gaps close, two adjacent tiles with equal values merge into one tile with twice the value. - A tile created by a merge does not merge again in the same move. - When three or more equal tiles line up, the pair closest to the side of the move merges first. ```text Row before a left move Row after the move [2, 2, 2, 0] -> [4, 2, 0, 0] [2, 0, 2, 4] -> [4, 4, 0, 0] [4, 4, 4, 4] -> [8, 8, 0, 0] [2, 4, 8, 16] -> [2, 4, 8, 16] (nothing moves) ``` ### Clarifying Questions - Is the board always square, and what size is it? - Does a move also place a new tile on the board, and is a move that changes nothing allowed? - Should a move modify the board in place or return a new board, and should it report whether anything changed? - Is the score, the sum of the merged values, part of this exercise? ### Part 1 — Move left Implement `move_left(board)`, which applies a left move to the whole board, and write tests for it that you run before moving on. ```hint Solve one row first A left move treats every row independently. Get a single row right, including gaps between tiles and runs of three or four equal tiles, before handling the board. ``` #### What This Part Should Cover - Correct sliding and merging for one row, including the rule that a merged tile does not merge again - Applying the row logic to the board, and reporting whether the board changed - Tests for gaps, runs of equal tiles, full rows with no merges and empty rows ### Part 2 — All four directions Extend the code to `move(board, direction)` for `"left"`, `"right"`, `"up"` and `"down"`, without writing four separate copies of the merge logic. Two designs came up in the interview: adjusting how rows and columns are indexed so that each line of the board is read in the order of the move, and rotating the board so that every move becomes a left move. Implement one of them and be ready to compare it with the other; the interviewer favored rotation. ```hint Every move is a left move somewhere For each direction, work out which cells form one line and in which order they must be read so that the Part 1 logic applies unchanged, then decide how the results get written back. ``` #### What This Part Should Cover - One shared merge routine reused for all four directions - Correct results for every direction, including which end of a line merges first - A reasoned comparison of rotation and index remapping: clarity, risk of indexing bugs, and cost - Tests for each direction ### What a Strong Answer Covers - Confirms the merge rules, new-tile behavior and in-place versus copy semantics before coding - A short, correct line-merge routine that runs in time linear in the line length - Four directions without duplicated logic, and a clear argument for the chosen design - Tests written and run early, then extended to every direction - Readable code built from small, well-named functions ### Follow-up Questions - Add a check that reports whether the game is won (a tile has reached the winning value, 2048 in the original game) or lost (no move changes the board). Can you detect a loss without simulating all four moves? - After every move that changes the board, place a new tile on a random empty cell. How do you keep the move logic deterministic and testable? - Track the score, which grows by the value of every tile created by a merge. - Support undoing the last move.