Autonomous Vehicle Waymo, Cruise, Aurora, Motional, and Zoox

Autonomous vehicle companies represent one of the most demanding engineering environments in the industry. The convergence of real-time embedded systems...

·

Autonomous Vehicle Software Engineer Interview Guide: Waymo, Cruise, Aurora, Motional, and Zoox

Autonomous vehicle companies represent one of the most demanding engineering environments in the industry. The convergence of real-time embedded systems, computer vision, machine learning, robotics, and safety-critical software engineering creates a hiring bar unlike anything you will encounter at a typical software company. If you are preparing for a role at Waymo, Cruise, Aurora, Motional, or Zoox, this guide gives you the technical depth and process transparency you need to compete seriously.

The AV Industry Landscape

Understanding where each company sits strategically shapes how they hire and what they value in engineers.

Waymo (Alphabet subsidiary) is the most mature commercial robotaxi operation in the world, with paid rides operating in San Francisco, Phoenix, and Los Angeles without safety drivers. Their engineering culture is deeply research-oriented, with significant investment in formal methods, simulation fidelity, and perception quality. Waymo hires more PhD-level engineers than any peer in the space.

Cruise (GM subsidiary) has had a turbulent regulatory period but continues to employ world-class engineers working on full autonomy for urban environments. Their stack is heavily Python and C++, and they have invested significantly in simulation infrastructure and fleet data pipelines.

Aurora focuses on the autonomous trucking market and has a reputation for rigorous safety engineering practices. Co-founded by former leads from Google, Tesla, and Uber ATG, Aurora's culture prizes systems thinking and formal safety cases. They use the Aurora Driver, a hardware-software platform designed to be licensed to vehicle OEMs.

Motional (Hyundai-Aptiv joint venture) has a significant software engineering presence in Pittsburgh and Boston, with robotaxi deployments in Las Vegas. They emphasize production reliability and have a mature DevOps and simulation culture.

Zoox (Amazon subsidiary) is building a purpose-built bidirectional robotaxi with no steering wheel. Their engineering problems are unique because the vehicle itself is novel — they cannot leverage production vehicle platforms. This means their software engineers work closer to the hardware layer than at most other companies.

Interview Process Structure

Despite surface differences, AV companies share a common interview structure shaped by the complexity of their technical domains.

Phone screen: A 45-60 minute technical screen with a domain-specific engineer. Unlike a typical FAANG screen, this will often include a problem directly relevant to AV — a simple geometric computation, a sensor processing question, or a systems design warm-up. Expect C++ or Python code.

Technical assessment or take-home: Many AV companies use an asynchronous take-home that involves implementing a component — a basic Kalman filter, a point cloud clustering algorithm, or a path planning function. These are evaluated on correctness, code quality, and understanding of numerical stability.

On-site (virtual or in-person): Typically 4-6 rounds.

Hiring committee review: AV companies, especially Waymo and Aurora, have strong hiring committee processes where multiple interviewers must align. A strong signal in one round rarely overrides a weak signal in another.

Technical Domains in Depth

Perception and Computer Vision

Perception is the first step in the autonomy stack: the system must understand what is in the world around the vehicle. Interviewers in perception roles will probe your understanding of deep learning architectures for object detection and segmentation, the tradeoffs between accuracy and inference latency, and how to handle distribution shift between training data and production environments.

Key topics:

Sensor Fusion and State Estimation

Sensor fusion is the discipline of combining noisy measurements from multiple sensors into a consistent, accurate estimate of the world state. This is the heart of the AV problem, and every mid-to-senior engineer in the space is expected to understand it deeply.

The workhorse of sensor fusion is the Kalman Filter and its nonlinear variants: the Extended Kalman Filter (EKF) and the Unscented Kalman Filter (UKF). For multi-object tracking, you combine these with data association algorithms like the Hungarian algorithm or the Joint Probabilistic Data Association (JPDA) filter.

Here is a practical C++ implementation of a constant-velocity Kalman filter for tracking a single object in 2D:

#include <Eigen/Dense>
#include <cstdint>

