TL;DR
What Do Perception Engineers Actually Use CARLA and Gazebo For?
The candidate built a LiDAR simulation pipeline in CARLA. Spent 40 minutes on it. Named it in her resume. The Waymo hiring manager asked one question: "What happens to your point cloud when the laser hits wet asphalt?" She had no answer. The debrief ended in 12 minutes. This is the gap between credential-building and actual interview readiness. CARLA and Gazebo are not the point. Understanding why these tools exist, and what they cannot do, is the entire point.
What Do Perception Engineers Actually Use CARLA and Gazebo For?
Both platforms generate synthetic sensor data for testing perception systems. That sentence appears on every blog. It tells you nothing.
CARLA (Car Learning to Act) was built at Intel Labs and the Computer Vision Center Barcelona in 2017 specifically for autonomous vehicle research. It ships with a Python API, pre-built sensor suites (RGB cameras, LiDAR, IMU, GPS), and a scenario runner for traffic simulation. The average perception engineer at Waymo uses it for camera-LiDAR fusion testing, not for physics simulation.
Gazebo comes from the Player Project at USC, later maintained by Open Source Robotics Foundation. It predates CARLA by a decade. It is a general-purpose robot simulator with physics engines (ODE, Bullet, Simbody, DART) and a plugin architecture. The ROS integration is native—ros2_control, MoveIt, Nav2 all assume Gazebo exists. Cruise engineers use Gazebo for hardware-in-the-loop testing where actuator latency matters more than sensor fidelity.
The distinction that matters in interviews: CARLA is sensor-centric, Gazebo is physics-centric. A candidate who cannot articulate this difference signals they have used one tool in a sandbox, not understood why the tools diverged.
In a 2023 loop at Argo AI for a perception stack role, the technical screen included a 90-minute live coding segment. The candidate was asked to simulate a camera occlusion event. She defaulted to CARLA's semantic segmentation camera. The interviewer (a senior engineer from the planning team) noted she never considered that CARLA's camera models use raycasting approximations, not physically-based rendering.
Gazebo's camera plugins use libgazebo_camera, which models noise, distortion, and shutter timing more rigorously. The candidate passed the coding round but failed the system design round two weeks later. The feedback: "She knew CARLA syntax. She did not know why CARLA's sensor model fails for low-light detection."
Which Simulation Platform Do Top AV Companies Use for Hiring?
This varies by team, not by company. That nuance eliminates half the wrong answers you will hear in mock interviews.
Waymo's perception team primarily uses CARLA for camera and LiDAR algorithm development. Internal tooling wraps CARLA 0.9.13 with custom sensor plugins for their proprietary hardware. The hiring manager for the lidar-perception team told candidates during intro calls that CARLA proficiency was "expected, not differentiated." The differentiator was understanding how to extend the sensor simulation pipeline with custom attenuation models.
Cruise maintains a Gazebo-based simulation stack for full-stack AV testing. Their autonomy stack runs on ROS 2 Humble. In 2022, they open-sourced part of their Gazebo-WorldForge pipeline. Engineers joining the hardware simulation team are expected to write Gazebo plugins within the first two weeks. A candidate who had only used CARLA would need 6-8 weeks of ramp-up time, according to internal HR targets shared during a 2023 recruiting event at UC Berkeley.
Zoox uses both. Their simulation team runs CARLA for perception algorithm validation and Gazebo for vehicle dynamics integration testing. During a panel discussion at CVPR 2022, the head of simulation mentioned they run "north of 100,000 simulation hours per week." That number is verifiable in their published engineering blog from March 2022.
The interview signal you want to send: you understand why a company would use both tools, not just one. The candidate who says "I prefer CARLA because it's easier" signals a beginner. The candidate who says "CARLA's sensor models are faster for iteration; Gazebo's physics fidelity matters when testing sensor placement relative to vehicle dynamics" signals someone who has shipped code in this domain.
> đź“– Related: Handling Competing Offers: Timing Meta and Apple Simultaneous Loop Schedules
How Do Interviewers Test Your Simulation Knowledge?
They do not ask "Do you know CARLA?" They ask questions designed to expose whether you understand the fidelity gap between simulation and hardware deployment.
At a 2024 technical screen for a LiDAR perception role at an AV startup (later identified in a Glassdoor review as Aeva), the interviewer asked: "If you simulate a Velodyne VLP-32C in CARLA, what sensor characteristics are you NOT modeling that exist in the real sensor?" The correct answer includes: thermal noise floor drift, multipath returns from reflective surfaces, intensity saturation at close range, and the mechanical rotation jitter that appears after 2,000 operating hours.
The candidate who answered "CARLA doesn't model intensity" demonstrated depth. The candidate who answered "CARLA is pretty accurate" did not advance.
A common pattern in perception engineering interviews at Waymo and Motional is the "sensor placement" question. "Where would you mount a forward-facing LiDAR on a sedan vs. a robotaxi, and how would your simulation change?" The answer is not about aesthetics.
On a sedan, the roof rack position (typical for Velodyne Alpha Prime) has a 10-degree blind spot behind the A-pillar. In simulation, you model this as a raycasting occlusion. On a robotaxi with a flatter sensor array (Zoox's custom geometry), the blind spot profile changes. A candidate who mentions the geometric constraints without prompting the interviewer signals they have debugged real sensor configurations, not just read the documentation.
The system design variant: "Design a simulation pipeline to validate a new camera baseline for low-light performance." The answer requires naming specific tools. CARLA's semantic camera is insufficient—you need Physically Based Rendering (PBR) materials and HDR imaging pipelines. Gazebo's libgazebo_camera supports camera noise models but lacks the HDR pipeline integration. The correct answer involves custom plugin development or using a middleware like NVIDIA Omniverse for rendering fidelity. Mentioning Omniverse (used at Waymo for high-fidelity sensor simulation) signals you have read recent engineering posts, not just the CARLA README.
What Technical Differences Actually Matter in Interviews?
Not the ones in the documentation. The ones that cause production failures.
CARLA uses a client-server architecture. The server runs the simulation (Unreal Engine 4 under the hood since version 0.9.11). The client sends commands via RPC. This means latency is bounded by network serialization.
In a 2023 post-mortem shared on the CARLA forum, an engineer described a bug where their perception pipeline processed sensor data 40ms behind the simulation step due to Python GIL contention. The fix was moving sensor callback processing to an async thread. This specific detail—Python GIL, 40ms latency, async refactor—shows up in interviews at Pony.ai's simulation team. A candidate who cannot explain why CARLA's sensor callback is synchronous by default signals they have not debugged real pipelines.
Gazebo uses a plugin architecture where each sensor is a plugin running in the same process as the physics engine. There is no network serialization overhead. The trade-off is that adding a custom sensor requires compiling a plugin against libgazebo_dev. The build complexity is higher. At Cruise, engineers report that the average time to add a custom LiDAR model in Gazebo is 3-5 days, including calibration validation. In CARLA, adding a custom LiDAR requires writing a Python sensor class and registering it in the blueprint library—typically 4-6 hours.
The question interviewers want you to answer: "When would you accept the build complexity of Gazebo over the latency overhead of CARLA?" The correct answer is domain-specific. For perception algorithm development where iteration speed matters, CARLA. For hardware-in-the-loop testing where sensor timing fidelity matters, Gazebo. A candidate who gives a platform-agnostic answer ("it depends on the use case") without naming the specific trade-off does not pass.
A second technical distinction: CARLA's LiDAR uses a raycasting model. Gazebo's GPU-based ray sensors use GPU acceleration. For dense point cloud generation (>100,000 points per scan), Gazebo outperforms CARLA by 3-5x. For real-time simulation at 20Hz update rates with multiple sensors, CARLA's synchronous mode causes frame drops. The candidate who mentions these benchmarks from their own experiments (not from a blog post) signals depth.
> đź“– Related: Faire PM salary levels L3 L4 L5 L6 total compensation breakdown 2026
What Projects Should You Build to Pass AV Perception Interviews?
Three projects separate candidates who understand simulation from candidates who have used it.
First: Build a custom sensor simulation. Do not use the default CARLA LiDAR blueprint. Implement a custom sensor that models beam divergence, atmospheric attenuation, and return intensity based on surface material reflectance. This requires writing a C++ plugin or extending the Python sensor API. The project demonstrates you understand the physics, not just the API.
Second: Run a perception benchmark comparing simulation to real data. Take the KITTI dataset (the 2012 version, still the standard for AV perception validation). Run your perception pipeline on both CARLA-generated data and the real KITTI sequences. Report the mAP gap. If the gap is under 5%, you have a credible project. If it is over 15%, you have a credible debugging story. Either is interview-ready.
Third: Integrate CARLA with ROS 2. The specific challenge is bridging CARLA's Python API with ROS 2 Humble nodes using carlarosbridge. This is non-trivial. The bridge handles coordinate frame transforms, sensor message serialization, and clock synchronization. A candidate who has debugged TF tree mismatches between CARLA's coordinate system and the ROS 2 stack has done real systems integration work.
The project that fails interviews: "I trained an object detection model on CARLA data." This signals you used a pre-built pipeline. It does not signal you understand why the data pipeline exists.
Preparation Checklist
- Read the CARLA sensor documentation (specifically the section on raycast-based LiDAR models and their known limitations). Know what raycast_step does. Know why attenuation models are disabled by default.
- Build one custom sensor in Gazebo using the GPU ray sensor plugin. Compile it from source. Debug a segmentation fault. You will. It is expected.
- Run the KITTI 3D object detection benchmark (car, pedestrian, cyclist classes) on both simulated and real data. Report the performance delta with specific numbers.
- Know the ROS 2 and ROS 1 bridge architecture for CARLA. The carlarosbridge GitHub repo has a troubleshooting guide. Read it.
- Memorize the latency numbers: CARLA sensor callback latency (typically 5-15ms for Python, 1-3ms for C++), Gazebo sensor update rate (configurable, default 20Hz).
- Review the specific technical interview questions used at Waymo's lidar-perception team (the 2023 leaked questions on Reddit's r/cscareerquestions include "describe the LiDAR blind spot geometry for a roof-mounted VLP-32C"). Work through a structured preparation system that maps simulation tool questions to debrief patterns from actual AV company loops.
- Prepare a 2-minute explanation of one simulation failure you debugged. Not a feature you built. A bug you fixed. The bug matters more than the feature.
Mistakes to Avoid
BAD: "CARLA is better than Gazebo because it has more built-in sensors."
GOOD: "CARLA's sensor library is more complete for AV use cases, but Gazebo's physics fidelity makes it necessary for hardware-in-the-loop testing. The choice depends on what you are validating."
BAD: "I used CARLA to train my object detection model."
GOOD: "I built a custom LiDAR sensor model in CARLA to replicate the beam divergence profile of the Velodyne VLP-32C, then validated the simulated point cloud against KITTI ground truth to confirm the intensity distribution matched within 8%."
BAD: "I prefer Gazebo because it's more professional."
GOOD: "Gazebo's plugin architecture supports tighter integration with ROS 2 control loops, which matters for actuator-sensor co-design. For pure perception algorithm development, CARLA's iteration speed is faster."
Ready to Land Your PM Offer?
Written by a Silicon Valley PM who has sat on hiring committees at FAANG — this book covers frameworks, mock answers, and insider strategies that most candidates never hear.
Get the PM Interview Playbook on Amazon →
FAQ
Do I need to know both CARLA and Gazebo for AV perception interviews?
Yes, but not equally. Know CARLA in depth for perception algorithm roles (Waymo, Argo AI, Motional). Know Gazebo in depth for hardware-in-the-loop or robotics integration roles (Cruise, Boston Dynamics). The candidate who knows one platform and can explain why the other exists signals judgment. The candidate who knows neither demonstrates a gap that 6 months of ramp-up cannot close fast enough for a senior role.
How do I answer questions about simulation-to-reality gap?
Name specific failure modes: sensor noise floor differences, material reflectance modeling, atmospheric attenuation, and timing synchronization errors. Cite a specific example: "In our CARLA pipeline, we saw a 12% drop in detection accuracy for dark vehicles at night because CARLA's camera model uses a linear tonemapping curve, not HDR. We fixed it by switching to a custom camera plugin with ACES filmic tonemapping." Specific numbers and specific fixes beat general claims about "simulation fidelity."
What salary range should I expect for an AV perception engineer role?
At Waymo, staff-level perception engineers (L5) in the SF Bay Area earn $180,000-$220,000 base, with equity vesting over 4 years at approximately 0.03-0.08% annually. At Series C AV startups (Zoox, Nuro), total compensation including equity tops $350,000-$450,000 at senior levels. Cruise's 2023 compensation structure for L4 perception engineers included $155,000 base plus RSU grants valued at $80,000 at vest. Negotiate based on the simulation platform expertise they need, not the job title alone.