Embedded engineer behavioural interview questions

As asked

Tell me about a time you found a race condition in embedded firmware. How did you identify it, what was the impact, and what did you change to fix it?

Sample answer outline

A strong answer describes a specific incident: the setup (what the code was doing, why concurrency was involved), how the bug manifested (intermittent, hard to reproduce), the debugging approach (logic analyzer, added instrumentation, code inspection), the root cause (missing volatile, missing critical section, non-atomic read-modify-write), and the fix (interrupt disable, FreeRTOS mutex, LDREX/STREX). They should quantify the impact and mention what they added to prevent recurrence.

Expect these follow-ups

• How did you test that your fix actually eliminated the race rather than just making it less frequent?
• What code review or static analysis process would have caught this before it shipped?

As asked

Tell me about the most stressful production firmware bug you have debugged. What was the situation, how did you approach it, and what did you learn?

Sample answer outline

The candidate should describe the context (product shipped, customer impact, time pressure), their systematic approach (what they ruled out first, what tools they used), how they communicated progress to stakeholders, and the resolution. The learning component should be specific: a process change, a new monitoring approach, or a design pattern they now use to prevent the class of bug.

Expect these follow-ups

• What would you have done differently in the original design to prevent this?
• How did you communicate uncertainty to non-technical stakeholders while the investigation was ongoing?

As asked

Walk me through the first time you brought up firmware on a completely new PCB. What order did you validate things in, what went wrong, and how did you work through it?

Sample answer outline

The candidate should describe a systematic bring-up sequence: power rail verification before applying power, connecting a debugger and verifying the CPU is halted and the memory map looks correct, bringing up clock and basic peripherals one at a time, using GPIO toggles to verify ISR timing before enabling more complex subsystems. They should mention a specific problem they encountered (e.g., wrong SPI CS polarity, missing pull-up, PCB errata) and how they distinguished firmware issues from hardware issues.

Expect these follow-ups

• How do you determine whether a bring-up problem is a hardware fault or a firmware configuration error?
• What is your bring-up checklist for a new board revision?

As asked

Describe a situation where you had to write and test firmware before the target hardware was available. What was your approach and how did you validate your code?

Sample answer outline

A strong answer describes using QEMU, a simulator like Renode, or a similar evaluation board, abstracting hardware dependencies behind a HAL so that host-based unit tests could exercise most of the logic, and setting up continuous integration on the host to catch regressions. They should mention what assumptions they had to make about hardware behavior and how they validated those assumptions when the hardware arrived.

Expect these follow-ups

• What surprised you when you finally ran your code on real hardware?
• How did you structure the HAL abstraction to minimize rework when the hardware changed?

As asked

Give me an example of a time you had to make a significant tradeoff between power consumption and performance or responsiveness in an embedded design. How did you decide and what was the outcome?

Sample answer outline

The candidate should describe the constraints (battery life target, response latency requirement), the options they evaluated (clock frequency, sleep depth, sampling rate), how they quantified the tradeoffs (current profiling, battery life calculation), who they involved in the decision, and what they chose. The outcome should include whether the decision proved correct in the field.

Expect these follow-ups

• How did you measure the actual current consumption to validate your estimates?
• What changed your power model between design and production?

As asked

Tell me about a time there was a disagreement between your firmware team and the hardware team about how a peripheral or interface should be designed. How did you resolve it?

Sample answer outline

The candidate should describe the technical disagreement (e.g., pull-up resistor value, SPI clock polarity, GPIO vs interrupt-driven approach), how they brought data to the discussion (timing analysis, datasheet excerpts, prototype measurements), and how they reached a consensus or escalated appropriately. The answer should demonstrate respect for hardware constraints while advocating for firmware needs.

Expect these follow-ups

• What would you have done differently if the hardware team was not receptive to your data?
• How do you document interface agreements to prevent future mismatches?

As asked

Describe a time you caught a safety-critical bug during a code review before it reached hardware. What was the bug, how did you recognize it, and what was the process outcome?

Sample answer outline

The candidate should describe the context (what the code was meant to do), the specific bug (missing volatile, incorrect ISR priority, uninitialized variable, off-by-one in a safety limit check), why it was safety-critical, and how they communicated the issue constructively. The outcome should include any process improvements like additional review checklists or static analysis rules.

Expect these follow-ups

• How do you distinguish between a style issue and a safety issue during code review?
• What static analysis tools do you use in your code review process for embedded C?

As asked

