Mission Software Engineer - Undersea Reconnaissance & Strike

Mission Software Engineer - Undersea Reconnaissance & Strike

Quincy, Massachusetts, United States

Anduril Industries is a defense technology company with a mission to transform U.S. and allied military capabilities with advanced technology. By bringing the expertise, technology, and business model of the 21st century’s most innovative companies to the defense industry, Anduril is changing how military systems are designed, built and sold. Anduril’s family of systems is powered by Lattice OS, an AI-powered operating system that turns thousands of data streams into a realtime, 3D command and control center.

As the world enters an era of strategic competition, Anduril is committed to bringing cutting‑edge autonomy, AI, computer vision, sensor fusion, and networking technology to the military in months, not years.

Anduril Maritime builds autonomous underwater/surface vehicles: autonomy computers running control and mission logic, payload computers driving sonar and other sensors, surface integration units, and ground control stations. We’re past the “does it work in the lab” phase - vehicles are in the field, and field vehicles find bugs the lab never does. We need someone whose job, starting day one, is to pick up those bugs and actually close them: reproduce it, find the real cause, fix it, ship it, tell the team what happened.

To be clear about what this isn’t: it’s not a ticket‑triage‑and‑forward job, and it’s not “junior dev does the boring work while senior devs build features.” You’ll be shipping real fixes in the real codebase. You’re just entering the codebase through “this broke on a vehicle” instead of “here’s a clean feature spec.” Once you’ve built up cross‑subsystem fluency – which this role forces faster than sitting in one subsystem ever would – you move into owning subsystems and roadmap work like anyone else.

• Take a field‑reported anomaly (sensor stopped publishing, mission faulted mid‑track, data stream drifted for no obvious reason) and figure out what subsystem it’s actually in – not just where it was reported.
• Reproduce it for real. Replay recorded sensor/mission data through the live pipeline, pull it into visualization tooling, don’t guess.
• Use the metrics and log infrastructure that already exists (per‑service metrics, dashboards, centralized logs) to reconstruct system state at the moment things went wrong, instead of re‑running until you get lucky.
• Confirm the fix in a simulated environment first, hardware‑in‑the‑loop where that matters, before it goes anywhere near a real vehicle.
• Write the fix in whatever language the subsystem actually uses – Rust, C++, Python, Go, whatever —