TS Battery State Estimation (JR-202611969) + Sr Sub-System Lead Engineer, HV Battery Mgmt (JR-202612558) · built 2026-07-07 · companion to GM applications
0. The 30-second frame (say this, in your words)
"I spent 10+ years at GM on battery / EV validation — I know the systems, the process, and the people. What's different now is that I ship working software fast using AI: data pipelines, validation automation, analysis tooling. I'm a senior engineer who closes the loop from requirement to running code, not just spec." Two anchors carry every answer: deep GM battery/validation credibility + AI-accelerated delivery.
1. Role A — Technical Specialist, Battery State Estimation
JR-202611969 · Milford MI · hybrid 3x/week · senior IC
Owns SOC / SOH / SOP state estimation for HV battery systems: estimation algorithms + embedded implementation + validation + the battery data pipeline/analytics.
Quals mapping (point-by-point)
Role needs
Sam brings
HV battery domain (SOC/SOH/SOP)
10+ yr GM battery/EV validation — lived the failure modes, cell behavior, aging, thermal. Estimation targets are the numbers you already validated against.
Algorithm development
MS EE + DFSS Blackbelt = the math/stats spine (state estimation is Kalman-filter / model-based; DOE + variance reduction is your language).
Validation + correlation
Core strength — you built/ran the validation that estimation algorithms get graded against. You know what "good" looks like on real hardware.
Battery data pipeline + analytics
AI-accelerated data tooling is your edge (see below) — ingest, clean, feature-extract, dashboard test data fast.
Embedded C/C++ (required)
Lighter spot — honest framing below.
AI differentiator (concrete, judgment-forward — NOT "I use AI a lot"):
"I stand up a battery test-data pipeline in a fraction of the usual time — parse loggers, normalize, flag anomalies — because I drive the boilerplate with AI and spend my judgment on what to measure and why."
"For estimation, I can prototype and back-test an SOC/SOH algorithm against historical cell data quickly, then hand a validated reference model to the embedded team — shrinks the algorithm-to-silicon loop."
"AI is a force multiplier on the grunt work (data wrangling, plotting, test harnesses) so senior time goes to the engineering call. I own the correctness; the tool owns the typing."
"My deepest lane is battery systems + validation + algorithm/data work, not day-one embedded C/C++."
"What compensates: I understand the embedded target from the validation side, I read/modify C/C++, and AI-assisted development closes that ramp faster than a traditional one — I ship embedded-adjacent software now."
"I'd expect to lead algorithm + validation from day one and ramp on production embedded coding standards early — and I learn fast because I build to learn."
Pivot: "The value I add isn't another C++ typist — it's the senior who connects the battery physics, the estimation math, and the validation so the embedded work targets the right thing."
Likely questions + answer bullets (Role A)
1. Walk me through how you'd validate an SOC estimation algorithm.
define truth reference (coulomb counting + reference cell tests) → test matrix across temp/SOC/current/aging → error metrics (RMSE, worst-case, drift over cycle) → edge cases (cold, high-rate, near-empty) → correlate model vs hardware → sign-off criteria. Tie to real GM validation you ran.
2. SOH is drifting in the field but not in the lab. How do you chase it?
data-first: pull field vs lab data, segment by usage/temp/age → hypothesize (cell aging model gap, sensor bias, unmodeled load) → reproduce in a targeted test → isolate. Emphasize the data-pipeline speed you bring.
3. How do you think about SOC vs SOH vs SOP — where do they conflict?
SOC = energy now; SOH = capacity/resistance vs new; SOP = instantaneous power limit (temp + SOC + aging dependent). Conflict: SOP must be conservative as SOH degrades to protect the pack; over-conservatism costs performance. It's a validated trade-off, not a formula.
4. Tell me about a hard battery problem you owned end to end.
SAM-FILL a real GM story — STAR: Situation, Task, Action (what YOU did), Result (number). Pick one with a measurable outcome.
5. How would you use AI/ML in this role responsibly?
ML for pattern/anomaly detection + data-driven aging models; AI for tooling/automation. Guardrail: physics-based models stay authoritative for safety-critical limits; ML augments, doesn't replace validated safety logic. Shows judgment, not hype.
6. You're light on production C/C++. Why you?
Use the honest-framing bullets above.
7. Describe your validation-to-requirements discipline.
DFSS mindset: requirement → measurable spec → test that proves it → traceability. You've done DFMEA + DOE; you validate against intent, not just pass/fail.
8. How do you work with the embedded + controls teams?
Hand off a validated reference model + clear acceptance criteria; stay in the loop through bring-up; translate between physics/algorithm and code. Senior IC glue.
9. Why come back to GM (and via a gap)?
Honest + forward: built an independent services business (real shipped software + trades), sharpened AI-accelerated delivery, and want to bring that back to the battery problems you know at GM scale. Eligible again as of 7/1.
10. Where do you want to grow?
Deeper on production embedded + estimation algorithm ownership; long-term technical leadership on battery software.
2. Role B — Senior Sub-System Lead Engineer, HV Battery Management
JR-202612558 · Milford MI · hybrid 3x/week · senior IC across the full lifecycle
Owns a battery-management sub-system across the V: requirements (Requirements-First / BDD / Given-When-Then), SSTS/BTS, DFMEA, MBSE, agile/Scrum, embedded controls + calibration.
Quals mapping (point-by-point)
Role needs (req/preferred)
Sam brings
SAFe / agile (PREFERRED)
SAFe 5 certified — lead with this; it's an explicit preferred qual. You've run cadence/PI-style delivery.
Requirements-First / BDD / Given-When-Then
Matches how you already work — requirements rigor + acceptance criteria. Frame validation as executable requirements.
SSTS / BTS documents, traceability
GM systems + validation background = you've authored/consumed sub-system technical specs and traced them to test.
DFMEA
DFSS Blackbelt — DFMEA is core toolkit; you've led risk analyses.
MBSE
Systems-thinking + your validation modeling; ramp on the specific toolchain.
Embedded controls + calibration
Calibration/controls experience + validation; safety-critical / ISO 26262 familiarity (preferred qual you hit).
AI differentiator (framed for a systems-lead role):
"I turn requirements into executable checks fast — Given-When-Then scenarios wired to automated validation, generated + maintained with AI, so traceability isn't a document that rots."
"I automate the DFMEA / traceability / review overhead so the team spends time on engineering judgment, not spreadsheet upkeep."
"As a sub-system lead, AI lets me prototype interfaces and calibration tooling quickly to de-risk decisions before committing the team."
Likely questions + answer bullets (Role B)
1. How do you take a battery sub-system from requirements to validated delivery?
Requirements-first (SSTS) → decompose to testable specs (BDD/GWT) → DFMEA to surface risk → design + calibration → validation traced to each requirement → sign-off. Walk the V.
2. Give an example of leading a sub-system across teams.
SAM-FILL a GM story — cross-functional (hardware/controls/validation), your leadership, the outcome.
3. How do you run DFMEA and act on it?
Structured severity/occurrence/detection, prioritize by RPM/AP, drive detection/mitigation into design + test, close the loop. DFSS discipline.
4. How does SAFe/agile work for safety-critical embedded?
Cadence + backlog + PI planning for flow; but safety artifacts (requirements, DFMEA, ISO 26262 work products) stay rigorous — agile organizes the work, it doesn't skip the safety case.
5. Requirements-First / BDD — what does that mean to you in practice?
Write the acceptance scenario (Given-When-Then) before the design; it defines "done" and becomes the test. Prevents scope drift + makes traceability automatic.
6. Walk me through a calibration problem you solved.
7. How do you handle a requirement conflict between sub-systems?
Surface early via interface specs + MBSE model; quantify the trade; escalate with data + a recommendation, not just the conflict.
8. ISO 26262 — how have you touched functional safety?
Frame your real exposure honestly (safety-critical validation, FMEA, requirements traceability); note it's a preferred (not required) qual and you're ramping the formal work-products.
9. Why you for a senior sub-system lead seat?
Systems + validation + requirements rigor + SAFe + the AI-accelerated delivery that makes traceability + tooling actually stay current. Senior IC who ships.
10. How do you mentor / raise the team's bar?
SAM-FILL — example of leveling up peers/process; the AI-tooling you'd share.
3. Smart questions for Sam to ASK (both roles)
"What does success look like in the first 6–12 months for this seat?"
"Where does this sub-system / estimation work sit on the current program timeline — what's the pressing problem right now?"
"How is the team split between algorithm/validation and production embedded — where would I own the most?"
"How open is the group to AI-accelerated tooling in the validation + requirements workflow?" (plants your differentiator)
"What's the biggest technical risk on the program you'd want this person to de-risk?"
Role A only: "How mature is the battery data pipeline today — build vs. maintain?"
Role B only: "How formal is the ISO 26262 / MBSE toolchain today — established or standing it up?"
4. Logistics + reminders
Both roles: senior IC → comp anchor GM Level 7 ($140-190K); do NOT undersell. Let them frame comp; place your number into it.
Run in parallel with Robo (Dom wants Sam, structure TBD) — two paths = leverage. Don't drop either.
Message Luke + Adam (internal advocates) about both reqs + any other openings — lead with the AI differentiator.
Have 3–4 STAR stories ready (a hard battery/validation win, a cross-team lead, a calibration/controls fix, an AI-accelerated delivery) — reuse across questions.
SAM-FILL before interviews: pick + rehearse 3-4 real STAR stories (bank below) · application confirmation #s + recruiter/HM names once they reach out · whether you messaged Luke + Adam · interview dates.
5. STAR-story bank SAM + CLAUDE TO FILL
Fill 4–5 of these with real GM examples (work them with Claude). Each is reusable across many questions — a strong story bank beats memorizing answers. Format: Situation (context, 1 line) → Task (what was on you) → Action (what YOU specifically did) → Result (a NUMBER if possible). Keep each to ~60–90 seconds spoken.
Slot 1 — Validation root-cause win
A hard battery/validation problem you chased to root cause. Answers: Role A Q1/Q2/Q4, "hardest problem," "how you validate."
S: [SAM+CLAUDE] · T: [__] · A: [what you did — the method] · R: [number: error reduced, defect caught, time saved]
Slot 2 — Led a project / sub-system across teams
You owned a sub-system or program element end to end. Answers: Role B Q1/Q2/Q9, "leadership," "cross-functional."
S: [SAM+CLAUDE] · T: [__] · A: [how you led + coordinated hardware/controls/validation] · R: [shipped / milestone / outcome]
Slot 3 — DFSS / DFMEA catch
A risk your DFSS/DFMEA discipline surfaced + drove into the design/test. Answers: Role B Q3, "DFMEA," "requirements rigor."