The problems you’d be working on
Rather than a list of responsibilities, here’s what the team is actually chewing on:
A model that’s two points better offline can be worse on the road. Aggregate benchmark numbers hide the failures that matter — the rare scene, the unusual agent, the bad lighting. Building evaluation that predicts on-road behaviour, and knowing when to distrust your own metric, is a bigger part of this job than architecture search.
We generate far more data than anyone can look at. The interesting frames are a vanishingly small fraction of what the fleet records. Finding them, deciding what’s worth labelling, and keeping the training set honest as the distribution shifts is continuous work, not a one-time setup.
The vehicle’s compute budget is fixed and already full. Everything you add competes with everything already running. You’ll be making concrete trades between accuracy, latency, and memory, and defending them.
Modern architectures keep changing what’s possible. Transformers and multimodal models opened up approaches that weren’t available two years ago. Part of the job is reading what’s coming out, judging honestly whether it applies to our problem, and being willing to conclude that it doesn’t.
Nothing ships alone. Your model’s output is someone else’s input. You’ll work directly with the planning, infrastructure, and vehicle software teams, and the handoffs are where most of the real difficulty lives.