Firmware EngineerInterview Questions & Practice

Q1. How would you reduce ISR latency without breaking correctness?

Strong answer: Keep the ISR to capture-and-defer: read the hardware, post to a queue or semaphore, and let a task do the real work. Keep interrupt-masked critical sections to a few instructions, set interrupt priorities and nesting deliberately, and use DMA to eliminate per-byte interrupts entirely. Correctness is preserved by making the deferred path own the data — not by making the ISR faster at everything.

Weak answer: A weak answer just says to make the ISR faster without explaining what gets deferred.

Q2. When would you choose polling over interrupts for a peripheral?

Strong answer: Polling wins when events arrive so fast that interrupt entry and exit overhead dominates, or when worst-case latency must be deterministic in a dedicated loop. Interrupts win for sparse events and for low power — sleep until something happens. DMA is the third option that often beats both by removing the per-event CPU cost altogether.

Weak answer: A weak answer assumes interrupts are always better.

Q3. What would you inspect first if an OTA update bricks devices after reboot?

Strong answer: Check the boot chain in order: does the bootloader validate the image (CRC or signature) before jumping; is the layout A/B dual-bank with automatic rollback when the new image fails to confirm a healthy boot; do the vector-table offset and flash layout match the image; and is the commit metadata written atomically and last, so a power cut mid-update cannot strand the device.

Weak answer: A weak answer blames the firmware image without checking recovery and boot sequencing.

Q4. A low-priority task holds a mutex that a high-priority task needs, and a medium-priority task is starving them both. What is happening and how do you fix it?

Strong answer: This is priority inversion: the high-priority task is blocked behind the mutex holder, and the unrelated medium-priority task preempts the holder, so the inversion persists. The standard fixes are priority inheritance (the holder temporarily inherits the blocked task’s priority) or a priority ceiling protocol. A strong answer also says what each costs in worst-case latency analysis.

Weak answer: A weak answer raises the low task’s priority by hand, which fixes this trace and breaks the next one.

Q5. How do you size a task stack when interrupts can nest, and how do you verify the number in the lab?

Strong answer: Size from worst-case call depth using compiler-reported frame sizes, then add interrupt margin only where it lands on the task stack: on Cortex-M ports nested ISRs run on the dedicated main stack and only one exception frame hits the task stack, while ports without a separate interrupt stack must budget full nesting on every task. Verify with high-water-mark instrumentation or stack painting on real workloads rather than trusting the estimate.

Weak answer: A weak answer doubles the default stack size and moves on, leaving the overflow to reappear under a rare interrupt sequence.

Q6. Why does a peripheral register read in C need volatile, and when is volatile alone not enough?

Strong answer: volatile tells the compiler the value can change outside normal program flow, so every access must actually happen — without it, the optimizer may cache the register in a CPU register and a status-poll loop never sees the update. It is not enough when ordering matters across the memory system: volatile constrains the compiler, not the hardware, so write buffers and reordering still require barriers (DMB/DSB on Arm). The classic failure is starting a DMA transfer before the descriptor writes have actually reached memory.

Weak answer: A weak answer recites "volatile prevents optimization" without knowing it provides no inter-thread synchronization and no hardware memory ordering.

Q7. A device locks up roughly once a week in the field but never in the lab. How do you approach it?

Strong answer: Build capture infrastructure first — watchdog reset-cause registers, persistent crash logs, trace buffers in retained RAM — so the next field failure produces evidence instead of a shrug. Then reason about what differs from the lab: temperature, supply quality, traffic patterns, and uptime-dependent effects like heap fragmentation that only appear after days of operation.

Weak answer: A weak answer adds a watchdog reset and calls it fixed, hiding the failure instead of finding it.

Q8. Walk the secure-boot chain of trust. Where does trust start, and what breaks if one link is skipped?

Strong answer: Trust starts in immutable code — a boot ROM holding or hashing a root key in OTP/fuses. Each stage verifies the next stage’s signature against a key chained back to that root before jumping to it: ROM checks the bootloader, the bootloader checks the application. Skip one link — the bootloader runs an unverified app — and the whole chain is worthless, because an attacker only has to replace the first unchecked stage. A strong answer adds that the root key must live in write-protected storage; a root of trust you can re-flash is not a root of trust.

Weak answer: A weak answer says “the bootloader checks a signature” without naming an immutable root or explaining that every stage must verify the next before handing off control.

Q9. How do you stop a downgrade attack that re-flashes an older, signed-but-vulnerable image?

Strong answer: Signature checks alone do not help — the old image is validly signed. You need a monotonic anti-rollback counter (a security/version counter in OTP or a monotonic NVM cell): the bootloader refuses any image whose version is below the stored minimum, and the counter advances only after a new image confirms a healthy boot. A strong answer names the cost — the counter is one-way, so bumping it on a bad image can brick the field population, which is exactly why it advances on confirmation, not at flash time.

Weak answer: A weak answer relies on the signature check or a software version flag kept in rewritable flash, which the attacker can roll back along with the image.