Generalist AI is one of the harder robotics startups to interview at right now, mostly because the team is small (under 100 people) and the people reviewing your work wrote the papers you probably cited in grad school. Andy Zeng and Pete Florence spent years at Google DeepMind on robot learning; Andrew Barry spent about five years as a senior roboticist at Boston Dynamics. The bar reflects that. This is a company betting that a single learned model can control many robot embodiments, and its recently announced Gen 1.5 model claims to pick up new tasks from video demonstrations as short as 3 to 12 seconds. If that pitch excites you, the interview will test whether you can actually build toward it.
Before anything else: Generalist has not published a formal interview process, and with a team this size the loop varies by role and by who’s hiring. Treat everything below as a well-grounded composite from how comparable robotics foundation model shops hire, not a leaked rubric. This guide is aimed at experienced ML, robotics, and infrastructure engineers. The people reviewing you ship real robot policies, and the ex-DeepMind and Boston Dynamics bar is a senior-to-research one. At under 100 people, entry-level pipelines are thin and internships aren’t a confirmed track, so new grads and career-changers should set expectations accordingly.
On logistics, confirm the specifics with your recruiter, because a controls role and a pretraining-infra role look almost nothing alike here. For shops this size, expect the end-to-end loop to run roughly two to five weeks from recruiter screen to offer, faster if they’re moving on you. Technical rounds at early robotics startups are usually live rather than take-home, though some infra roles add a short take-home or a project walk-through. The company is based in San Mateo; whether a given role is onsite, hybrid, or remote, and whether Generalist sponsors visas at this stage, are both unconfirmed at this headcount, so ask before you invest a full loop.
What Generalist is actually screening for
The through-line across every round is production sense. Boston Dynamics DNA shows up as a bias toward engineers who get a thing working on real hardware, under real latency, with real failure modes, instead of proving it works in a slide. The DeepMind side shows up as a bar on ML fundamentals: you should be able to reason about data, losses, and evaluation for a policy the same way an infra engineer reasons about throughput and backpressure.
Concretely, they tend to probe four things. Can you write correct, fast code under time pressure. Do you understand modern robot learning (imitation learning, diffusion policies, vision-language-action models) well enough to argue tradeoffs. Can you design the unglamorous systems that make a foundation model possible: teleoperation data pipelines, fleet logging, eval harnesses, sim. And do you actually want to work on general-purpose robots, versus wanting a hot AI logo on your resume. The last one matters more at a sub-100-person company than it does at a 10,000-person one.
One honest note for the non-robotics senior: strong ML or infra engineers without hands-on robot-learning experience do get hired here, mostly for data and training infrastructure. But for modeling and research roles, robotics depth is close to a hard gate, not a nice-to-have.
The round structure
A typical loop for an ML or robotics engineering role runs four to six conversations after the recruiter call. Research-scientist loops lean harder on your publication record and a paper deep-dive; infrastructure loops lean toward systems and data. This is the shape most candidates for these roles see across the robotics foundation model space, including peers like Physical Intelligence and Skild AI.
| Stage | Format | What it tests | Rough length |
|---|---|---|---|
| Recruiter screen | Call | Background, motivation for robotics, role fit, comp expectations | 30 min |
| Technical screen | Live coding or ML fundamentals | Correct code fast, or core ML reasoning (losses, data, eval) | 45-60 min |
| ML / robotics depth | Discussion + whiteboard | Imitation learning, VLA models, sim-to-real, policy design | 45-60 min |
| Systems / data infra | Design | Teleop data pipelines, fleet logging, training infra, eval harnesses | 45-60 min |
| Research / project deep-dive | Presentation or Q&A | Your past work in depth, ownership, technical judgment | 45-60 min |
| Mission / team fit | Conversation, often with a founder | Why Generalist, how you work, ambiguity tolerance | 30-45 min |
The coding and ML screen
The coding screen is closer to practical engineering than to a LeetCode grind. You should still be fluent with the core coding patterns, but expect problems with a robotics or data flavor. A common one: implement a ring buffer for streaming sensor data at 100 Hz and reason about what happens when a consumer stalls. Or parse and align two time-series streams (say, camera frames and joint states) that arrive at different rates with clock skew. Python is the default; some hardware-adjacent roles ask for C++.
If your screen is ML fundamentals instead, the questions are conceptual but sharp. Expect things like “explain the difference between behavior cloning and a diffusion policy, and when behavior cloning fails,” or “you have 10,000 teleoperation episodes across three robot types; how do you turn short video demos into a training signal, and what’s your loss.” They’re listening for whether you reach for the right tool and can name the failure mode, not for a memorized definition. This is a good place to sanity-check your prep against how AI-era interviews have shifted toward reasoning out loud over recall.
The robotics and foundation model round
This is the round that separates people who’ve done robot learning from people who’ve only read about it. Questions are open and you’re expected to drive. Some phrasings you’re likely to hear:
- “How would you handle different action spaces across embodiments, say a 7-DOF single arm versus a bimanual mobile platform, in one policy?”
- “Walk me through how a vision-language-action model grounds a language instruction into actions. What do you lose by tokenizing continuous actions?”
- “Your policy works in sim and fails on the real robot. Walk me through how you debug that, in order of what you’d check first.”
- “Design an evaluation for a manipulation policy. What metrics, and how do you keep from overfitting to your own eval set?”
The sim-to-real and evaluation questions are where strong candidates pull ahead. Anyone can say “domain randomization.” Fewer people can talk concretely about why a policy that nails a task in sim whiffs on real friction and lighting, or why eval design is the hard part of robot learning when your test distribution drifts every time you change the data. Bring a real story about an eval you built or a sim-to-real gap you actually closed.
The systems and data-infrastructure round
A robotics foundation model is a data and infrastructure problem as much as a modeling one, so this round carries real weight even for research-leaning candidates. It rhymes with a classic system design interview, just pointed at robots. A representative prompt: “Design the data pipeline that ingests teleoperation demonstrations from a fleet of heterogeneous robots, versions it, and makes it queryable for training.” Follow-ups push on schema for multimodal data (video, proprioception, actions), how you deduplicate and filter low-quality episodes, how you handle petabyte-scale storage and retrieval, and how you keep training reproducible when the dataset changes weekly.
Good answers name the boring problems early: clock synchronization across sensors, backfilling labels, quarantining bad episodes before they poison a run, and building an eval harness that runs automatically on every candidate checkpoint. If you’ve built ML data infrastructure at any scale, tell that story in detail here.
Behavioral and mission fit
The behavioral bar is lighter on process and heavier on judgment and drive than at a big company. There are no Amazon-style leadership principles to recite, but a structured STAR answer still lands better than a ramble. Expect “tell me about a project you owned end to end,” “a time you were wrong about a technical decision,” and a genuine “why robots, and why now.” At a small, well-funded company moving fast, they’re screening out people who need a spec handed to them and people who are chasing the valuation. Have a real answer for why general-purpose robotics, specifically, is worth years of your life.
Compensation
Generalist does not publish comp, and with a company this small there’s no reliable public dataset yet, so treat any number you see online with suspicion. What’s safe to say: it’s a Bay Area robotics startup that just raised $600M total and is competing for the same senior ML and robotics talent as Physical Intelligence and Skild AI, so cash offers sit in the competitive Bay Area AI-startup band and equity is where the real upside (and real risk) lives. Senior engineers at well-funded Bay Area AI startups commonly see base salaries in the low-to-mid $200Ks with meaningful early-stage equity on top, but the range is wide and role-dependent.
Because so much of the package is equity at a reported $3B valuation that could go up a lot or evaporate, model it seriously instead of eyeballing the headline number. Run the offer through a total comp calculator, ask your recruiter for the strike price, current preferred price, and vesting schedule, and read up on how to negotiate a startup offer before you accept. Ask directly what percentage of the company your grant represents; at this stage that number is more honest than any dollar figure.
How to prep
If you’re targeting a modeling or research role, be ready to defend your own work line by line and to argue current robot learning tradeoffs (imitation versus RL, diffusion policies, VLA architectures, how you’d use short video demos) like you argue with a labmate. If you’re targeting infra, rehearse a data-pipeline and eval-harness design end to end. Everyone should keep coding sharp on practical, streaming-data problems rather than pure puzzle grinding. For broader context on how these research-first startups run their loops, the AI-native company guides and the AI-startup interview difficulty index are worth a read before your onsite.
The candidates who do well here aren’t the ones with the most papers or the cleanest LeetCode record. They’re the ones who can point at a robot that did something new because of code they wrote, and explain exactly why it worked. That’s the whole company in one sentence, and it’s what every round is quietly checking for.
Practice the behavioral round:
