Applied Intuition builds the software that other companies use to develop and validate autonomy: high-fidelity simulation, scenario libraries, sensor models, and the data tooling to run it at scale. The pitch is that you do not validate a self-driving stack on a million real road miles, you run billions of miles in simulation against edge cases you author on purpose. On the commercial side that ships as products like SDS for Automotive, an end-to-end ADAS and autonomy stack, plus Vehicle OS and Cabin Intelligence. The company says it serves 18 of the top 20 global automakers. More recently it has moved into defense with its Acuity ground, air, and maritime autonomy line and the Axion tooling, mission-control, and simulation suite, and it now runs programs across the Department of Defense.
Why prepare for this loop now: the hiring is heavy and it spans two very different engineering profiles. Applied Intuition closed a $600 million Series F and tender offer in June 2025 co-led by BlackRock-managed funds and Kleiner Perkins, at a $15 billion valuation, up from a roughly $6 billion Series E the year before. Automotive and a growing defense business are pulling in engineers on a systems track and a full-stack track at once. If you are comparing several private-company bets, our library of company interview guides helps calibrate what to expect, but keep Applied Intuition in its own bucket: it sells simulation tooling for autonomy, not the hardware the defense startups it gets grouped with build.
Why the questions look the way they do
The product explains the interview. Simulation and tooling is a systems-software problem: you push large volumes of sensor and scenario data through performance-sensitive C++, and you ship developer-facing tools other engineers have to trust. So the coding bar rewards correct, well-structured code over clever use of an exotic algorithm, and at least one interviewer asked outright how a working solution would be cleaned up for production. They hire people who write code others will build on, not people who only clear a timed puzzle.
What the on-site actually contains
The stages below are reconstructed from candidate reports on Glassdoor, Taro, and InterviewQuery; the company does not publish its process, so read this as a well-informed approximation rather than a fixed itinerary. Budget about a month start to finish, with the on-site as the day that decides it.
| Applied Intuition interview stage | Format and length | What it screens for |
|---|---|---|
| Recruiter screen | ~30 min phone | Background, track fit (systems vs. full-stack), motivation, work-authorization and location fit for the specific req |
| Online assessment (new-grad / early-career) | ~45 min automated, ~4 questions | Straightforward-to-hard coding, done before a human screen for junior applicants |
| Technical phone screen | 45-60 min live on CoderPad | One medium/hard coding problem in the role’s main language (C++ for systems roles), correctness and edge cases |
| On-site coding rounds | 2 rounds in the super day | More timed coding, plus an open-ended problem-solving round; production-quality code and how you would refactor it |
| System design | ~45-60 min | Autonomy-flavored design, e.g. “design an off-road autonomous vehicle” or a sim/data pipeline; scoping and tradeoffs |
| Behavioral + hiring manager | ~45 min each | Collaboration, ownership, how you handle ambiguity, why autonomy and why this company |
Read the sentiment plainly. Glassdoor’s sample is small: the general software-engineer pool reports difficulty around 3.2 out of 5 and only about 45 percent positive, meaning most candidates left neutral-to-negative, while the new-grad pool skews friendlier near 72 percent. The open-ended “situational” round on the on-site is not a clean algorithm question; it hands you an underspecified problem and watches how you scope it, worth rehearsing separately from LeetCode drills.
The system-design round, concretely
If you draw the reported “design an off-road autonomous vehicle” prompt, the interviewer wants you to decompose the autonomy stack and reason about validating it, not produce a finished architecture. Lay out the pipeline first: perception (lidar, camera, radar, and fusing them), localization and mapping (harder off-road, where lane markings are gone and GPS can drop), planning split into route and local motion planning, and control down to actuation. Then reach the part that lands at this company specifically, how you know it works: scenario generation, sim-in-the-loop validation, edge-case coverage, and the data throughput to log and replay sensor streams. Structure the answer around three things a design round like this weighs: can you scope (ask what is in and out before designing), can you model the domain (name the subsystems and their interfaces), and can you reason about scale (data volumes, compute, validation coverage). A generic web-service answer that ignores perception, sim, and data volume is what falls flat.
If you are on the C++ / simulation / robotics track
This is the systems-engineering path, and the coding screen is where most of the filtering happens. Be genuinely fluent in modern C++: object lifetime and ownership, references versus pointers, the standard containers and what each one costs, and enough about memory layout to explain why one approach beats another. Practice writing clean, compiling code in a shared editor while you talk, because a CoderPad session rewards clarity over cleverness. The underlying data structures are standard, so a pass through the common coding patterns and a refresher on time and space complexity covers the algorithmic slice; what sets candidates apart is writing it as production C++ and having a real answer to “now how would you clean this up.” Expect framing pulled from robotics and systems work: coordinate transforms, sensor data, scenario state, and the like.
If you are on the full-stack / data track
This is a real half of the org, not a footnote. Applied Intuition’s full-stack postings ask for React, TypeScript, and CSS on the front end plus one of Python, C++, or Go on the back end; the UK full-stack roles list TypeScript, Go, and Python specifically. These engineers build the web tooling on top of the products named above: the dashboards that front Vehicle OS and Cabin Intelligence, the scenario-authoring and log-review interfaces, and the pipelines that move sim results and sensor data into something inspectable. The interview matches that. One reported round started from an API response with nested JSON and layered on constraints as it went. A second common shape is a data-modeling and API task: design the endpoint and schema that serve scenario or log data with filtering and pagination, then handle the payload getting large. Full-stack system design here tends toward exactly that, an ingest-to-dashboard service (schema, API, caching, rendering large datasets) rather than distributed-systems trivia, and the general muscles from a set of system-design interview guides transfer, especially stating tradeoffs out loud.
How the loop changes by level
New grads and early-career applicants pick up an extra gate: an automated online assessment (about 45 minutes, roughly four questions from easy to hard) before the live phone screen, and the process tends to move fast, often two to four weeks. Candidate reports do not cleanly separate the senior loop (treat this as unconfirmed), but expect the same skeleton with more weight on system design as the level rises. Ask the recruiter which loop your req runs.
Work authorization and location
Applied Intuition now spans two regulatory worlds, and the answer differs by side. The commercial automotive business is an ordinary software job; the defense business touches U.S. government autonomy programs, and roles on that side can carry U.S.-person or ITAR-style eligibility requirements the way any defense-facing engineering job does. On visas, the careers page does not publish a sponsorship policy, so international candidates should ask the recruiter whether a given commercial req is open to sponsorship; the defense-facing roles are the ones most likely to be closed to non-U.S.-persons outright. On location, the company lists offices in the Bay Area (Sunnyvale) plus Ann Arbor, San Diego, and Washington, D.C., several international sites, and at least one remote listing. It does not publish a blanket on-site, hybrid, or remote policy, so confirm the arrangement for your specific req instead of assuming. Settling all of this on the first call spares you a loop you were never eligible to finish.
How to read the comp
The real question at a $15 billion private company is how to value the equity, and the starting point is that nobody outside can value it precisely. Offers come as base plus equity in options and/or restricted stock units, so pin down which one you are getting, at what strike or grant price, on what vesting schedule (four years with a one-year cliff is the common shape; ask about refreshers), and at what level, since leveling drives the number more than negotiation does. The one useful liquidity signal is that the June 2025 Series F included a tender offer, meaning existing shareholders had a window to sell some shares for cash. That beats most private-company equity, where paper stays paper until an IPO, but a tender is episodic and eligibility-gated, not a standing right to sell, so ask whether the company runs them on a regular cadence. For a base sanity check, one aggregator (Hello World, hw.glich.co) lists a software-engineer and senior band around $150,000 to $200,000; treat that as order-of-magnitude and read the California pay-transparency range on the exact requisition as your real anchor. Then put the offer through a total-comp calculator to value the equity against the current valuation and your vesting, and a good salary-negotiation walkthrough covers the mechanics of pushing it.
How to prepare
Prioritize by track. Systems and simulation candidates should put most of their hours into writing clean, correct C++ quickly, then into the “make it production-quality” follow-up that candidates report. Full-stack candidates should drill practical data-handling, API design, and React/TypeScript ahead of algorithmic esoterica. Every candidate gets a design round and a behavioral round, and the behavioral round is a real filter on collaboration and ownership, so bring two or three tight stories; if yours tend to wander, the STAR-method structure pulls them back to the point. Spread the algorithmic prep over a couple of weeks with a lightweight study plan so it does not crowd out C++ fluency or front-end practice, and pass your resume through a resume checker before you apply, since a systems resume that quantifies what you shipped lands very differently from a generic web-dev one.
Applied Intuition is fundamentally a tooling company. It hires you to build software that other engineers, at automakers and inside defense programs, will stake their own work on, and the interview asks the question that follows: can you write code clean enough that a stranger would trust it in production.
Practice the behavioral round:
