SpaceX · Hawthorne, CA
Avionics Test Engineering Intern
A test-side avionics role: you are handed flight hardware that does not work yet and expected to find out why. The posting is unusually explicit about the bench — oscilloscopes, DMMs, hardware-in-the-loop fixtures — which tells you the interview will be about measurement and debugging rather than about designing a board from a blank schematic.
What this interview will test
Read from the posting itself, against the topics hardware interviewers actually probe. The terms beside each topic are the ones that appear in the posting.
- Test Automation→
automated test · hardware-in-the-loop
Turning a manual bench check into a repeatable automated test.
- Communication Protocols→
spi · i2c · uart · can
The buses that connect parts, and how they fail.
- Signal Integrity→
signal integrity · high-speed
What happens to a signal between the driver and the receiver.
- Embedded Systems→
embedded · arm · firmware
Microcontrollers, peripherals, and the hardware-software boundary.
- Lab Instrumentation→
power supply · bench
Getting a measurement you can trust.
- PCB Bring-Up & Debug→
bring-up · debug
Taking a new board from bare to working, and diagnosing it when it is not.
Ranked by the terms above, matched against the topic taxonomy. This is the free reading of the posting. The curriculum you get inside weights these against each other from the full text and shows the sentence behind every weight.
A question this role would ask
From the topic this posting signals most strongly. Try it before you open the answer — that is the whole loop, and this is what the generated bank looks like.
You are bringing up a new avionics board. The 3.3V rail measures 3.28V on a DMM and looks correct. The microcontroller runs, but roughly one boot in five it comes up with its I2C sensor bus wedged, both lines held low.
Walk through how you would isolate this. What do you measure first, and what would each result rule out?
What a strong answer covers
The intermittency and the both-lines-low symptom point at a slave mid-transaction rather than at the rail. A DMM average of 3.28V says nothing about behaviour during the boot transient, so the first move is to scope the rail against the reset line and the I2C lines together on a single trigger, capturing the failing boot — that separates a brownout or slow rail ramp from a bus that is being held. If the rail is clean, both lines low with the master idle is the classic stuck-slave case: a device that was mid-byte when the MCU reset, still clocking out data and holding SDA. Confirming it means clocking SCL manually until SDA releases, which is also the standard recovery. The fix is a bus recovery sequence in init, plus checking whether the sensor's reset is tied to the MCU's — a slave that does not get reset when the master does is the root cause, not the symptom.
- Distrusts the DMM reading — Recognizes that an averaged rail measurement cannot show a transient, and moves to a triggered scope capture of the failing boot.
- Reads the symptom — Connects both-lines-low with an idle master to a slave holding the bus, rather than treating it as a generic 'bus problem'.
- Separates cause from recovery — Distinguishes the recovery clocking sequence from the actual root cause — asymmetric reset between master and slave.
- Orders the measurements — Each step rules something specific out; the candidate can say what a clean result would have meant.
See the finished track for this exact posting
Not a sample of someone else’s role — the complete curriculum built from the posting above: every domain weighted, every weight traced back to the line that caused it, and the question loop running. No account needed.