About Niantic Spatial

AI has learned from almost everything online, but it still struggles with the physical world, where 99.5% of economic activity happens. It doesn’t know where things are, how spaces fit together, or what changes over time.

That’s one of the biggest unsolved problems in AI, and it’s the one we’re solving at Niantic Spatial. We build spatial AI models and services so people and machines can reason, learn and act safely in the physical world. We turn camera imagery, video, sensor data and archives into accurate, AI-readable representations of real places that robots can train in and machines can use to know exactly where they are.

In physical AI, mistakes have real consequences. That’s why we build AI grounded in measured reality, not guesswork, so the people and machines relying on it can trust it to get things right.

Our team built some of the world’s most widely used maps. Now we’re building something bigger: a living, measured record of the real world that machines can query, learn from and use to understand how places change over time. If you want to help AI understand the world we actually live in, come build with us.

About the Real-World Test Lab (RWTL)

Physical AI doesn't get graded on a leaderboard. It gets graded on a factory floor at shift change, in a substation with no GPS, on a site where the lighting is wrong and the stakes are real.

The Real-World Test Lab closes the gap between the benchmark and the field. We bring the customer's world inside our walls — their devices, their environments, their hardest conditions, and their definition of success — and make it the bar every release has to clear.

As Niantic Spatial's first and most demanding customer, we push our reconstruction, localization, and spatial understanding to their limits, find where they shine and where they break, and turn that into evidence that shapes what we build next. It's a new team at the frontier of physical AI, and you'll help invent how the job is done.

About the Role

We're hiring a Hardware Operations Engineer with a robotics specialism, reporting to the Director of the Real-World Test Lab, to own the physical layer of our evidence. You'll manage our fleet of capture devices and robots, engineer the test environments and the instrumentation inside them, support the captures our data programs depend on, and run physical test sessions, including the real-robot side of our sim-to-real work.

A physical run only counts as evidence if the hardware is characterized, the environment is controlled, the ground truth is trustworthy, and someone can reproduce the run months later. You'll build what makes that possible: fixtures, ground-truth references, calibration and data-offload tooling, and the integrations that feed physical runs into the same automated evaluation system as everything else.

You engineer the conditions, not just the setup. When a physical result didn't match expectations, you've worked out whether the hardware, calibration, environment, or system under test was responsible. Then you built the rig, reference, or logging that kept the question from coming back. You know an uninstrumented physical test is an anecdote, and in the Lab you'll be the person who can say with authority whether a strange result is real.

What Success Looks Like

30 days: Fleet inventory and characterization baseline complete, safe operating procedures defined for current spaces, and first instrumentation gaps identified.

60 days: First physical robot run executed with ground-truth instrumentation, documented well enough to repeat, with results in the Lab's evaluation system.

90 days: Test environments in regular use with controlled, documented conditions; capture support running smoothly with our data acquisition team; and the physical side of sim-to-real running on a standing instrumented protocol.

What You'll Do

Own and Characterize the Fleet - Manage our capture devices, sensors, and robots end to end: inventory, calibration, firmware, maintenance, logistics, and spares. Characterize what each platform can and cannot do, so a device's limits are a known quantity rather than a surprise inside a result.