class KalmanFilter2D {
public:
    // State: [x, y, vx, vy]
    Eigen::VectorXd x_;   // state mean
    Eigen::MatrixXd P_;   // state covariance
    Eigen::MatrixXd F_;   // state transition matrix
    Eigen::MatrixXd H_;   // measurement matrix
    Eigen::MatrixXd R_;   // measurement noise covariance
    Eigen::MatrixXd Q_;   // process noise covariance

    KalmanFilter2D(double process_noise_std, double measurement_noise_std) {
        x_ = Eigen::VectorXd::Zero(4);
        P_ = Eigen::MatrixXd::Identity(4, 4) * 500.0;

        // Constant velocity transition
        F_ = Eigen::MatrixXd::Identity(4, 4);
        // dt will be set per-prediction step

        // Observe only position
        H_ = Eigen::MatrixXd::Zero(2, 4);
        H_(0, 0) = 1.0;
        H_(1, 1) = 1.0;

        R_ = Eigen::MatrixXd::Identity(2, 2)
             * measurement_noise_std * measurement_noise_std;

        // Q initialized here; overridden per step with actual dt
        Q_ = Eigen::MatrixXd::Zero(4, 4);
        double q = process_noise_std * process_noise_std;
        Q_(2, 2) = q;
        Q_(3, 3) = q;
    }

    void Predict(double dt) {
        F_(0, 2) = dt;
        F_(1, 3) = dt;

        // Update Q for this dt (discrete white noise acceleration model)
        double dt2 = dt * dt;
        double dt3 = dt2 * dt;
        double dt4 = dt3 * dt;
        double q = Q_(2, 2);  // base process noise variance
        Q_(0, 0) = dt4 / 4.0 * q;
        Q_(1, 1) = dt4 / 4.0 * q;
        Q_(0, 2) = Q_(2, 0) = dt3 / 2.0 * q;
        Q_(1, 3) = Q_(3, 1) = dt3 / 2.0 * q;
        Q_(2, 2) = dt2 * q;
        Q_(3, 3) = dt2 * q;

        x_ = F_ * x_;
        P_ = F_ * P_ * F_.transpose() + Q_;
    }

    void Update(const Eigen::Vector2d& z) {
        Eigen::VectorXd y = z - H_ * x_;             // innovation
        Eigen::MatrixXd S = H_ * P_ * H_.transpose() + R_; // innovation covariance
        Eigen::MatrixXd K = P_ * H_.transpose() * S.inverse(); // Kalman gain

        x_ = x_ + K * y;
        Eigen::MatrixXd I = Eigen::MatrixXd::Identity(4, 4);
        P_ = (I - K * H_) * P_;
    }

    Eigen::Vector2d GetPosition() const {
        return x_.head<2>();
    }
};

In an interview, be prepared to explain why we use (I - KH)P rather than the numerically stabler Joseph form, and when you would prefer a UKF over an EKF. The answer involves the degree of nonlinearity in your motion or measurement models.

For multi-sensor fusion, understand that different sensors operate at different frequencies: a typical automotive LiDAR runs at 10 Hz, cameras at 30 Hz, and radar at 20 Hz. A well-designed fusion architecture handles asynchronous updates cleanly — each new measurement triggers an update step, while predictions run at a fixed control loop frequency.

Localization and Mapping

AV localization goes far beyond GPS. Production systems use HD maps — centimeter-accurate semantic maps that encode lane geometry, speed limits, traffic signal positions, and driveable surface boundaries. Localization is the problem of precisely estimating the vehicle's 6-DOF pose within that map.

The dominant approach is LiDAR-based point cloud registration against a pre-built map, typically using Iterative Closest Point (ICP) or Normal Distributions Transform (NDT). GPS provides a coarse prior, IMU provides high-frequency pose integration between LiDAR scans, and wheel odometry provides additional redundancy.

Interview topics in this domain:

Motion Planning

The planning stack converts a localization estimate and perception output into a trajectory the vehicle should follow. This involves multiple layers: route planning at the road network level, behavioral planning at the scene level (when to yield, when to change lanes), and trajectory optimization at the continuous motion level.

