AIVIA Career Map: Autonomous Driving

Career Maps & Support Career maps
1

AIVIA Career Map: Autonomous Driving Engineering

Autonomous driving spans perception, planning, onboard compute, data infrastructure, simulation, and safety assurance. This map lays out those surfaces: what each involves, how the roles differ across them, and the openings that map to each.

Each component is an AIVIA evaluation unit, a system area where engineers make decisions, debug failures, and explain tradeoffs. All components are listed below; some have public evaluations now, with more added over time.

Candidates: Where an evaluation is live, you can take it for detailed feedback whether you are currently looking for open opportunities or not. It doubles as upskilling and interview prep, and you decide whether any result is visible.

Hiring teams: Use live evaluations to search and prescreen candidates, or work with us to create custom components and evaluations matched to your roles.

 

The job links are here to make the map concrete. They show how each technical surface appears in real hiring language, from internships and student roles through senior and staff roles, so students, pivoters, and experienced engineers can see where a component fits in actual autonomy work. A few postings may have moved or closed since this map was compiled in June 2026.

 


Jump to a role family

 

01 · Onboard compute, acceleration, and deployment

These roles cover the path from a trained model to that model running safely on real silicon: quantization and compilation, runtime behavior under real-time deadlines, the platform services underneath, and getting updates onto the fleet without breaking the cars already on the road.

These teams sit between AI research and automotive silicon, getting large neural networks to run within millisecond deadlines and the vehicle’s thermal and power limits.


Example openings

Senior / Staff / Full-time


Components

  • Accelerator Compiler Runtime: The compiler that takes a trained model and produces code for a specific accelerator. IR design, graph lowering, fusion, and memory planning live here.
  • Edge Model Optimizer: The work of making a model small and fast enough to fit on a target chip while preserving behavior. Quantization choices, calibration, accuracy regressions in the long tail.
  • Hardware-Aware Model Mapping: Deciding how a model maps onto the heterogeneous compute units of a target accelerator: which operations run where, how they’re partitioned and laid out, and the latency, accuracy, and power tradeoffs those choices force on real silicon.
  • Embedded Inference Runtime: The runtime that actually executes the compiled model on the vehicle. Real-time deadlines, thermal limits, and what happens when the model is correct but late.
  • Realtime Compute Platform Services: The OS-level layer beneath the runtime, covering scheduling, IPC, fault response, and the contracts the rest of the stack depends on being deterministic.
  • Embedded Linux Platform Pipeline: The build, integration, and deployment pipeline for the Linux platform the autonomy stack runs on. Kernel configs, drivers, OTA updates, recovery paths.
  • OTA Model Updater: Pushing model and software updates to the fleet, with staged rollouts, health checks, and the rollback path for when a new build misbehaves on a car that’s already on the road.
  • Vehicle Application Platform: The on-vehicle application layer, covering visualization, communication, and the apps that connect riders, operators, and services to the autonomy stack.

↑ Back to the map


02 · Perception, tracking, and sensor fusion

These roles cover how the vehicle sees the world: detecting and tracking objects, fusing data across sensor modalities, generating ground truth, and building the evaluation pipelines that decide whether a perception model is ready to ship.

These teams handle multi-modal inputs (camera, lidar, radar, ultrasonic) and resolve disagreements between them when sensors report conflicting readings of the same scene.


Example openings

Senior / Staff / Full-time


Components

  • Object Detection: Finding and labeling things in camera or lidar data. Confidence calibration, occlusion handling, the long tail of objects that don’t appear often enough in training.
  • Scene Segmentation: Per-pixel understanding of the scene (drivable surface, lanes, free space, obstacles) and how to keep boundaries stable across frames.
  • Perception Fusion: Combining camera, lidar, radar, and ultrasonic into one consistent view of the world. Timestamp alignment, sensor disagreement, and which modality to trust when.
  • Drift Detector: Catching when the world the perception model sees in production starts diverging from the world it was trained on, such as new vehicle types, weather patterns, road configurations.
  • Perception Eval Framework: The pipeline that decides whether a perception model is ready, using slice-aware metrics, simulation runs, fleet replay, and release gates.
  • Ground Truth Annotation Pipeline: Producing the labeled data everything downstream depends on. Human-and-automated review loops, label drift over time, consensus failures on edge cases.

↑ Back to the map


03 · Planning, pose, and autonomy behavior

These roles cover where the vehicle is, what other agents are doing, and what the vehicle should do next: localization and calibration, behavior prediction, motion planning, and the safety layer that runs alongside it all.

These teams model the likely intent of other agents under uncertainty, and run a separate deterministic safety layer that can override the planner when a safety boundary is crossed.


Example openings

Senior / Staff / Full-time


Components

  • Motion Planner: Choosing the trajectory the vehicle actually takes. Cost-weight tuning, decision oscillation between near-equal options, comfort under constraints.
  • Behavior Prediction: Modeling what other agents (vehicles, pedestrians, cyclists) are likely to do next, and how confident that prediction should be.
  • SLAM System: Simultaneous localization and mapping. Real-time pose tracking, incremental drift, false loop closures in repetitive environments.
  • Sensor Calibration: Keeping sensor extrinsics and intrinsics aligned, and detecting when they’ve drifted from temperature, vibration, or physical shifts.
  • Safety Watchdog: The runtime layer that catches violations of safety invariants and triggers fail-safe behavior when the rest of the stack disagrees with itself.

↑ Back to the map


04 · Data, MLOps, and annotation infrastructure

These roles cover the infrastructure that makes autonomy development possible at scale: training data pipelines, multimodal storage, edge-case mining from fleet data, dataset versioning, and the lineage that lets any result be traced back to the exact data and model that produced it.

The work here is large-scale data mining: selecting the small fraction of valuable logs to retrain on, and catching label regressions before they propagate downstream.


Example openings

Senior / Staff / Full-time


Components

  • Training Data Pipeline: Preparing and serving training data at scale. Shuffling, augmentation, distributed loading, and the label-transform consistency that quietly breaks runs.
  • Multi-Modal Data Storage: Storing camera, radar, lidar, vehicle state, and annotations together so they can be retrieved as coherent scenes, and tracking lineage as it changes.
  • Edge Case Mining: Surfacing the rare and hard examples from production fleet data, through coverage analysis, hard-case sampling, and not overfitting to your own mining proxy.
  • Dataset Registry: Versioning training and evaluation datasets with lineage and access control, so a result months later can be traced back to the exact data that produced it.
  • Model Registry: Versioning trained models with lineage back to the data and code that produced them, and the metadata downstream systems need to use them safely.
  • ML CI/CD Pipeline: The CI/CD pipeline for ML, with automated training, evaluation, and promotion runs triggered by code or data changes, plus the artifacts and approvals that go with them.

↑ Back to the map


05 · Simulation, validation, and safety assurance

These roles cover how the system is proven, before it drives and after: closed-loop simulation and sim-to-real transfer, hardware-in-the-loop benches, the release gates a model must clear, and the safety case that ties every claim to evidence.

These teams reproduce rare and high-risk scenarios in simulation, measure how closely simulation matches real-world behavior, and assemble the validation evidence that safety reviews and regulators require.


Example openings

Senior / Staff / Full-time


Components

  • Sim-to-Real: Bridging simulation and the road through domain randomization, scenario-based validation, and replay between sim and physical hardware, plus the work of proving the gap is small enough to trust.
  • HIL Validation Platform: Hardware-in-the-loop benches that run scenarios against real ECUs. The work of explaining why a behavior on the bench doesn’t reproduce in the vehicle.
  • Model Validation Gateway: The automated gates a model must pass before promotion (performance, fairness, safety) and the work of keeping those gates aligned with what production will actually see.
  • Safety Case Evidence System: Turning “we tested it” into a defensible argument, with traceable safety claims, hazards, mitigations, and validation evidence, plus the responses a regulator will actually accept.

↑ Back to the map


06 · Engineering judgment for senior and staff roles

Senior and staff autonomy roles cover the technical surfaces above, plus a separate axis: judgment under ambiguity. When evidence conflicts, when teams disagree, when leadership wants speed, and when concerns are real but not yet proven. These show up across every role family.

There’s no separate openings list here: these surfaces are exercised in the senior and staff versions of the roles in every section above, not in postings of their own.

The work includes decisions such as whether to delay a driverless launch to resolve an unproven regression, and defending that decision under schedule pressure.


Components

  • Technical Conflict Resolution: Resolving disagreements between senior engineers without losing the evidence, and without consensus theater or quiet authority overrides.
  • Architecture Risk Choice: Making architectural decisions under safety, schedule, and reliability tension, and defending those decisions when the tradeoffs come due.
  • Stakeholder Alignment: Coordinating across autonomy, hardware, safety, and product when their goals and timelines aren’t naturally aligned.
  • Tech Debt Prioritization: Choosing what to fix now, what to defer, and what to make legible enough that the next team can decide for themselves.

These four are a sample. Engineering effectiveness spans far more, including incident response, blameless post-mortems, code-review feedback, RFC authorship, scope management, build-vs-buy, and others, collected in the full skills catalog.


↑ Back to the map


Internships and early-career

Student, intern, and co-op roles in autonomy are sparse and rotate quickly, so the current openings are collected here rather than split across the families above. Check each company’s careers page for new student and early-career roles.


Openings


↑ Back to the map


Evaluations

The first evaluations are landing in the areas hiring teams are asking about most:

Autonomous Systems
AI Compute Infrastructure
Technical decision-making

Follow those categories to see what’s open and catch new ones as they’re added.

 


Candidates: Get started today and start building your profile. AIVIA evaluations sharpen skills, doubles as interview prep, and gives you detailed feedback every time. Results stay private unless you choose to share them.

Hiring teams: Start with the live evaluations. Prescreen with custom ones. Search the talent pool by verified reasoning.

New here? Start with the quick start.

Questions? Reply below.




autonomous_driving_map
autonomous_driving_map2160×2160 458 KB