Zoox, the Amazon-owned Robotaxi company, started its first paid rides in Foster City and Las Vegas in Q1 2026. Zoox is unusual in the AV space: custom-built vehicle + custom-built full-stack software. As a result, its interview loop is broader than Waymo's or Cruise's — you can be asked about C++ embedded systems, ML perception, and ROS-style messaging frameworks in a single onsite.
This article is based on Q1-2026 onsite debriefs from three candidates (Perception SDE, Planning SDE, Embedded Systems). We'll break down all five stages and walk through two high-frequency coding questions with full solutions.
Zoox Interview Pipeline
| Stage | Duration | Content |
|---|---|---|
| 1. Recruiter Phone Screen | 30 min | Resume, "Why Zoox", role fit |
| 2. Hiring Manager Chat | 45 min | Project deep-dive + cross-team collaboration |
| 3. Technical Phone Screen | 60 min | 1 C++/Python coding question (CoderPad) |
| 4. Onsite Loop | 5 × 60 min | 2× Coding, Robotics system design, ML deep-dive, BQ |
| 5. Team Match | 1-2 weeks | No re-interviews — just team alignment |
Biggest difference from Waymo: Zoox coding questions skew toward systems engineering, not pure algorithms. Expect prompts like "implement a 200ms-tolerant sensor stream aligner", not "two-sum variant."
Coding Question 1: Sensor Time Sync (LiDAR + Camera)
Problem
Two time-stamped streams:
- LiDAR packets:
(ts_l, point_cloud), 10 Hz - Camera frames:
(ts_c, image), 30 Hz
Implement a sync function: for each LiDAR packet, find the camera frame closest in time, with a max diff of 50 ms — otherwise drop that LiDAR packet. Return all matched pairs.
Data may arrive out of order; must process online (streaming).
Approach
A Zoox-style problem: looks like LC Two Pointer but adds three real-world constraints — streaming, reorder, and tolerance.
- Maintain a camera buffer with deque; drop frames older than 50ms before current LiDAR ts
- For each LiDAR packet, wait until at least one later camera frame arrives — then decide
- Use a heap for the reorder window: buffer 200ms before committing
Python Solution
from collections import deque
import heapq
class SensorSync:
def __init__(self, tolerance_ms=50, reorder_window_ms=200):
self.tol = tolerance_ms
self.window = reorder_window_ms
self.cam_buf = deque()
self.lidar_q = []
self.matched = []
def push_camera(self, ts, frame):
self.cam_buf.append((ts, frame))
self._gc(ts)
def push_lidar(self, ts, packet):
heapq.heappush(self.lidar_q, (ts, packet))
self._gc(ts)
def _gc(self, now_ts):
while self.cam_buf and now_ts - self.cam_buf[0][0] > self.window:
self.cam_buf.popleft()
while self.lidar_q and now_ts - self.lidar_q[0][0] > self.window:
ts_l, packet = heapq.heappop(self.lidar_q)
self._match_one(ts_l, packet)
def _match_one(self, ts_l, packet):
best = None
best_diff = self.tol + 1
for ts_c, frame in self.cam_buf:
diff = abs(ts_c - ts_l)
if diff <= self.tol and diff < best_diff:
best, best_diff = (ts_c, frame), diff
if best is not None:
self.matched.append((ts_l, packet, best[0], best[1]))
def flush(self, max_ts):
self._gc(max_ts + self.window + 1)
return self.matched
Time: O(W) per event, where W is camera frames in window
Follow-up: How to drop _match_one to O(log W)? Use SortedList indexed by ts_c, then binary-search lower/upper bound.
Coding Question 2: Trajectory Smoothing
Problem
Given waypoints from Planner [(x, y, t)], discrete decisions cause velocity jumps between adjacent points. Implement sliding-window weighted smoothing:
- Odd window size k
- Center weight is highest, falls off linearly
- Border uses nearest-point mirroring
Must run online — output one smoothed point per incoming waypoint.
Approach
Classic weighted moving average plus Zoox real-world needs:
- Online → deque of last k points
- Normalize weights to avoid divide-by-zero at boundaries
- Must preserve monotonic timestamps — otherwise controller downstream oscillates
Python Solution
from collections import deque
class TrajectorySmoother:
def __init__(self, window=5):
assert window % 2 == 1
self.k = window
self.half = window // 2
self.buf = deque()
self.weights = [self.half + 1 - abs(i - self.half) for i in range(window)]
def push(self, x, y, t):
self.buf.append((x, y, t))
if len(self.buf) > self.k:
self.buf.popleft()
return self._smooth()
def _smooth(self):
pts = list(self.buf)
if len(pts) < self.k:
pad = self.k - len(pts)
left = pad // 2
right = pad - left
pts = [pts[0]] * left + pts + [pts[-1]] * right
wsum = sum(self.weights)
sx = sum(p[0] * w for p, w in zip(pts, self.weights)) / wsum
sy = sum(p[1] * w for p, w in zip(pts, self.weights)) / wsum
return (sx, sy, pts[self.half][2])
Time: O(k) per waypoint Bonus: Mention B-splines or Savitzky-Golay filter as next-step improvements — Planner team interviewers love it.
Robotics System Design
| Prompt | Focus |
|---|---|
| Design Robotaxi E-Stop chain | Safety redundancy, dual-channel arbitration |
| Multi-sensor data distribution across ROS-style topics | Pub/Sub, QoS, back-pressure |
| Replay 1TB/hour logs offline | Sharding, time index, downsampling |
| HD Map incremental updates across fleet | Delta sync, signature verification |
Draw an "actor + topic" diagram on whiteboard — Zoox internally uses an actor-based framework (LCM/ROS2-like), so this vocabulary scores well.
ML / Perception Deep Dive
Perception candidates get a dedicated theory + engineering round:
- 3D object detection (PointPillars, CenterPoint, BEVFusion) fundamentals
- Inference optimization: TensorRT, quantization, ONNX gotchas
- Augmentation: synthetic night, synthetic rain for AV scenes
- Active learning over billions of frames
The deepest probes are on evaluation metrics — mAP vs NDS (nuScenes) and why NDS weighs 5 sub-metrics.
Behavioral / Leadership
Zoox cultural keywords:
- Customer Obsession (Amazon DNA)
- Earn Trust — resolving cross-team conflict
- Are Right, A Lot — a decision you got wrong and how you corrected
- Frugality — validating a risky idea at minimum cost
Keep each BQ STAR-formatted in under 3 minutes, leaving room for "what if you'd chosen alternative X" follow-ups.
FAQ
Q1: Zoox vs Waymo / Cruise difficulty?
Algorithm rigor: Waymo > Cruise > Zoox Engineering depth: Zoox > Waymo > Cruise Zoox prompts are closer to "code shipping tomorrow." Less LC-Hard, more system reasoning. Pure ML research candidates can stumble on Round 4 engineering questions.
Q2: Is Zoox still hiring in 2026?
After Foster City commercial launch in Q1 2026, Perception / Planning / Vehicle Software are actively hiring; Mapping and Cloud headcount is tighter. Check LinkedIn before applying.
Q3: Is onsite Zoom or in-person?
Hybrid: All phone screens online, onsite defaults to Foster City with travel reimbursed. Remote onsite is possible but only ~60% acceptance — hiring managers weigh whether they need to see you whiteboard live.
Q4: Which language for coding?
Robotics / Perception / Planning: strongly prefer C++ (your interviewer ships C++). Cloud / Infra / Simulation: Python is fine. ML Research: PyTorch + Python.
Q5: How to prepare ROS / AV fundamentals?
From zero:
- Read ROS2 "Concepts" docs (2 hours)
- Get Autoware.Auto demo running (half day)
- Read Apollo Planning module source (1 week)
- Skim nuScenes / KITTI README (30 min)
Afterwards you can speak intelligibly about publisher/subscriber, TF tree, launch files — enough for Zoox baseline.
Q6: Does Zoox hire new grad / intern?
Yes. PhD in robotics / vehicle engineering has highest priority; pure SWE new grads typically land Cloud / Tools / Simulation. ~30 interns per year, 2025 conversion ~50%.
Preparing for Zoox / Waymo / Cruise autonomous-driving interviews?
AV interviews demand both algorithmic depth and systems engineering sense — LeetCode grinding alone is no longer enough. We've assembled 2026 question banks for Zoox / Waymo / Cruise / Aurora / Wayve and prep tracks across Perception / Planning / Embedded.
Add WeChat Coding0201 or contact us.
Contact
Email: [email protected] Telegram: @OAVOProxy