Frontend Grid: Robot Eats Candies

Frontend phone screen for a Snowflake frontend role: implement a small JavaScript game where a robot navigates a grid eating candies. Grid scaffolding and helper functions are provided. Requirements A grid is pre-rendered in the DOM; helper functions for cell access and rendering are provided. A robot starts at a known cell; candies are placed at specified cells. Implement the JavaScript logic that moves the robot through the grid and removes candies as it visits them. The exact movement rules (player-controlled vs autonomous shortest-path) are clarified during the round; both have been reported. Notes Snowflake's frontend phone screen does not always announce itself as frontend-only — confirm with the recruiter before the round whether to prepare LeetCode or DOM / JS exercises. The interviewer's background (frontend-focused vs full-stack) is a strong hint. For autonomous movement, the natural algorithm is BFS from the robot's current cell to the nearest candy, re-running after each candy is consumed (or to all candies in one pass with multi-source BFS variants). For player-controlled movement, the work is largely event-handling boilerplate: keyboard listeners, debounced re-renders, state update on cell entry, candy removal. Familiar JS / DOM idioms (event delegation, requestAnimationFrame for smooth re-renders, basic state object) are the assumed baseline — interviewers expect candidates to write these without referring to documentation. Edge cases: robot on a wall, multiple candies in the same cell (should there be?), grid boundary handling, robot collides with itself or with previously-cleared cells. Preparation Refresh vanilla-JS DOM event handling: addEventListener on document for keyboard input, cell-id-keyed lookups for rendering. Drill BFS on a 2-D grid in JS (no Python crutch); know the array-of-arrays vs flat-array trade-offs. Prepare a simple state object: { robot: {x, y}, candies: Set<"x,y">, grid: number[][] }. Re-render after each state mutation.