Embedded engineer interview questions

As asked

A sensor produces data at irregular intervals and the device runs on battery. When would you use interrupts instead of polling, and what can go wrong?

Sample answer outline

Interrupts let the CPU sleep and react when the sensor signals data, which is often better for irregular events and power-sensitive devices. Polling can be simpler and more predictable when timing is fixed, the check is cheap, or the hardware interrupt line is unreliable. Keep interrupt service routines short: capture the event, clear the flag, and defer real work to the main loop or RTOS task. Discuss debouncing, missed interrupts, priority inversion, shared data races, and volatile or atomic access. Interviewers want practical embedded judgement, not a blanket rule that interrupts are always better.

Expect these follow-ups

• How do you safely share data between an ISR and the main loop?
• When can polling be more deterministic than interrupts?
• How would you debug an interrupt storm in the field?

As asked

Write a small ring buffer suitable for bytes received from a UART interrupt handler. Explain the overflow policy.

Sample answer outline

Use a fixed-size buffer with head and tail indices so no allocation happens at runtime. The interrupt handler should do the minimum work: attempt to push the byte and record overflow if the buffer is full. Define the overflow policy explicitly, either drop newest, drop oldest, or set an error flag for the consumer. In real firmware, indices shared with an ISR need atomic or critical-section handling depending on the platform width and concurrency model. Candidates often write a dynamic vector or ignore the full versus empty ambiguity.

Reference implementation (rust)

struct Ring<const N: usize> {
    buf: [u8; N],
    head: usize,
    tail: usize,
    full: bool,
}

impl<const N: usize> Ring<N> {
    fn new() -> Self {
        Self { buf: [0; N], head: 0, tail: 0, full: false }
    }

    fn push(&mut self, byte: u8) -> bool {
        if self.full {
            return false;
        }
        self.buf[self.head] = byte;
        self.head = (self.head + 1) % N;
        self.full = self.head == self.tail;
        true
    }

    fn pop(&mut self) -> Option<u8> {
        if !self.full && self.head == self.tail {
            return None;
        }
        let byte = self.buf[self.tail];
        self.tail = (self.tail + 1) % N;
        self.full = false;
        Some(byte)
    }
}

Expect these follow-ups

• How would this change for DMA-backed UART receive?
• What makes the shared indices safe or unsafe on an 8-bit MCU?
• When would you drop oldest instead of newest?

As asked

Design an OTA firmware update system for a device deployed in homes where physical recovery is expensive.

Sample answer outline

Use A/B firmware slots or a golden fallback image so a bad update does not brick the device. Download and verify the image with signatures and checksums before marking it bootable, then use a bootloader that only commits the new slot after the application reports healthy startup. Roll out gradually by device cohort, model, region, and power or network conditions, with telemetry on download failures, boot loops, and rollback rates. Include version anti-rollback if security requires it, but design a support path for emergency downgrade. Strong candidates discuss power loss during update and how the bootloader state machine handles it.

Expect these follow-ups

• How do you test the bootloader update path itself?
• What telemetry do you need before expanding rollout from 1 percent to 50 percent?
• How do you handle a device that loses power halfway through flashing?

As asked

A firmware build starts crashing only after adding a new feature. The device has 256KB RAM and no MMU. How do you investigate memory pressure?

Sample answer outline

Start from the linker map to see static RAM, stack, heap, and section growth before debugging randomly. Add stack high-water marks, heap allocation tracing if a heap exists, and guard patterns around buffers to catch overflow. Reproduce under worst-case task scheduling and input sizes because embedded failures often depend on timing. Consider moving constant data to flash, reducing buffer sizes, using static allocation, or splitting features behind compile-time flags. Candidates often focus on CPU debugging and miss that the crash is a layout or stack collision problem.

Expect these follow-ups

• How do you size task stacks in an RTOS?
• When would you ban dynamic allocation after startup?
• What clues in a hard fault point to stack corruption?