What the interviewer wants
- What you capture and where, at the moment of the fault
- How it survives the reset and gets off the device
- How engineers turn it into a root cause
Constraints
- Cortex-M4, 512 KB flash, 128 KB RAM, FreeRTOS
- Devices upload telemetry over MQTT once an hour
- Flash writes from a fault handler are risky; RAM survives a software reset but not power loss
- Firmware images are built in CI; builds are reproducible
If you ask the interviewer
- Which resets matter? HardFault, watchdog, assert failures, stack overflow and brown-out.
- Privacy constraints? Don't upload user data; memory contents of the network buffers are off limits.
- Can the device reboot twice? Yes, as long as it ends up running normally.
How it's graded
The rubric a senior interviewer would use. Each item is scored 0 to 3 and weighted.
| What is captured | weight 3 |
| Safe fault handler | weight 3 |
| Persistence and upload | weight 2 |
| Symbolisation and triage | weight 2 |
| Other resets | weight 1 |
| Validation | weight 1 |
How to structure your answer
- Requirements and assumptions: the numbers that drive the design.
- Architecture: blocks, tasks, data flow, memory.
- Key decisions and trade-offs, with the alternatives you rejected.
- Failure modes and recovery.
- Testing and validation.
More design rounds
Write your design in five sections and get it graded against this rubric, with a follow-up question from the AI interviewer.
Answer this round