What to Expect in the Boston Dynamics System Design Interview

Boston Dynamics tests design skills through robotics-flavored sessions in the onsite loop, not a standard web-scale design round. Candidates report design discussions about robot software architecture and fleet-level systems, with hard probes on failure cases. Candidates report three example probes. What happens when time synchronization drifts between robots? What happens when a perception model becomes less reliable after a camera change? How do you enforce safety margins in motion planning? The company also builds Orbit, its fleet management software, so cloud-side design questions have a natural product anchor.

What Makes This Round Different

A normal system design interview assumes servers, databases, and web clients. Here the "clients" are robots: Spot inspecting industrial sites, Stretch unloading trucks, Atlas working in factories. That changes the design space in three ways.

First, the physical world is the main source of failure. Sensors degrade, batteries drain, and networks drop mid-mission. Second, timing is a real constraint. Control loops run many times per second, so latency budgets are strict and measured in milliseconds. Third, safety is a requirement, not a feature. A wrong answer from your system can move a heavy machine near a person.

Interviewers reward candidates who treat these constraints as requirements from the first minute.

The Question Types

• On-robot architecture. How software is organized on the robot: perception (understanding sensor data), planning (choosing actions), and control (executing motion). Expect questions about what runs where and at what rate.
• Fleet management systems. Design the cloud side for a fleet of robots on customer sites. This mirrors Orbit: missions, telemetry, maps, and health dashboards.
• Data pipelines. Robots produce heavy sensor data, including video. Design ingestion, storage, and review tools for it.
• Failure and safety reasoning. Given a design, interviewers change one assumption and watch you adapt. The reported probes above are this type.

A Worked Example: An Inspection Robot Fleet

Here is a high-level path through a fleet management question.

Requirements first. Assume 2,000 robots across hundreds of customer sites. Each runs scheduled inspection missions and collects readings and images. Operators need mission scheduling, live status, and alerts.

On-site connectivity. Sites have weak or restricted networks. Each robot buffers mission data locally and uploads when connected. A site gateway can batch uploads for several robots.

Cloud ingestion. An API gateway authenticates robots and writes events to a message queue, a buffer that holds events until services process them. Heavy files like images go directly to object storage, with references in the event stream.

Services. A mission service stores schedules and results. A telemetry service keeps recent robot state for live dashboards. An alert service evaluates rules, such as a reading above a threshold, and notifies operators.

The probes. Expect the reported failure questions here. If robot clocks drift, event ordering breaks, so use server-side timestamps plus sequence numbers per robot. If a camera change degrades perception, add model health monitoring: track confidence scores and flag drops for review. For safety margins, keep enforcement on the robot, never dependent on the cloud link.

What Interviewers Evaluate

The evaluation centers on constraint handling. State latency, bandwidth, and reliability assumptions early, with numbers. Separate what must run on the robot from what can run in the cloud. Explain your degraded modes: what the robot does when the network, a sensor, or the cloud fails. Candidates who present a clean happy path and no failure story do poorly here. Depth in robotics fundamentals counts more than breadth of web components.

How to Prepare

• Master the core building blocks. Queues, object storage, time-series data, and stream processing appear in every fleet question. Grokking the System Design Interview teaches them through worked designs.
• Study distributed-system failure patterns. Clock drift, retries, and idempotency are exactly what the probes test. Grokking the System Design Interview II goes deeper on these topics.
• Rehearse the edge-then-cloud split. For any robot system, practice stating what runs on the machine and what runs remotely, and why.
• Prepare the rest of the loop. See What Is the Boston Dynamics Interview Process Like? (Round by Round) for the stages, and Top Boston Dynamics Behavioral Interview Questions (and How to Answer Them) for the behavioral sessions.