Autonomy Engineer Interview Questions: What to Ask and What to Look For

Q: “You are building a behavior planner for a delivery robot that must navigate sidewalks with pedestrians. How do you model pedestrian intent?”

Strong answer: Discusses prediction models that estimate future pedestrian trajectories based on observed motion, body orientation, and context (e.g., proximity to crosswalks, looking at phone). Mentions social force models for group dynamics. Explains that prediction should output a distribution of possible futures, not a single trajectory, and that the planner must reason over this uncertainty. Describes conservative assumptions: if pedestrian intent is ambiguous, the robot should yield. May reference specific approaches like conditional variational autoencoders or graph neural networks for trajectory prediction.

Red flags: Treats pedestrians as static obstacles with a safety buffer. Does not model intent or future trajectories. Has no concept of uncertainty in prediction. Assumes pedestrians will always behave predictably.

Q: “Compare A* with RRT* for motion planning in a cluttered warehouse. When would you choose each?”

Strong answer: Explains that A* is complete and optimal on a discrete graph, making it fast and predictable for structured environments with a good heuristic, but struggles in high-dimensional configuration spaces. RRT* is a sampling-based planner that handles high-dimensional spaces well and converges to optimal solutions given enough time, but is stochastic and can produce inconsistent paths. For a warehouse with defined aisles and predictable geometry, A* on a precomputed grid is often preferable for its determinism and speed. RRT* becomes more appropriate when the robot has complex dynamics (e.g., a manipulator arm) or the environment is highly unstructured. May also mention hybrid approaches or lattice planners.

Red flags: Can only describe one algorithm. Does not understand the tradeoffs between graph-based and sampling-based planning. Cannot explain when each approach is appropriate. Confuses completeness with optimality.

Q: “How would you design a safety architecture that prevents your autonomous system from causing harm even when the planner makes a mistake?”

Strong answer: Describes a layered safety approach. A runtime safety monitor that checks planner outputs against invariant constraints (minimum distance to humans, maximum speed, stay within operational domain) before execution. Fallback behaviors that activate when the primary planner fails or the safety monitor rejects a plan (e.g., controlled stop, retreat to safe position). Hardware-level interlocks that provide a final safety layer independent of software (e.g., bumper-triggered emergency stop, hardware watchdog timers). Discusses the principle that safety systems should be simpler and more verifiable than the primary planner. May reference formal methods like control barrier functions or reachability analysis.

Red flags: Relies entirely on the planner being correct. Has no concept of independent safety monitoring. Does not mention hardware interlocks. Thinks unit tests are sufficient for safety validation. Cannot explain defense-in-depth principles.

Q: “Your simulation shows 99.9% success rate, but field performance is 95%. How do you close the gap?”

Strong answer: Starts by analyzing the 5% of field failures to categorize them. Checks whether failures cluster around specific scenarios, environments, or conditions. Investigates sim-to-real discrepancies: are sensor models accurate? Does the simulation capture realistic agent behavior? Are there physical effects (wheel slip, actuator lag, communication delays) that the simulation ignores? Uses real-world failure data to build targeted simulation scenarios. Applies domain randomization to make the simulation less idealized. Runs regression testing to confirm that sim improvements correlate with field improvements. Understands that closing this gap is iterative, not a one-time fix.

Red flags: Assumes simulation is authoritative and the field results are anomalous. Does not analyze the specific failures. Plans to “improve the simulation” without a targeted strategy. Does not understand that sim-to-real transfer is an ongoing challenge, not a solved problem.

Q: “How do you handle partial observability in a planning system? Give a concrete example.”

Strong answer: Explains that in most real-world scenarios, the robot cannot observe everything that matters for decision-making. Uses a concrete example: “When approaching a blind corner, the robot cannot see whether a pedestrian is about to step around it. We maintain a belief state that represents the probability of hidden agents based on historical data and environmental context. The planner treats high-probability hidden-agent locations as soft constraints, reducing speed proportionally to the uncertainty.” Discusses information-gathering actions: the robot might position itself to improve visibility before committing to a maneuver.

Red flags: Assumes full observability. Plans only based on what is currently visible. Has no concept of belief states or uncertainty in state estimation. Cannot provide a concrete example. Says “the perception system handles that.”

Q: “Describe how you would implement a decision-making system under time pressure, where the robot must act within 100ms.”

