Why pre-screen self-driving car engineers before the on-site system design panel
Pre-screening self-driving car engineers protects the most expensive hour on your calendar: a panel of principal engineers running a system design and coding loop. Applicants arrive from robotics labs, ADAS suppliers, drone and warehouse autonomy, and university competition teams, and every resume lists perception, sensor fusion, and ROS. A resume cannot tell you whether their code ever ran on a vehicle with a safety driver in the seat. Ten minutes surfaces the layer they truly owned, the platform it ran on, and how they handled a disengagement.
What actually matters when screening Self-driving Car Engineer candidates
- 01
Technical depth
Probe the stack layer they own: perception, prediction, planning, or control, and the theory and sensor physics under it.
- 02
Work that shipped
Look for miles driven with their code in the loop, on public roads or a real test programme, not only in simulation.
- 03
Diagnosis under uncertainty
Test how they investigate a disengagement when logs, sensors, and the planner all offer a plausible story.
- 04
Working across the org
Check how they work with safety drivers, validation, and regulators when a fix has road-safety consequences.
Pre-screening questions to ask Self-driving Car Engineer candidates
12 questions grouped by what they test. Ask the same set in every screen and score answers on a consistent scale, or send them as an async video screen and compare answers side by side.
Stack depth
Which sensor technologies have you worked with directly on a vehicle: lidar, radar, cameras, IMU, wheel odometry? Tell me about one of their failure modes you had to design around.
Specific parts and physics: spinning versus solid state lidar, radar Doppler ambiguity, rolling shutter artefacts, calibration drift, and how weather or occlusion changed their design.
They list sensor names from a spec sheet but cannot describe a single failure mode they personally observed in data.
How have you dealt with the challenges of sensor fusion in your past projects, especially when two sensors disagreed?
A concrete fusion architecture (early, late, or track-level), timestamp synchronisation and extrinsic calibration detail, and a rule they used when lidar and radar tracks conflicted.
They describe fusion only as feeding everything into a neural network, with no view on synchronisation or calibration.
What role does SLAM or localisation play in your work, and how accurate did your pose estimate need to be?
Numbers and constraints: centimetre-level lateral accuracy, GNSS/RTK plus IMU fusion, map matching against HD maps, and behaviour in tunnels or urban canyons.
They recite the SLAM acronym and textbook algorithms without ever stating an accuracy requirement or a failure case.
Walk me through your approach to path planning and trajectory generation on a system you actually worked on.
A named approach (lattice, sampling, optimisation-based, MPC) with cost terms, comfort and kinematic constraints, and the tradeoff they tuned between progress and caution.
They describe planning generically as A star or RRT with no cost function, no vehicle model, and no comfort constraints.
What do you keep in mind for the computational efficiency of your algorithms, given the compute budget on the vehicle?
Awareness of the target hardware (Orin, Xavier, custom ASIC), per-cycle latency budgets, quantisation or pruning, and what they cut to hit a deadline.
They treat compute as unlimited and have never profiled a pipeline against a hard cycle time.
Shipped work
Pick one autonomous driving feature you developed or tested and walk me through it: your part of the code, the platform it ran on, and the miles it drove.
Their specific contribution on a named platform, mileage or hours with their code in the loop, and a metric they moved such as disengagements per thousand miles.
The project stops at simulation or a demo video, and they cannot separate their own work from the team's shared stack.
Tell me about your experience with real-time systems and where timing actually bit you in a self-driving stack.
Concrete timing detail: sensor to actuation latency, jitter, watchdogs, deterministic scheduling, and a bug caused by a missed deadline or clock skew.
They equate real-time with fast and have never measured end-to-end latency or handled a dropped cycle.
Have you built or extended simulation environments for testing self-driving algorithms, and how did you know the simulator matched the road?
Named tooling (CARLA, LGSVL, in-house resimulation from logs), scenario generation from real disengagements, and honest limits on sim-to-real gaps in sensor models.
They treat passing in simulation as proof of correctness and cannot name a case where the road contradicted the sim.
Diagnosis under uncertainty
Take me through how you debug an autonomous driving system after a disengagement, when perception, prediction, and the planner each offer a plausible explanation.
A log-first method: pull the rosbag, replay the frame, check timestamps and perception output against ground truth, then bisect layer by layer before assigning blame.
They guess at the cause or default to blaming another team's layer without pulling logs or reproducing the frame.
How do you handle edge cases and unexpected scenarios, like an occluded jaywalker or an unprotected left across traffic?
A named scenario they handled, how it entered the regression suite, and a fallback behaviour such as a minimal risk manoeuvre or conservative occlusion reasoning.
They promise more training data as the answer to every edge case, with no fallback behaviour or regression test.
Safety and collaboration
How do you ensure the safety and reliability of the software you develop, and who else has to sign off before it reaches a vehicle on public roads?
Named process: ISO 26262 or SOTIF work, hazard analysis, code review and simulation gates, shadow mode, safety driver briefings, and validation sign-off before road release.
Safety is described as another team's job, with no release gate, no shadow mode, and no interaction with safety drivers.
What do you see as the biggest unsolved challenges in self-driving today, and which one has cost you the most time?
A specific, first-hand answer such as long-tail behaviour prediction, validating rare events, or regulatory evidence, tied to work they personally did.
Generic commentary on public trust or industry hype with no connection to a problem they have worked on.
How to score responses
Score every candidate on the same four criteria immediately after the screen. At this stage you are shortlisting for panel interviews, not making the final call.
| Criterion | What a 5 looks like | Scale |
|---|---|---|
| Technical depth | Deep command of their stack layer and the sensor physics feeding it, including where the models break. | 1 · 2 · 3 · 4 · 5 |
| Work that shipped | Names real driving programmes their code ran in, with intervention or safety metrics they owned. | 1 · 2 · 3 · 4 · 5 |
| Diagnosis under uncertainty | Investigates disengagements from logs methodically, separating perception, prediction, and planning causes. | 1 · 2 · 3 · 4 · 5 |
| Working across the org | Works closely with safety and validation, and documents changes to a standard a regulator could audit. | 1 · 2 · 3 · 4 · 5 |
Autonomy work is explained on a whiteboard, not in bullet points. Async video lets you hear an engineer reason aloud through a disengagement, share their screen over a trajectory plot or rosbag, and show whether they can make a safety driver understand the fix.
Try it on HirevireScreening FAQ
Process basics
What should a pre-screen for a self-driving car engineer cover before the technical loop?
Cover four areas in ten to fifteen minutes: which stack layer they owned (perception, prediction, planning, or control), the vehicle platform and mileage their code ran on, one disengagement or incident they investigated end to end, and how they coordinated a fix with validation and safety drivers. Leave algorithm implementation and live coding for the panel.
Do candidates need public road experience, or is simulation work enough?
Simulation-only experience is enough for some roles, but you should know which you are buying. Engineers from CARLA, cases in a closed course, or a university competition can be strong on theory and tooling. Engineers with public road miles have felt calibration drift, sensor occlusion, weather, and a safety driver taking over. Match that to whether your programme is pre-road or already driving.
Evaluating answers
How do you tell real autonomy depth from buzzword fluency?
Ask for the physics and failure modes, not the library names. A strong candidate explains why lidar returns drop on wet asphalt, why radar Doppler helps at range, what an extended Kalman filter assumes and when those assumptions break, or the latency budget between sensor timestamp and actuation. Naming TensorFlow, PyTorch, and OpenCV without a concrete debugging story is fluency, not depth.
What are the biggest red flags in a self-driving car engineer screen?
Three patterns should stop you: blaming perception for every planner failure without evidence from logs, describing safety as someone else's team, and being unable to name a single metric they moved (disengagements per thousand miles, false positive rate per hour, planner cycle time). Also watch for candidates who cannot say which lines of code were theirs on a shared open-source stack.
Go deeper on this role
Sanat has personally screened 300+ candidates across 18+ years of building and hiring teams, and turned that screening process into Hirevire's video screening platform. LinkedIn
