# Getting hired at Physical Intelligence, the robot foundation lab

Source: https://www.techinterview.org/post/3233477140/physical-intelligence-interview-guide/
Updated: 2026-08-02 · techinterview.org

Physical Intelligence hires like a research lab that happens to ship robots, and the interview reflects that split. The company is training one model, the π0 line, that can drive many different robots to fold laundry, bus a table, or assemble a box, instead of hand-tuning a separate controller for each task. The loop is built to find people who can push that kind of general-purpose model forward, or keep a fleet of real robots running while it learns. Walk in expecting a standard LeetCode grind and you'll misread the room.

Look at who is on the other side of the table. The founding team came out of Google DeepMind and the robot-learning groups at Berkeley and Stanford: Karol Hausman as CEO, with Sergey Levine, Chelsea Finn, Brian Ichter, and others. That pedigree sets the bar. Research interviews resemble the ones you'd get at a frontier language-model lab, and even the systems roles get pressed on whether you understand what the model needs from the infrastructure you're building.

## Why the money changes the questions

Physical Intelligence raised a $400 million Series A in late 2024 at roughly a $2.4 billion valuation, then a round in November 2025 that put it near $5.6 billion, with backing from CapitalG, Thrive, Lux, and Jeff Bezos among others. There has since been talk of raising again at a materially higher mark. Figures like these move fast, and a private company's equity is only worth what the next round and an eventual exit say it is, so treat any number you read as a snapshot. What matters for the interview is what the funding pays for: a lot of physical robots, a lot of compute, and a mandate to train one policy across many robot bodies rather than scripting each one.

That mandate is why they screen for vision-language-action (VLA) modeling, imitation learning from teleoperated demonstrations, and the unglamorous plumbing that moves camera frames and proprioception in and motor commands back out, over a network, at control-loop speed. π0 was open-sourced in early 2025, so you can read the real architecture before you interview, which is the best prep move on the board. Candidates who have run the released checkpoint and can talk about its flow-matching action head, action chunking, or why the model conditions on a language instruction walk in with a genuine edge.

## The tracks and how they diverge

There isn't one interview. The loop forks early depending on whether you're aiming at research, model-adjacent software, or the fleet side, and the rounds pull apart from there.

| Interview track | What the role does | Main interview emphasis | Signature question |
| --- | --- | --- | --- |
| Research scientist / engineer | Advance the π0-line VLA models and training recipes | Robot-learning depth, paper defense, distribution shift, data strategy | Where does π0 break on a robot it never saw in training? |
| Runtime / robotics software engineer | Low-latency inference and control systems on real robots | Real-time systems, C++ and Python, concurrency, profiling | Bridge a 200 ms model to a 20 ms control loop. |
| Robot integration / fleet engineer | Keep the physical robot fleet reliable and calibrated | Hardware debugging under uncertainty, sensors, firmware | A robot regressed on a task it used to pass. Isolate why. |
| ML infrastructure / data | Training pipelines and trajectory data at fleet scale | Distributed data systems, versioning, throughput | Version and replay a week of trajectories across 30 machines. |

Research scientists and research engineers get the heaviest scrutiny on learning. Expect a long conversation about a paper you claim to know cold, then steady pressure on the parts you skated over. A common opener sounds like this: "Walk me through how π0 turns a language instruction and a camera image into motor commands, and tell me where that pipeline breaks on a robot it never saw in training." They're watching whether you reason about distribution shift, data coverage, and the gap between a clean benchmark number and a robot that actually finishes the task in a stranger's kitchen. Vague enthusiasm about "generalization" dies quickly; a specific account of why behavior cloning compounds errors survives.

## The runtime and systems rounds

Runtime and robotics software engineers face a different test. The job is low-latency, high-throughput systems work: pulling images off the cameras, running inference, and getting actions back to the actuators fast enough to matter. Interviewers ask about the operating system, the camera pipeline, serialization, zero-copy paths, and where a garbage-collection pause or a Python GIL stall would wreck a 50 Hz loop. A representative prompt: "Your model takes 200 ms per inference but the arm needs a command every 20 ms. How do you bridge that?" A strong answer reaches for action chunking and asynchronous inference, running the policy ahead and interpolating between commands, rather than adding threads and hoping.

You'll also get ordinary coding, weighted toward systems fluency. C++ and Python both come up; the runtime and autonomy stack leans on tight C++ with Python for research speed. Concurrency, memory layout, and profiling are fair game. If your entire career has been application code behind a web framework, this is the round that finds out.

## Robot integration and the fleet

Integration and fleet engineers keep physical hardware alive, so their interview is heavy on debugging under uncertainty. They'll describe a robot that started failing a task it used to pass and ask how you'd isolate the cause: calibration drift, a sensor fault, a firmware regression, or a model that quietly degraded after a data change. Staying calm and methodical about a messy, half-instrumented failure counts for more than reciting a named algorithm. People who have actually run hardware, and felt how sim-to-real betrays you, tend to shine in this round.

## Questions phrased the way they land

Across tracks, a handful of flavors recur. Some are research-shaped, some are systems, some just probe judgment:

- "Why does imitation learning from human teleoperation compound errors at test time, and what reduces it?"

- "You have 100 hours of demonstrations for task A and 2 hours for task B. How do you get decent performance on B?"

- "Design the data pipeline that logs and versions a week of robot trajectories collected across 30 machines, and can replay any slice of it."

- "A policy scores 95% in evaluation and 60% on real robots. Where did the 35 points go?"

- "Explain flow matching or diffusion for action generation to someone who understands classification but not generative models."

None of these are trick puzzles. They're the arguments the team is already having internally, which is the tell: they want to know whether you'd be useful in that argument next week.

## Comp, and what to actually weigh

Physical Intelligence pays in the frontier-lab band, which means a competitive base and equity that is the real variable. At a private company, that equity is a bet on future rounds and eventual liquidity, not cash you can spend. Research roles at labs of this tier usually carry the highest total numbers, with strong software and systems roles close behind, though titles and levels blur at a company this young. Rather than anchoring on one figure someone posted online, ask the recruiter for the base range, the option or RSU count, the current strike or preferred price, and the vesting schedule, then value the equity yourself against the last known valuation. Weigh other offers on near-term cash if you need certainty, and on equity upside if you believe robot foundation models become the next platform.

## Preparing without burning weeks

Read the π0 and π0.5 write-ups, then pull the open-source checkpoint and run it if you can get a machine. Being able to say "I ran the model, here's what surprised me" changes the whole conversation. Refresh the fundamentals of imitation and reinforcement learning: behavior cloning, DAgger, and the reasons offline data and online performance drift apart. For systems roles, be sharp on real-time constraints, the true cost of a memory copy, and how you'd profile a loop that keeps missing its deadline. For every track, keep one project you can defend down to the studs, because interviewers will keep asking "why" until they reach either your understanding or its edge.

The people who struggle here are usually strong generic engineers who treat a robot as an API. The ones who get offers hold opinions about where learned control breaks and carry some scar tissue from making a real system work. If you've spent a weekend fighting a jittering control loop or a sim-to-real gap that refused to close, bring that story. It travels further at Physical Intelligence than another perfectly solved graph problem.