Design a robot movement command system

Read the full interview experience this question came from →

Quick Overview

This question evaluates design and implementation skills for an extensible, command-driven robot movement system, covering state representation on a 2D integer grid, directional updates, command dispatching, input/output semantics, and explicit handling policies for invalid commands.

Design a robot movement command system

Company: Shopify

Role: Machine Learning Engineer

Category: Coding & Algorithms

Difficulty: easy

Interview Round: Technical Screen

## Robot Movement (Pair Programming) You are given an empty starter repository (only a README). Implement a small, testable robot movement module that can: - Represent a robot on a 2D grid. - Receive a sequence of user commands. - Execute those commands to update the robot’s position and direction. - Be easily extensible as new valid commands are added over time. ### Requirements 1. **Robot state** - The robot has a position `(x, y)` on an integer grid. - The robot has a facing direction: one of `{N, E, S, W}`. 2. **Commands (initial set)** Support at least these commands: - `L`: rotate 90° left (N→W→S→E→N) - `R`: rotate 90° right (N→E→S→W→N) - `F`: move forward by 1 step in the direction it is currently facing 3. **Input / Output** - Input: initial state `(x0, y0, dir0)` and a command string like `"FFLFFR"` (or an equivalent list/array of commands). - Output: final state `(x, y, dir)` after executing all commands. 4. **Invalid command handling** - Define and implement a clear policy for unknown commands (e.g., throw an error, ignore, or collect errors). State your choice. 5. **Extensibility constraint (core design requirement)** - Assume **valid commands will keep expanding** (e.g., `B` for backward, `J` for jump, `U` for undo, etc.). - Design the command system so adding a new command does **not** require rewriting large parts of the robot execution logic. - Discuss/implement a command abstraction (e.g., command objects, a registry/dispatcher, etc.). 6. **Testing** - Write small, incremental tests as you implement. - After finishing, explain: - What else you would optimize. - How you would do **systematic testing** (unit tests, property-based tests, edge cases). ### Example - Initial: `(0, 0, N)` - Commands: `"FFRFF"` - Expected final: `(2, 2, E)` ### Constraints (you may assume) - Command string length: up to ~10^5. - Grid is unbounded (no walls/obstacles) unless you explicitly choose to add bounds as an extension. Implement the core classes/functions (e.g., `Robot`, command execution/dispatcher) and demonstrate with tests.

Overview: This question evaluates design and implementation skills for an extensible, command-driven robot movement system, covering state representation on a 2D integer grid, directional updates, command dispatching, input/output semantics, and explicit handling policies for invalid commands.

Read the full Shopify Machine Learning Engineer interview experience this question came from

Shopify logo
Shopify
Dec 15, 2025
easyMachine Learning EngineerTechnical ScreenCoding & Algorithms
90
0

Robot Movement (Pair Programming)

You are given an empty starter repository (only a README). Implement a small, testable robot movement module that can:

  • Represent a robot on a 2D grid.
  • Receive a sequence of user commands.
  • Execute those commands to update the robot’s position and direction.
  • Be easily extensible as new valid commands are added over time.

Requirements

  1. Robot state
    • The robot has a position (x, y) on an integer grid.
    • The robot has a facing direction: one of {N, E, S, W} .
  2. Commands (initial set) Support at least these commands:
    • L : rotate 90° left (N→W→S→E→N)
    • R : rotate 90° right (N→E→S→W→N)
    • F : move forward by 1 step in the direction it is currently facing
  3. Input / Output
    • Input: initial state (x0, y0, dir0) and a command string like "FFLFFR" (or an equivalent list/array of commands).
    • Output: final state (x, y, dir) after executing all commands.
  4. Invalid command handling
    • Define and implement a clear policy for unknown commands (e.g., throw an error, ignore, or collect errors). State your choice.
  5. Extensibility constraint (core design requirement)
    • Assume valid commands will keep expanding (e.g., B for backward, J for jump, U for undo, etc.).
    • Design the command system so adding a new command does not require rewriting large parts of the robot execution logic.
    • Discuss/implement a command abstraction (e.g., command objects, a registry/dispatcher, etc.).
  6. Testing
    • Write small, incremental tests as you implement.
    • After finishing, explain:
      • What else you would optimize.
      • How you would do systematic testing (unit tests, property-based tests, edge cases).

Example

  • Initial: (0, 0, N)
  • Commands: "FFRFF"
  • Expected final: (2, 2, E)

Constraints (you may assume)

  • Command string length: up to ~10^5.
  • Grid is unbounded (no walls/obstacles) unless you explicitly choose to add bounds as an extension.

Implement the core classes/functions (e.g., Robot, command execution/dispatcher) and demonstrate with tests.