Strong answer: Discusses anytime algorithms that produce a feasible (if suboptimal) solution quickly and improve it with remaining computation time. Mentions precomputation strategies: caching common maneuvers, maintaining a library of motion primitives, precomputing reachable sets. Describes computational budgeting where the system allocates time across planning stages and has hard cutoffs. Explains the role of fallback plans: the robot always has a previously computed safe trajectory it can execute if the current planning cycle runs out of time. May discuss warm-starting the planner from the previous solution.

Red flags: Ignores the time constraint entirely. Designs a system that takes 500ms and says “we need faster hardware.” Has no concept of anytime algorithms. Does not maintain a fallback plan. Does not understand that deterministic timing is as important as average-case speed.

Q: “How do you validate an autonomy system for deployment? What testing is sufficient?”

Strong answer: Describes a multi-stage validation process. Starts with unit tests for individual components. Runs extensive simulation testing across a scenario library that includes known edge cases, adversarial scenarios, and randomly generated variations. Follows with hardware-in-the-loop testing on the target platform. Then conducts field testing in controlled environments before graduating to real operational conditions with safety drivers or operators. Discusses statistical confidence: how many miles or hours of testing are needed to make claims about failure rates. Understands that testing can never prove safety, only build confidence, and that monitoring in deployment is part of validation.

Red flags: Says “it works in simulation” is sufficient. Has no concept of statistical confidence in testing. Skips hardware-in-the-loop testing. Does not include field testing in their validation plan. Cannot explain what “sufficient testing” means quantitatively.

Q: “The perception team says their system has a 5% false negative rate. How does this affect your planning approach?”

Strong answer: Immediately recognizes that a 5% false negative rate means the planner cannot fully trust that the perceived scene is complete. Describes concrete mitigations: maintaining memory of previously detected objects that may have been missed in the current frame, using prediction to track objects through detection gaps, adding safety buffers in areas where objects could be present but undetected, and adjusting speed based on the perception system's known limitations. Works with the perception team to understand which object classes and conditions have the highest false negative rates so the planner can be specifically conservative in those situations.

Red flags: Treats perception output as ground truth. Does not consider how perception errors propagate into planning decisions. Says “that is the perception team's problem to fix.” Has no strategy for operating with imperfect perception.

Q: “A customer reports that the robot hesitates too much. How do you balance safety conservatism with operational efficiency?”

Strong answer: Starts by quantifying the hesitation: how often, in what scenarios, and what triggers it. Distinguishes between appropriate caution (yielding to a pedestrian in the path) and unnecessary hesitation (stopping for a distant, non-threatening object). Investigates whether the root cause is overly conservative safety margins, noisy perception causing false positives, or a planner that cannot distinguish between threat levels. Proposes targeted fixes rather than globally reducing conservatism. Explains the tradeoff clearly to the customer: “We can reduce hesitation in scenario X with acceptable safety margins, but reducing it in scenario Y would compromise safety.”

Red flags: Immediately reduces safety margins to make the customer happy. Makes no effort to understand the root cause. Cannot quantify or categorize the hesitation. Treats all conservatism as equally important and refuses to adjust anything.

Q: “How do you communicate the limitations of your autonomy system to non-technical stakeholders?”

Strong answer: Describes the operational design domain in concrete, non-technical terms: where the system works, where it does not, and what conditions degrade performance. Uses specific examples rather than probabilistic language: “The robot operates reliably on paved sidewalks in daylight. Performance degrades on unpaved surfaces and in heavy rain. It cannot operate safely on roads without sidewalks.” Creates documentation that operations teams can use to make deployment decisions. Does not overstate capabilities or hide limitations.

Red flags: Uses technical jargon that stakeholders cannot understand. Overstates system capabilities. Hides limitations to avoid difficult conversations. Cannot translate technical constraints into operational guidance.

Q: “You discover a safety-critical bug in the planning system one week before a major demo. What do you do?”

Strong answer: Immediately reports the bug to the team and management with a clear technical description, severity assessment, and reproduction steps. Assesses whether a fix can be implemented and thoroughly tested within the remaining time. If not, proposes mitigations: restricting the demo to scenarios that do not trigger the bug, adding a runtime check that detects the condition and triggers a safe stop, or having a human safety operator ready to intervene. Is transparent about the risk. Never suggests hiding the bug or hoping it will not trigger during the demo.

Red flags: Keeps the bug quiet and hopes for the best. Rushes a fix without proper testing. Does not consider mitigations short of a full fix. Defers entirely to management without providing a technical recommendation.