Tell me about a situation where a real-time deadline was being missed in production, causing system misbehavior. How did you diagnose it and what did you do to fix it?

Sample answer outline

The candidate should describe how they detected the deadline miss (watchdog reset, output glitch, error counter), their profiling approach (oscilloscope on a GPIO toggled at task entry/exit, SEGGER SystemView, or a cycle counter), the root cause (ISR blocking, priority inversion, unexpected cache miss), and the fix. They should quantify the before and after timing margins.

Expect these follow-ups

• How do you add timing instrumentation to production firmware without affecting the timing you are measuring?
• What monitoring would you add so this class of problem is detected earlier in future products?

As asked

Tell me about a time you inherited legacy embedded firmware with no documentation and poor reliability. What steps did you take to understand it and improve it without breaking existing functionality?

Sample answer outline

The candidate should describe reverse-engineering the code (reading the linker script, call graph, peripheral register usage), adding a regression test harness before making changes, identifying the highest-risk areas first (ISRs, shared state), and making incremental changes with hardware validation between each. They should mention how they communicated progress and risk to their team or manager.

Expect these follow-ups

• How do you prioritize which parts of the legacy code to address first?
• What would make you recommend a full rewrite rather than incremental improvement?

As asked

Tell me about a time a firmware deliverable was at risk of missing its deadline due to a technical problem. How did you manage the situation and what was the outcome?

Sample answer outline

The candidate should describe the technical blocker (an unresolved hardware errata, an unexpectedly complex driver, a shifting hardware schedule), how they assessed the realistic options (descope, workaround, replan, bring in help), how they communicated early with stakeholders, and what they chose. The answer should demonstrate transparency and a bias toward early communication rather than hoping the problem resolves itself.

Expect these follow-ups

• How did you decide when to escalate versus continuing to try to solve it yourself?
• What engineering practice did you adopt afterward to catch schedule risk earlier?

As asked

Tell me about a situation where your firmware work was blocked on a dependency from another team, such as a PCB revision or a hardware bring-up issue. How did you keep moving and how did you resolve the dependency?

Sample answer outline

The candidate should describe the dependency and its impact, how they communicated the block clearly without blaming the other team, what parallel work or simulator-based approach they used to stay productive, and how they tracked and escalated the dependency. The answer should show resourcefulness and good judgment about when to escalate.

Expect these follow-ups

• How do you build a schedule that accounts for hardware dependencies without building in excessive slack?
• What would you do differently upfront to reduce the chance of this kind of block?

As asked

A fleet of devices in the field is experiencing random resets with no clear pattern. You have no physical access to the devices. What is your plan to diagnose and fix this remotely?

Sample answer outline

The candidate should describe adding a reset cause log in the next firmware push (reading the RCC reset status register on boot), capturing a crash log from the fault handler to non-volatile memory, adding runtime metrics (stack watermarks, heap headroom, ISR timing) to an OTA telemetry report, and segmenting the fleet to narrow the pattern by hardware revision, firmware version, or geographic region. They should mention the need to avoid a firmware push that itself introduces a reset.

Expect these follow-ups

• How do you determine whether the resets are caused by firmware or by the power supply hardware?
• If the RCC reset cause always shows 'power-on reset', what does that tell you and what do you do next?

As asked

During profiling you discover that your SPI receive ISR is taking 8 microseconds on average but your SPI clock gives you only 10 microseconds between bytes. What do you do?

Sample answer outline

The candidate should propose switching from ISR-per-byte to DMA-based reception to remove the CPU from the hot path entirely. If DMA is not available, they should look at what the ISR is doing in 8 microseconds and trim it: avoid printf, avoid FreeRTOS API calls that acquire mutexes, defer processing to a task triggered by a task notification. They should also check whether the ISR is being preempted by a higher-priority ISR unexpectedly.

Expect these follow-ups

• If DMA is already in use and the DMA complete ISR is still too slow, what is your next step?
• How does enabling the Cortex-M instruction cache affect ISR latency?

As asked

A sensor that worked perfectly for three months suddenly stops responding over I2C in a deployed product. The hardware has not changed. How do you approach this?

Sample answer outline

The candidate should check whether the I2C bus is stuck (SCL or SDA held low by the sensor), perform the 9-clock recovery sequence in firmware, check for a stuck start condition, and attempt a sensor soft reset via its register if accessible. They should look for patterns: does it happen after a specific firmware path, at a particular temperature, or after a number of hours? If it is a stuck bus, they should add a bus recovery routine to the I2C error handler. They should also consider whether the sensor has errata or a known failure mode.

Expect these follow-ups

• How do you implement the 9-clock I2C bus recovery in firmware?
• What telemetry would you add now to catch this problem earlier in the next product?

As asked

You need to write a driver for a new sensor IC that has a datasheet but no example code and no existing drivers online. How do you approach it?

Sample answer outline

The candidate should describe reading the datasheet from front to back before writing a line of code, starting with the electrical characteristics (power supply, logic levels, communication interface), then the register map, then the initialization sequence. They should write a minimal read-ID function first to validate communication, add each feature incrementally, and capture all traffic on a logic analyzer to compare against the expected waveforms in the datasheet. They should also mention writing a HAL for the driver so tests can run on the host.

Expect these follow-ups

• How do you handle ambiguous or contradictory information in a sensor datasheet?
• At what point do you contact the chip vendor's application support, and what do you prepare before reaching out?

As asked

Your firmware exceeds the Flash budget by 12KB on final link. Delivery is in two days. Walk me through how you approach reducing binary size without dropping features.

Sample answer outline

The candidate should describe running the linker map to identify the largest contributors, looking for accidental inclusion of printf float support or other Newlib heavy features, enabling -Os or LTO, auditing for duplicate string literals, replacing sprintf with lighter alternatives, and stripping debug symbol sections from the production build. They should also check whether any large lookup tables can be moved to Flash with const, and whether unused code is being pulled in by library dependencies.

Expect these follow-ups

• How does link-time optimization help and what are its risks for embedded firmware?
• What linker flag shows you exactly which object files and symbols are consuming Flash?

As asked

Describe a time you helped a junior embedded engineer work through a difficult debugging problem. How did you guide them without just giving them the answer?

Sample answer outline

The candidate should describe the problem the junior was stuck on, how they asked questions to understand what had already been tried, how they guided the junior to form hypotheses and test them methodically rather than just telling them the answer, and what the outcome was for both the problem and the junior's development. The best answers show a coaching approach rather than a hero approach.

Expect these follow-ups

• How do you decide when to give the answer directly vs continuing to coach?
• What debugging process did you try to instill in the junior engineer through this experience?

As asked

Your bootloader detects a CRC failure on the application image at boot. There is no backup image. The device is in the field with no physical access. What happens next?

Sample answer outline

The candidate should describe the bootloader falling back to a minimal recovery firmware (a factory-flashed safe image in a protected region) that can still connect to the OTA server and download a fresh application. If no recovery image exists, the bootloader should enter a DFU mode waiting for a new image over USB, BLE, or UART if any of those are accessible. They should discuss why this scenario argues for always having a recovery partition and for RDP settings that prevent unauthorized flash erasure.

Expect these follow-ups

• What hardware features on STM32 can protect the bootloader from being overwritten by a corrupted OTA update?
• How do you design the recovery firmware to be as small and reliable as possible?

As asked

Your system becomes completely unresponsive to user input. A logic analyzer shows the CPU is spending 95 percent of its time in one ISR. What caused this and what are your options?

Sample answer outline

The candidate should identify common causes: a GPIO configured for both-edge interrupt on a bouncing line, a UART overrun re-triggering the ISR before it clears the flag, a timer ISR where the period is shorter than the ISR execution time, or an incorrectly cleared interrupt flag creating an infinite re-entry loop. Fixes include adding a debounce filter, clearing the correct status bit, increasing the timer period, or disabling the interrupt and switching to polling or DMA. They should also mention adding ISR execution time measurement as a permanent guard.

Expect these follow-ups

• How do you safely disable a runaway ISR without corrupting the peripheral state?
• What compiler or RTOS tool can show you live ISR CPU usage without stopping the system?

As asked

Your manager asks you to prepare your embedded firmware for a safety or security certification (IEC 61508 SIL 2 or IEC 62443). You have never done this before. How do you approach the gap analysis and what are the first things you address in the codebase?

Sample answer outline

The candidate should describe studying the standard's requirements for the relevant SIL level, engaging a certification body early to understand documentation requirements, performing a FMEA to identify failure modes, adding redundancy or error detection for safety-critical paths, switching to a certified RTOS variant or a safety-qualified compiler (e.g., MISRA C compliance), and establishing a formal verification and validation plan. They should acknowledge they would bring in expertise they lack rather than guessing.

Expect these follow-ups

• What are the most common MISRA C violations you see in typical embedded codebases?
• How does SIL 2 change your testing and documentation requirements compared to a commercial product?