Apptronik is the Austin humanoid-robotics company behind Apollo, a general-purpose robot aimed at warehouses and manufacturing lines. In February 2026 it closed a $520M Series A extension at roughly a $5B valuation, with Google, Mercedes-Benz, B Capital, and PEAK6 in the round, reportedly pushing total Series A financing past $935M. Apollo is also a named target embodiment for Google DeepMind’s Gemini Robotics, which means some of the most interesting learning-on-hardware work in the industry runs through this company. If you’re interviewing here, you’re interviewing for a job where the code you write moves a two-meter machine that weighs more than you do. That framing shapes every round.
The team is still small for its valuation, reported to be growing past 300 people, so hiring is deliberate and the loop leans senior. This is part of the broader AI-robotics hiring wave that also includes Figure, 1X, and the physical-AI research labs, and the interview style rhymes with those companies more than it does with a big-tech coding loop.
The rounds, in order
Drawing on Glassdoor interview reports and Apptronik’s own posted role descriptions, the loop has a fairly consistent shape: a recruiter phone screen, a hiring-manager conversation, and then a day-long onsite of four to five back-to-back sessions. The first two rounds are remote. The onsite is in-person at the Austin office, and expecting to travel for it is the safe assumption unless your recruiter says otherwise. Glassdoor puts the average process at about 16 days and rates difficulty a shade under 3 out of 5, which sounds gentle but undersells it. The difficulty isn’t puzzle trickiness. It’s whether you can hold up under an engineer who keeps asking “and then what happens?” until you hit the edge of what you actually understand.
The recruiter screen is logistics and motivation: why humanoids, why Apptronik over Figure or Tesla Optimus, what you want to build. Have a real answer. “I want to work on hard robotics problems” is not one; “I’ve done manipulation work and I want to see it run on hardware at scale instead of in sim” is.
The hiring-manager call gets technical fast. This is where they decide whether the rest of the day is worth booking. Expect a walk through your resume where they stop on one project and dig. For a controls candidate that might be “talk me through how you tuned that MPC controller”; for embedded, “why did you pick that RTOS and what did you give up.” They’re checking that the work on your resume is yours and that you can reason about it out loud.
The technical presentation
The distinctive round is a technical presentation to an audience of three or four engineers. You pick a project from your career and present it, then defend it. Candidates report a roughly hour-long slot, and the presentation itself is the short part: plan for maybe 20 to 30 minutes of material and expect the defense and Q&A to eat the rest. It’s your own deck, prepared in advance, not a live coding exercise. This is the single highest-signal part of the loop and the one candidates most often underprepare. It rewards depth: pick something you owned end to end, be honest about what went wrong, and come ready for the room to interrupt. The failure mode is a polished slide deck with no scars on it. Bring the bug that took you three weeks, the design you’d redo, the metric that didn’t move. Engineers who’ve shipped hardware can smell a sanitized story.
Practical prep: rehearse the version where you get four minutes in before the first hard question and never make it back to your planned narrative. If your understanding only survives the linear walkthrough, it isn’t understanding.
Role-specific technical rounds
Apptronik’s open roles skew toward four buckets, and the deep-dive questions track the bucket. These are live sessions, whiteboard or shared editor, not take-homes.
Controls and dynamics. Expect whiteboard work on control loops, state estimation, and rigid-body dynamics. Realistic prompts: derive or sketch a controller for a joint with a flexible transmission; explain how you’d fuse IMU and joint-encoder data for balance; what a Kalman filter assumes and where those assumptions break on a real robot; how you keep a walking controller stable when one foot’s contact estimate is wrong. They care whether you know why the math matters on hardware, not just that you can recite it.
Embedded and firmware. C and C++ in a real-time context, interrupt handling, memory constraints, timing, and communication buses like CAN or EtherCAT. Questions get concrete: what happens on the bus when a node drops, how you debug a missed deadline, why you’d use a lock-free queue between an ISR and a task, what a watchdog buys you and what it doesn’t. Undefined behavior and priority inversion come up because they bite.
Robotics ML and perception. This is the Gemini Robotics work: imitation learning, vision-language-action models, sim-to-real, and data pipelines. Expect a live discussion, not a take-home, of how you’d collect and curate demonstrations, how you evaluate a policy that only fails 2% of the time but fails dangerously, and where sim-to-real gaps come from. If you’ve touched modern ML interviewing, the framing is similar but the reward function is physical safety, not benchmark accuracy.
Software and systems. Middleware, ROS or a custom equivalent, latency budgets, and the plumbing between perception, planning, and control. Design prompts sound like “how would you structure the message flow so a perception hiccup can’t stall the control loop,” or “you have a 1 kHz control loop and a 30 Hz vision pipeline on the same machine, how do you keep them from starving each other.” That’s a real-time systems question wearing a distributed-systems costume.
Across all four, there’s usually a coding component, but it’s applied and live. Think “parse this sensor log and flag dropped frames” or “implement a ring buffer,” not “invert a binary tree under time pressure.” Correctness, edge cases, and clean handling of the messy real-world input matter more than the slickest one-liner.
Round-by-round summary
| Stage | Format | What they screen for |
|---|---|---|
| Recruiter screen | ~30 min remote call | Motivation, role fit, why humanoid robotics and why Apptronik |
| Hiring-manager screen | Remote technical call | Resume depth, ownership, ability to reason about your own work out loud |
| Technical presentation | In-person, ~1 hr: pre-built deck to 3-4 engineers, defense/Q&A is the bulk | Real depth, honesty about failures, holding up under interruption |
| Role-specific deep dives | Live sessions (whiteboard/shared editor): controls / embedded / ML / systems | Applied systems judgment on hardware, edge-case reasoning, correct fundamentals |
| Applied coding | Live practical problem, often within a deep dive | Correctness, edge cases, clean handling of messy sensor input |
| Behavioral / values | Woven through the onsite | Collaboration across mechanical/electrical/software, comfort with hardware failure |
What owning the ML actually means here
The Gemini Robotics partnership is the headline, so get specific about the division of labor before you accept a robotics-ML role. DeepMind supplies the foundation model; its on-device variant is reported to adapt to a new task from as few as 50 to 100 demonstrations. What that leaves for an Apptronik engineer is the hard, unglamorous part: the teleoperation and data-collection rig that produces those demonstrations, the curation and labeling pipeline, the on-robot integration and latency budget, the evaluation harness that decides whether a policy is safe to run, and the fallback behavior when the model is uncertain. How much of the model training and architecture happens inside Apptronik versus at DeepMind is exactly the question to ask your interviewers, because the answer tells you whether you’ll be doing research or productionizing someone else’s. Neither is wrong. Not knowing which one you signed up for is.
What they’re really screening for
Two things separate offers from rejections here. First, systems thinking across disciplines. Apollo is mechanical, electrical, and software fused together, and the engineers who thrive can hold the whole stack in their head enough to know when a “software bug” is actually a saturated actuator or a noisy encoder. Show that you think about the physical thing your code drives.
Second, comfort with failure on hardware. Robots break. Deadlines get missed. A candidate who talks only about clean successes reads as someone who’s never watched their controller send a robot into the safety cage. The behavioral thread of the loop is checking whether you can debug calmly, collaborate with mechanical and electrical engineers, and own a mistake. If you’ve prepped behavioral answers with the STAR method, aim your stories at cross-team debugging and hard tradeoffs, not leadership platitudes.
Compensation, location, and how to check it
Apptronik doesn’t publish bands, and I won’t invent them. It’s a well-funded Austin startup, so cash comp for senior engineers is generally competitive with major-metro tech but often below top-of-market Bay Area FAANG cash, with the upside carried by equity in a company that just repriced to roughly $5B. That equity is the number to interrogate: ask for your grant’s share count, the current strike or preferred price, the total shares outstanding, and the vesting schedule, so you can reason about it rather than trust a headline valuation. Cross-check role and level against levels.fyi and comparable robotics startups, and model the whole package with a total comp calculator before you negotiate. For a private company, the equity assumptions matter more than the base.
On location and visas: these are hardware roles built around a physical robot, so plan on Austin, on-site or hybrid rather than fully remote, and budget for relocation if you’re not local. Apptronik hasn’t published a public visa-sponsorship policy that I can point to, so if you need H-1B, TN, or transfer support, ask the recruiter directly on the first call rather than assuming either way. It’s a fair, normal question, and getting a straight answer early saves everyone a wasted loop.
How to prepare without wasting your time
Skip the grind-500-LeetCode plan. It’s the wrong prep for this loop. Instead, pick the one project you’ll present and rehearse defending it until the hard questions stop surprising you. Refresh the fundamentals of your discipline to the point where you can derive, not just recall: for controls, state estimation and stability; for embedded, real-time scheduling and concurrency; for ML, imitation learning and sim-to-real. Read up on Apollo and the Gemini Robotics partnership so your “why here” answer is specific. And have honest failure stories ready, because someone will ask what broke and how you found it.
The rest of the physical-AI field interviews on the same wavelength, so if you’re running a search across it, the AI-native company interview guides and the interview-difficulty index are worth a pass. But the thing that gets you an Apptronik offer isn’t a broad checklist. It’s being the engineer in the room who clearly knows what happens when the sensor lies.
Practice the behavioral round:
