15 Years in ADAS and AV: What I'd Tell an Engineer Entering Now

The industry will hire you for your algorithms. It will keep you, promote you, and eventually trust you with a program because of your systems judgment. Nobody told me that in 2011, when I started out in stereo vision and map matching, and it’s a pattern you can only see from a full arc, cameras, radar, lidar, Tier-1 suppliers, an EV OEM, a robotaxi program, and back to algorithm leadership. This piece is my attempt to hand that pattern to someone entering the field now, so they can spend those years compounding instead of discovering.

I’m going to trace my own arc honestly, transition by transition, and pull out what each one actually taught me. Not the LinkedIn version, the version I’d tell a new hire on my own team.

Starting in algorithms: the discipline you resent is the discipline that compounds

My first ADAS job put me on a stereo-vision platform as a junior engineer, working on camera-based safety features. That was the fun part. The part I underrated at the time was everything wrapped around it: drafting camera and feature requirements, establishing traceability in a requirements management tool, working inside a structured V-model and ASPICE process.

To a young engineer, requirements traceability feels like paperwork standing between you and the interesting problem. I want to be blunt about how wrong that instinct is. The requirements discipline I absorbed in those first two years (how a vehicle-level behavior decomposes into a feature requirement, then into what the sensor must actually deliver) became the single most transferable skill of my career. Every role since has drawn on it: decomposing vehicle requirements into component-level radar requirements on an autonomous vehicle program a decade later was the same mental motion, executed with higher stakes.

Here’s the thing about safety-critical engineering that algorithms courses rarely teach: the artifact is not the code. The artifact is the argument, the traceable chain from “the vehicle shall not brake falsely” down to “the sensor shall detect this class of target under these conditions,” with evidence at every level. Learn to build that chain early and you’re unlikely to end up as the engineer whose brilliant algorithm can’t be shipped because nobody can say what it’s supposed to do.

For the engineering leaders reading this: when you rotate new hires, put them on requirements decomposition for a real feature before you let them settle into pure algorithm work. It feels like a detour. It’s an investment that pays out for fifteen years.

The first transition: from writing the algorithm to owning the problem

After stereo vision, I spent seven years at a Tier-1 supplier doing what I’d call algorithms-at-scale: model-based feature applications like rear cross traffic alert and lane change assist for narrowband and 77 GHz radars, and then a radar-and-camera fusion system for occupant detection and vital-signs sensing inside the cabin. Along the way the job quietly changed shape. I went from developing algorithms to being the technical point of contact for a large cross-functional effort building them, coordinating across algorithm, systems, and validation engineers, collaborating directly with OEM customers on system and functional requirements, and putting the result in front of customers at a live demo event.

Two lessons from that stretch.

First: interior sensing taught me that the sensor alone is never the product; the judgment call is. Detecting an occupant with a radar return is a signal-processing problem. Deciding what the system should claim (is that a child or a bag of groceries, is that breathing or seat vibration) is a systems problem entangled with requirements, edge cases, and what the OEM is willing to warrant. The algorithm work was maybe a third of the engineering effort. The rest was defining what “detection” even means at the system level and proving it. If you enter this field expecting the ratio to favor the algorithm, production will re-educate you.

Second: tooling is leverage, and it’s chronically under-prioritized. One of the contributions I’m proudest of from those years wasn’t an algorithm at all, it was automating development and validation tools and demo suites, which measurably compressed our timeline and produced six-figure cost savings. It was also work that earned an internal award. The engineer who makes twenty other engineers faster is usually worth more than the engineer who is 20% faster themselves. New hires often underinvest here because tooling doesn’t feel like “real” perception work. It is.

Systems ownership: when the supplier’s algorithm is your problem anyway

The next step was formal systems ownership, a camera-based driver monitoring system on one side, and 77/60 GHz interior radar algorithm chains (signal processing, DOA estimation, point cloud processing, tracking) on the other. On the DMS program I wasn’t writing the core algorithms; I was directing suppliers on algorithm design and deliverables, and owning camera design, system design, requirements, hardware testing, integration, diagnostics, vehicle-level tuning, and validation through to successful OEM demos.

This transition is where a lot of strong algorithm engineers stall, because it demands a psychological shift: you are now accountable for engineering you didn’t do. When the supplier’s gaze-tracking underperforms in a corner case, “that’s their algorithm” is not an answer an OEM will accept from you. You have to know the algorithm domain deeply enough to interrogate it (to ask the supplier the question they were hoping you wouldn’t) while resisting the urge to redesign their solution from your desk. Having spent years on the algorithm side myself was what made supplier direction possible rather than theatrical. This is my strongest argument for doing real algorithm work before moving into systems roles: systems ownership without algorithmic depth tends to slide into schedule-chasing and checklist review.

The program-level implication: the best systems owners I’ve worked with are recovering algorithm engineers. If you’re building an organization, that’s a pipeline worth constructing on purpose.

Production reality is the real teacher

Then I went to the OEM side, as the sole owner of radar systems for a next-generation ADAS platform, sensor sourcing strategy, RFI/RFQ, component specifications, BOM and cost optimization with Tier-1 suppliers, environmental qualification, and supporting a production launch. Later, on a robotaxi program, I owned the end-to-end integration lifecycle for imaging radars: requirements decomposition and traceability, mounting locations and field-of-view coverage for 360° detection, electrical interfaces, qualification requirements from −40 °C to +85 °C with vibration, humidity, and EMC, and field benchmarking in rain, fog, and snow.

Everything I thought I knew about sensors got stress-tested in those roles. A few things production taught me that no amount of algorithm work could have:

A datasheet is a negotiation position, not a fact. Sourcing sensors through RFI/RFQ teaches you to read specifications the way a lawyer reads a contract, for what’s conspicuously unstated, for the test conditions under which the headline number was achieved, for the difference between what the silicon can do and what the module will do at 85 °C after ten years of thermal cycling. Field testing candidate sensors in actual rain and snow, against your own requirements rather than the supplier’s marketing conditions, is not optional diligence. It’s where the real ranking of suppliers emerges, and it is routinely different from the datasheet ranking.

Calibration and manufacturing are where perception meets money. The largest cost saving I’ve been part of (approximately six figures) came not from an algorithm but from redesigning a calibration process and altering manufacturing-line procedures for a new radar platform. That experience permanently changed how I evaluate perception designs: an algorithm that requires an exquisite calibration is an algorithm that costs money on every single vehicle, forever. Engineers who have never stood next to a manufacturing line tend to make different (and in my experience worse) architectural choices.

Qualification is a schedule item that behaves like a research project. Temperature cycling, vibration, EMC, these run on calendar time, and a failure late in qualification can cost you a sourcing decision or a launch date. The systems people who get this plan sensor decisions around qualification lead times; the ones who don’t discover it in program reviews.

For a new engineer, my advice is simple: seek out one production launch early in your career, even if it pulls you away from the “interesting” work for a year. The engineers I trust most in this industry are the ones who have shipped, because shipping recalibrates every judgment you make afterward.

Closing the loop: algorithms again, at a different altitude

My current role brought me back to algorithms: leading a team developing monocular Visual SLAM for autonomous parking, feature extraction, Bag-of-Words relocalization, EKF fusion, sparse 3D landmark-based pose estimation in GPS-denied environments, targeting real-time execution on embedded hardware through SIMD-level optimization. On paper it looks like where I started: camera-based perception software.

It isn’t, and the difference is the point of this whole essay. Fifteen years of systems scar tissue changes how you lead algorithm work. As my team designs the pipeline, the questions I bring to the table are the ones production taught me: what the manufacturing calibration story will look like, how we’ll build ground-truth infrastructure we can actually trust (validation you can’t trust is worse than no validation), which ISO 26262 and ASPICE artifacts will have to exist for this to be more than a demo, and how much compute headroom the embedded target really leaves, because I’ve watched beautiful algorithms die at each of those gates. The algorithm-versus-systems framing that dominates career conversations is a false choice. The destination is being an algorithms person with a systems worldview, or a systems person with algorithmic depth. Either combination is rare. Both are what the industry actually needs in technical leadership.

What the ML shift changes for you, and what it doesn’t

If you’re entering now, you’re entering an industry mid-transformation. Learned components are eating the perception stack: deep-learning feature extraction, ML-optimized fusion, segmentation-based approaches. Even in SLAM, learned feature extraction is moving into where classical detectors once lived. So let me be direct about what this changes and what it doesn’t.

What changes: the algorithm-development skill floor has moved. You should be fluent in the ML toolchain the way my generation had to be fluent in signal processing, and ideally both, because automotive perception still runs on embedded silicon with hard real-time budgets, and the engineer who can profile, vectorize, and fit a network into a thermal envelope is, in my experience, worth several who can only train one. Data infrastructure has also become first-class engineering: ground truth, synchronization, and dataset quality now sit where hand-tuned parameters used to.

What doesn’t change: everything in the middle of this essay. A learned model still has to be sourced onto real sensors, calibrated on a manufacturing line, qualified across the automotive temperature range, traced to requirements, defended in a safety case, and shipped inside a cost target. If anything, the ML shift makes the systems skills scarcer, because many engineers entering now are trained to treat the model as the product. The requirements question (what is this system supposed to do, under what conditions, with what evidence) gets harder with a learned component, not obsolete. The engineers who can hold both the network and the safety argument in their head at the same time are, I’d bet, the technical leads of the next fifteen years.

What I’d actually tell you

If a new engineer joined my team tomorrow and asked for the distilled version, here it is.

Learn requirements decomposition and traceability early, and take it seriously even when it bores you, it’s the skill that has transferred across every sensor and every role I’ve held. Do real algorithm work first; it’s the depth that makes every later systems role credible. Then deliberately take the assignment that scares algorithm people: a production launch, a qualification campaign, a supplier negotiation, a manufacturing-line calibration problem. Build tools that make your team faster and let the leverage speak for itself. When you move into systems ownership, stay technical enough to interrogate your suppliers’ engineering, because you’re accountable for it either way. Embrace the ML toolchain fully, and refuse to let it convince you that the model is the product. The model is a component. The product is the system it ships inside: a sensor, on a line, in a car, in the rain, ten years from now.

Fifteen years in, the work that mattered most was almost never the work that looked most impressive on the day I did it. The discipline compounds quietly. Start compounding now.