Key algorithms:

Be ready to derive the bicycle model vehicle kinematics from first principles. Interviewers at Aurora and Waymo commonly use this as a warm-up for planning discussions.

Simulation

Every AV company operates a massive simulation infrastructure. Testing in the real world is expensive, slow, and dangerous for corner cases. Simulation allows engineers to replay real-world scenarios, inject adversarial conditions, and test software changes across millions of scenarios before deploying to vehicles.

Interview discussions about simulation will probe:

System Design: Sensor Fusion Pipeline for Autonomous Vehicles

The most common system design question in AV interviews is: Design a sensor fusion pipeline for an autonomous vehicle.

Here is a production-caliber answer.

Sensors and their characteristics: A typical Waymo-class sensor suite includes five LiDAR units (one long-range spinning unit plus four short-range solid-state units), eight cameras (360-degree coverage), and four radar units (front and rear with side coverage). Each sensor has distinct latency, range, resolution, and weather resilience characteristics.

Pipeline architecture:

The pipeline is organized in three layers: raw data ingestion, per-sensor processing, and cross-sensor fusion.

In the raw ingestion layer, each sensor has a dedicated driver process running on dedicated hardware. LiDAR and camera data are high-bandwidth — a spinning LiDAR at 128 lines generates roughly 1.3 million points per second, each with XYZ coordinates and intensity. Camera data at 8 cameras x 1080p x 30 Hz is approximately 1.5 GB/s uncompressed. These data streams are timestamped with hardware-synchronized clocks (PPS signal from GPS) to microsecond precision. Time synchronization is not optional — a 10 ms timestamp error at 30 m/s produces a 30 cm position error.

In the per-sensor processing layer, each sensor stream is processed independently. LiDAR processing includes ground plane segmentation (RANSAC or neural network-based), point cloud clustering, and 3D bounding box estimation. Camera processing includes 2D object detection, depth estimation (either from stereo or monocular depth networks), and semantic segmentation. Radar processing includes Doppler velocity extraction and clutter filtering.

In the fusion layer, detections from each sensor are associated using a multi-hypothesis tracker. The key design decisions are:

  1. Coordinate frame: All detections are transformed to a single ego-vehicle frame before association. Calibration between sensor frames must be continuously monitored for drift.
  2. Association metric: Mahalanobis distance in the state space accounts for uncertainty. IoU-based association is fast but ignores prediction uncertainty.
  3. Track management: New tracks are initialized with high uncertainty. Tracks require N consecutive associations before being promoted to a confirmed state that feeds downstream planners. Tracks that miss M updates are pruned.
  4. Output interface: The fusion layer outputs a list of tracked objects with state estimates (position, velocity, acceleration, orientation, dimensions) and associated uncertainty. This interface is the contract between the perception stack and the prediction/planning stack.

Failure handling and redundancy: Every fusion system must have explicit handling for sensor degradation. Implement health monitoring that tracks per-sensor detection rate, point cloud density, and image exposure quality. When a sensor health check fails, the system switches to a degraded mode with reduced operational design domain — for example, restricting speed or disabling lane change in the absence of a functional side-facing camera.

Real-time constraints: The entire perception-to-planning loop must complete within 100 ms for a safe 10 Hz control cycle. Latency budgets are typically: LiDAR processing 30 ms, camera processing 40 ms, fusion 20 ms, leaving 10 ms margin. These budgets require careful profiling and often custom CUDA kernels for the compute-intensive steps.

C++ and Python Requirements

C++ is the production language for latency-sensitive components: sensor drivers, the fusion pipeline, the tracker, and the trajectory optimizer. Python is used for data pipelines, training infrastructure, simulation tooling, and increasingly for higher-level planning components.

For C++, AV companies expect proficiency with modern C++ (17 or 20), Eigen for linear algebra, ROS 2 or a proprietary equivalent for inter-process communication, and strong understanding of memory management, threading with std::mutex and std::atomic, and RAII patterns. Real-time systems often impose restrictions on dynamic memory allocation in the hot path — know why and how to use memory pools.

