15 embedded interview questions that trip up strong candidates

Firmware Prep — Sun, 15 Nov 2026 01:22:15 +0000

Firmware interviews are not inverted LeetCode. The questions that actually decide a screen are usually short, and they are designed to find out whether you know the limit of a tool, not just its textbook definition. Strong candidates still miss these, because the wrong answer often sounds fluent.

Below are fifteen that come up constantly. Each one includes the distinction that interviewers are listening for. If you can say these out loud, cleanly, you are already ahead of most mid-level loops.

1. What does volatile do?
It forces the compiler to perform the loads and stores you wrote, because the object may change or have side effects the translation unit cannot see. Use it for memory-mapped registers and for simple ISR flags when you are not using atomics. It does not give you atomicity, a hardware memory barrier, or a safe 64-bit access on a 32-bit CPU. For that, use C11 atomics or a lock.

2. const int *p versus int *const p?
The first is a pointer to const: you may move p, you may not write through it. The second is a const pointer: p itself may not be pointed elsewhere. They combine as const int *const p. This is a 20-second question that still eats people who have used const for years.

3. Why is 1 << 31 a problem?
If 1 is a signed 32-bit int, shifting it into the sign bit is undefined behavior. Write 1u << 31. Do bit work on unsigned types, and never shift by a count greater than or equal to the width of the type.

4. Why can't you detect signed overflow with if (a + b < a)?
Because signed overflow is undefined in C. The compiler may assume it never happens and delete your check. Widen to int64_t, add, and clamp; or use a checked builtin. Unsigned wrap is defined; signed overflow is not.

5. Is a packed struct a portable on-wire format?
No. Packing removes padding, which can match a datasheet layout, but it can generate unaligned accesses and it does nothing about endianness. Serialize fields explicitly. memcpy of a native integer onto a big-endian protocol is a bug waiting for a different host.

6. What is legal in an ISR?
Acknowledge the hardware, copy a small amount of data, set a flag, give a semaphore or send to a queue with the FromISR API, and request a context switch if needed. Do not block, do not malloc, do not call a sleeping mutex, and do not printf to a blocking console. Keep it short and predictable.

7. Mutex or binary semaphore?
A mutex has ownership and, on a good RTOS, priority inheritance. Use it to protect data. A binary semaphore is a signaling object with no owner and no inheritance; an ISR can give it, a task can take it. Using a semaphore as a mutex is one of the most common mid-level mistakes.

8. What is priority inversion, and how do you fix it?
A high-priority task is ready but blocked on a mutex held by a low-priority task, and a medium-priority task runs instead, so the delay is unbounded. Fix it with priority inheritance or a priority-ceiling protocol. “Make everything high priority” is not a fix. The public textbook case is the Mars Pathfinder reset in 1997.

9. Which way do Cortex-M priorities run?
On the NVIC, a numerically lower priority value is more urgent. That is the opposite of many RTOS task-priority conventions. If you mix them up while configuring preemption, you will not notice until an ISR you thought was low-priority starts interrupting everything.

10. Is I2C just a slower SPI?
No. I2C is a two-wire, open-drain, addressed bus with ACK/NACK, optional clock stretching, and multi-master arbitration. SPI is typically four wires, push-pull, full duplex, chip-select per device, and has no standard acknowledgement. They fail differently. A missing I2C part NACKs its address; a missing SPI part often just returns 0x00 or 0xFF.

11. A SPI device always reads 0xFF. What first?
Confirm the mode (CPOL and CPHA, one of four), chip-select polarity, and that the clocks actually reach the part. Getting the mode wrong is the first thing to check when a device “does not respond.” Then look at whether MISO is actually driven, and at wiring.

12. What extra bugs does DMA introduce?
Buffer lifetime (do not touch it until completion), cache coherency (clean before the engine reads CPU-written data; invalidate after it writes memory the CPU will read), alignment and length constraints, and error/completion handling. The DMA engine talks to memory, not to your cache.

13. What does the CAN ACK bit actually mean?
At least one healthy receiver heard a valid frame and drove the ACK slot dominant. It is not “the destination sent me a reply.” Classical CAN is content-addressed; higher-layer protocols add destination semantics on top. A missing ACK means no healthy receiver heard the frame.

14. A 32-bit millisecond tick wraps. How do you compare times?
Use a signed difference: (int32_t)(now - deadline) >= 0 means the deadline has been reached, provided the intervals you care about are shorter than 2^31 ticks (about 24.9 days at 1 ms). Do not use now > deadline as an unsigned compare if wrap is possible. A 32-bit millisecond tick wraps in about 49.7 days.

15. A CRC on a firmware image is enough, right?
A CRC (or a hash) is integrity: it catches transport and programming errors. It is not authenticity. If the threat model includes an untrusted sender, you need a signature or a MAC. And a reliable update design still needs a protected bootloader, two slots or a staging area, an atomic commit, a health check, and a rollback path that survives a power cut at every step.

If you take only one habit from this list, take this: say what is defined and what is not — in C, in a protocol, and in a timing budget.

This article was drafted with AI assistance and reviewed for technical accuracy by Firmware Prep.

DEV Community: Firmware Prep

15 embedded interview questions that trip up strong candidates