How would you design a firmware update process for devices in the field so a failed update never bricks them?

What the interviewer is looking for

• This question tests firmware testing & reliability. Tests on host and on target, uses hardware in the loop, watchdogs and safe update mechanisms.
• Strong answers: Dual image or A and B partitions, a small trusted bootloader, image verification and signing, rollback on failed boot, watchdogs and staged rollout.
• Likely follow-up: How would you stop someone installing malicious firmware?

Another way it may be asked: Thousands of devices update over the air, and some lose power halfway through. How do you make sure they always recover?

A structure to follow: Requirements, sketch, deep-dive, trade-offs

1. Step 1

   Requirements

   Ask who uses it, what it must do, and which qualities matter most: speed, reliability, cost, consistency.

2. Step 2

   Sketch

   Draw the main parts and the path one request takes through them before adding detail.

3. Step 3

   Deep-dive

   Pick the riskiest part (storage, queueing, failure handling) and go deeper there.

4. Step 4

   Trade-offs

   Name what you gave up for each choice, and what you would do first if it needed to grow.

This is guidance on shape, not a script. Use your own real experience and facts; never invent details to fill a gap. See the STAR guide and answer frameworks.

Common slips

• Naming tools before establishing requirements.
• Drawing every box at the same depth instead of going deep where it matters.
• Presenting one design as the only answer, with no trade-offs.

How to practise it

Time yourself: two minutes on requirements, five on the sketch, five on one deep-dive, two on trade-offs.

Related questions

• How do you test firmware when the hardware isn't ready yet or is in short supply?
• What does the volatile keyword do in C, and when would you need it in firmware?
• Can you explain the difference between I squared C, SPI and UART, and when you might pick each one?
• Your board powers on but the sensor never responds. What steps would you take to figure out what's wrong?
• How do you decide what goes inside an interrupt handler and what gets deferred to a task or the main loop?

Browse all questions