For Python, expect strong NumPy and PyTorch proficiency, experience with protobuf or similar serialization for data pipelines, and familiarity with distributed data processing (Ray, Apache Beam, or internal equivalents).

Safety-Critical Engineering Mindset

This is where AV interviews diverge most sharply from standard software engineering interviews. Safety is not a feature — it is the organizing principle of the entire engineering effort.

Interviewers will assess whether you instinctively apply safety reasoning. Be ready to discuss:

The behavioral interview round will probe your safety culture directly. Prepare stories about times you raised a safety concern, pushed back on schedule pressure for quality reasons, or caught a failure mode others missed. AV companies are deeply aware of the public and regulatory scrutiny they operate under. They hire engineers who internalize safety, not engineers who comply with safety checklists.

Compensation and Career Paths

AV companies compete with FAANG for top engineering talent and pay accordingly. At Waymo and Cruise, total compensation for senior software engineers (L5/L6 equivalent) ranges from $350,000 to $550,000 in strong markets, with a meaningful equity component. Staff and principal engineers can reach $600,000-$800,000+ TC. Domain expertise in perception, planning, or simulation commands a premium because the candidate pool is genuinely small.

For new graduates with strong robotics or computer vision backgrounds, L3/L4 offers at Waymo typically start at $220,000-$280,000 TC, substantially above equivalent FAANG new-grad offers due to the specialized skills premium.

Career paths diverge along two axes: technical depth versus engineering leadership.

On the technical track, the progression from Senior to Staff to Principal involves expanding scope from component ownership to subsystem ownership to cross-stack architectural influence. At the Principal level, you are expected to drive multi-year technical strategy — for example, the transition from a modular perception stack to an end-to-end neural network approach, or the design of the next-generation simulation platform.

On the engineering management track, AV companies value managers who can credibly engage with deep technical debates. A manager who cannot distinguish a good sensor fusion design from a poor one will struggle to prioritize the right work. Most successful engineering managers in AV come from an IC background in the domain.

Preparing for Your Interview

Start with the fundamentals: make sure your Kalman filter implementation is clean and you can derive it from first principles. Implement a basic 2D particle filter. Implement ICP from scratch. Work through the motion planning chapters of Principles of Robot Motion by Choset et al., and the perception sections of the Autonomous Mobile Robots textbook by Siegwart, Nourbakhsh, and Scaramuzza.

For coding practice, focus on graph algorithms (Dijkstra, A*), geometric algorithms (convex hull, point-in-polygon, polygon intersection), and spatial data structures (kd-tree, R-tree). These appear far more often in AV interviews than dynamic programming problems.

Read the published papers from your target company. Waymo, Aurora, and Motional all publish technical research. Reading their papers tells you what problems they consider hard and what approaches they have found promising — and it makes for excellent interview conversation.

Finally, prepare to articulate why you want to work in autonomy specifically. The mission-driven culture at AV companies is genuine. Engineers work long hours on hard problems in part because they believe they are building technology that will meaningfully reduce the 40,000 annual traffic fatalities in the United States. Interviewers can tell the difference between a candidate who is chasing compensation and one who is drawn to the problem. Be the latter — or be honest about what draws you and find genuine alignment with the mission.

The autonomous vehicle industry is technically demanding, safety-critical, and deeply consequential. The engineers who thrive there combine rigorous technical foundations with the judgment and humility that safety-critical work demands. Prepare thoroughly, reason carefully, and engage with the mission authentically.

Ready to practice for your next interview? Interview Simulator gives you AI-powered feedback on your responses — behavioral, technical, and system design. Start with 3 free practice interviews today.

Try Interview Simulator free →

Don't neglect behavioral preparation — see our behavioral interview guide.

For technical interview preparation, our system design guide is essential reading.

Master the most common coding interview patterns to ace your technical rounds.

Your resume is the first impression — get it right with our resume guide.

Explore Related Topics

Related Reading