Embedded Software Engineer Interview Guide

Demonstrable experience with real-time operating systems (RTOS) such as FreeRTOS, VxWorks, or QNX

C and C++ proficiency — list the version standards you have worked with (C++11/14/17)

Hardware/software interface experience: SPI, I2C, UART, CAN, PCIe

Evidence of working in safety-critical or high-reliability environments (ISO 26262, IEC 61508, DO-178C)

Familiarity with debugging tools: JTAG, oscilloscopes, logic analysers

Experience with version control (Git) and CI/CD in embedded contexts

Real hardware experience — have you actually debugged on target silicon, not just in simulation?

Understanding of the full embedded stack: from bare metal to RTOS to application layer

Safety and reliability mindset — critical in ASML and medical device contexts where a software fault stops production

Ownership and problem-solving ability — can you diagnose a race condition at 3am without help?

Communication with hardware and mechanical teams — embedded engineers do not work in isolation

Embedded development tools: IDE, debugger, compiler — name the specific toolchain

Version control (Git) and code quality practices (code review, static analysis)

Communication protocols you have implemented at driver level: I2C, SPI, UART, CAN

RTOS experience: FreeRTOS, Zephyr, QNX — and the scheduling and synchronisation patterns you used

Test automation and continuous integration in an embedded context

Functional safety standards if applicable: ISO 26262, IEC 61508

Security practices: secure boot, encryption, memory protection units (MPU)

Power management and low-power design techniques

Listing languages without context — "C++" on its own tells a recruiter nothing; specify what you built

No mention of the target hardware (MCU/MPU families: ARM Cortex, STM32, NXP i.MX)

Burying the most relevant experience at the bottom of the CV

Missing keywords that ATS systems filter on: "bare-metal", "firmware", "BSP", "device driver"

Omitting team size and project scale — recruiters want to know if you worked solo or in a 50-person organisation

Q1

Walk me through how you debug a race condition in a real-time embedded system. What tools do you use?

Q2

Explain the difference between a hard real-time and soft real-time system. Give an example of each from your experience.

Q3

How do you handle memory management in a system without dynamic allocation? Why would you avoid malloc in an embedded system?

Q4

Describe a time when a hardware bug looked like a software bug. How did you identify and resolve it?

Q5

How do you ensure your firmware is safe to update in the field? What is your approach to OTA updates?

Lead with your most impressive embedded project in the first bullet of each role

Quantify impact where possible: "reduced boot time by 40%", "achieved 99.97% uptime over 18 months"

Tailor the skills section to the specific vacancy — pull keywords directly from the job description

If you have safety certification experience, put it in a dedicated section near the top

A GitHub link with real embedded projects (even personal ones) significantly increases callback rate

Intermittent system crashes were occurring in the field across deployed units, with no reproducible pattern in the lab.

Root cause analysis pointed to memory corruption — but the exact allocation pattern causing it was difficult to isolate in a real-time environment.

Enabled memory protection unit (MPU) regions, added heap integrity checks, and systematically traced the corrupted pointer through JTAG debugging sessions. Rewrote the affected memory management module with a fixed-pool allocator.

Crashes reduced by 90%. Field returns dropped significantly within two months of the firmware update.