Systems Test & Readiness Engineer

Role Summary

You will own the technical execution of software and system readiness — from feature freeze through release gate. This is a hands‑on engineering role: you will read through merge requests, review component and subsystem HIL testing, and assess vehicle‑level regression plans, making coverage and risk calls based on engineering judgment of system‑level dependencies. You will drive readiness preparation across subsystem and integration teams, hold them accountable to their commitments, unblock testing where it stalls, and over time raise the bar on what readiness covers — including how regression testing is designed and executed across the organization.

This role is intentionally independent of software release management — Release TPMs own program cadence and gates; you own the engineering substance behind whether the product is actually ready.

• Maintain a working technical model of system‑level dependencies — across power management, communication, software functions, and safety domains — and use it to analyze the broader themes of each release: which major changes are landing, where risk is concentrating across subsystems, and what coverage those themes demand. Make defensible technical tradeoffs under time pressure when late‑breaking changes, regressions, or critical patches require quick decision making.
• Audit and improve how teams test — across engineering build phases, launch readiness milestones, and post‑launch OTA releases. Identify coverage gaps, weak failure‑mode analysis, and over‑reliance on vehicle‑level testing for defects that should be caught earlier. Treat regression testing as a system‑wide concern that no single team solves alone, and improve both the overall regression strategy across teams and the specific test cases inside domains where gaps are evident.
• Define and continuously raise the engineering bar for readiness exit criteria — translating “ready” from a process checkbox into a defensible technical claim backed by traceable test evidence. Build and operate a cross‑team test strategy review cadence that brings domain owners and integration leads to the same table to share approaches, debate coverage, and align on what “ready” means at each program phase.
• Drive readiness execution from feature freeze through external release. Hold domain and integration teams accountable to their commitments, flag slips early, and unblock testing by resolving technical, infrastructure, or coordination constraints (HIL availability, bench access, vehicle assets, missing inputs) that prevent test execution from staying on schedule.
• Drive root‑cause analysis for escapes — issues found in engineering test fleets and customer feedback — back into upstream test plans. Own the loop that prevents the same class of escape twice.
• Serve as an independent technical voice in OTA release reviews. This is a peer function to release management, not a subordinate one.

Minimum Qualifications:

• B.S. in Electrical Engineering, Computer Engineering, Computer Science, Mechanical Engineering, or related field. Advanced degree welcome but not required.
• 8+ years of embedded software, systems integration, or vehicle test engineering experience. Automotive, aerospace, or other safety‑critical embedded domains preferred.
• Hands‑on experience designing and reviewing test strategies for embedded systems — HIL, bench, vehicle‑in‑the‑loop, and on‑vehicle test.
• Deep understanding of vehicle E/E architecture and the dependencies that span subsystem and domain boundaries — power, communication, functional safety, software stack — sufficient to make coverage and risk calls without deferring to feature owners on every question.
• Track record of making technical risk tradeoffs under time pressure and being right often enough that engineering teams trust the call.
• Demonstrated ability to influence cross‑functional teams without direct authority — pulling work forward, surfacing risk early, and changing how other teams test because the technical case was credible.
• Comfort working alongside software release process and OTA delivery in a fast‑moving program — without owning the program itself.

Preferr…