Embedded Software Engineer interview questions and practice.
Develops software that runs on microcontrollers and hardware devices, working close to the metal on drivers, real-time systems and IoT products.
No card for the taster. Full interviews are paid one at a time. Nothing renews.
Last reviewed
This page is still being written: no authored question bank for this competency family. The role is fully supported in the interview itself; only the published question bank is outstanding.
What interviewers for Embedded Software Engineer actually ask
The question bank for this role is still being written. These are the first three competencies in the model the interview is scored against.
Understands the target hardware well enough to bring up and drive peripherals from datasheets and schematics, and to debug when the hardware does not behave as documented.
Designs firmware that meets timing requirements using interrupts, RTOS tasks, priorities and synchronisation correctly, and can prove it under worst-case conditions.
Delivers functionality within tight flash, RAM, CPU and power budgets, measuring rather than guessing and making explicit trade-offs.
What they are really assessing
Interviewers rarely score whether you seemed nice. They score against a model like this one, usually without telling you it exists. Each competency has a weak, adequate and strong shape, and the difference is almost always the level of specific detail you volunteer without being asked.
Hardware/software interface & peripherals
Understands the target hardware well enough to bring up and drive peripherals from datasheets and schematics, and to debug when the hardware does not behave as documented.
- Weak
- Relies on vendor HAL examples without understanding registers, timing or electrical constraints; cannot describe reading a datasheet to configure a peripheral or a hardware bug they diagnosed.
- Adequate
- Has configured peripherals (SPI, I2C, UART, ADC, timers) from datasheets and debugged a bus issue with a logic analyser, but is less sure about errata, timing margins or electrical causes.
- Strong
- Gives a specific bring-up or bug story: reading the datasheet and schematic, the measurement (scope, logic analyser) that isolated it to hardware, firmware or an erratum, and the workaround and its trade-offs.
Real-time design & concurrency
Designs firmware that meets timing requirements using interrupts, RTOS tasks, priorities and synchronisation correctly, and can prove it under worst-case conditions.
- Weak
- Uses delays and polling everywhere; cannot explain interrupt latency, priority inversion or what data must be protected between ISR and main context; timing is 'it seemed fine'.
- Adequate
- Uses interrupts and RTOS tasks with appropriate priorities and mutexes or queues, and has fixed a race condition, but worst-case timing was not measured or analysed.
- Strong
- Describes a real-time requirement with numbers, the design that met it (ISR split, task priorities, lock-free queues), how worst-case latency was measured or analysed, and a concurrency bug they found and proved fixed.
Memory, power & performance under constraints
Delivers functionality within tight flash, RAM, CPU and power budgets, measuring rather than guessing and making explicit trade-offs.
- Weak
- Cannot state the memory or power budget of a project they worked on; optimisation is 'I used -O2'; power management was not considered.
- Adequate
- Tracks flash and RAM usage, has reduced footprint or power with concrete techniques (sleep modes, clock gating, static allocation), but measurements are rough and the trade-offs are not documented.
- Strong
- Gives measured before/after numbers for memory, CPU load or current draw, the techniques used, the trade-off accepted (e.g. latency for sleep), and the tooling that keeps budgets from regressing.
Debugging & testing on target hardware
Finds intermittent, timing-dependent and hardware-related bugs with the right tools, and builds automated tests that run on real or simulated hardware.
- Weak
- Debugging is printf and guesswork; has never used a JTAG debugger, logic analyser or oscilloscope in anger; testing is manual on the bench.
- Adequate
- Uses a debugger, trace and analysers to isolate bugs, and has unit tests off-target and some hardware-in-the-loop tests, but intermittent field issues are hard for them to close.
- Strong
- Describes an intermittent field bug traced with trace, watchdog data or logging to a root cause and proven fixed, plus a HIL or simulation test setup they built that catches regressions automatically.
Reliability, safety & device security
Designs devices that fail safe and recover (watchdogs, brown-out, fault handling), applies safety standards where required, and secures boot, updates and communications.
- Weak
- No watchdog or fault-handling strategy; cannot describe what happens on a stack overflow or power glitch; security is 'the device is not on the internet'.
- Adequate
- Uses watchdogs, brown-out detection and fault handlers, and has implemented signed firmware updates, but cannot discuss safety standards (IEC 61508, ISO 26262) or threat models for the device.
- Strong
- Gives a fault-handling design with recovery paths and field data on its effectiveness, secure boot and update design with key management, and where relevant how a safety standard shaped the process and evidence.
Firmware lifecycle, OTA & manufacturing
Manages versioning, build reproducibility, field updates and production programming so devices can be maintained safely for years.
- Weak
- Builds are done from a developer's machine; cannot describe how field devices are updated, how a bad update is recovered, or how production units are programmed and tested.
- Adequate
- Has reproducible builds and an OTA mechanism with rollback, and has supported production programming, but bricking risk and long-term compatibility are not systematically addressed.
- Strong
- Describes an A/B or bootloader update design with proven recovery from a failed update, a production test fixture or flow they built, and how they handled compatibility across hardware revisions in the field.
Working with hardware, mechanical & product teams
Collaborates with electrical, mechanical and product engineers across a hardware development cycle, negotiating requirements early and handling constraints that cannot be changed after tooling.
- Weak
- Waits for finished hardware before engaging; blames hardware for firmware problems; cannot describe influencing a schematic or a product requirement.
- Adequate
- Reviews schematics and raises firmware needs (test points, debug ports, pin choices) and has negotiated a requirement change, but engagement is reactive.
- Strong
- Gives a case where early firmware input changed a hardware design (pin mux, memory size, debug access) and saved a respin, and one where they worked around a fixed hardware constraint late in the cycle with a clear trade-off.
Reading the questions is the easy half. Try answering three of them out loud, to someone who follows up.
Try 5 minutes freeWhat your 30 minutes covers
The same shape as a real first-round interview, pitched at mid-level Embedded Software Engineer and scored throughout.
Warm-up, then Motivation & fit
Build rapport, settle nerves, and get a short walk-through of your background. Why this role, why this employer, and what you are actually looking for.
Your experience
Two or three real situations from your CV in depth: context, what you did, what happened, what you would change.
Pitched at mid-level scope: owns a firmware subsystem or a whole product's firmware, including architecture, testing and field support; accountable for its reliability.
Role-specific questions
The core competencies and domain knowledge for the role, with follow-ups on anything vague.
Drawn from this role's domain: bringing up a peripheral (SPI, I2C, UART, ADC) from the datasheet and schematic, debugging a bus or timing problem with a logic analyser or oscilloscope and interrupt design: latency, priorities and sharing data safely with the main loop, and the rest of the competency model.
Your questions, then Wrap-up
Your questions for the interviewer, and yes, they are assessed. Next steps and a clean finish.
What changes with seniority
The questions barely change between levels. What changes is the answer they will accept.
| Junior | Mid | Senior | |
|---|---|---|---|
| Scope of ownership | Owns drivers or features within an existing firmware base with review; expected to test on target and read datasheets independently. | Owns a firmware subsystem or a whole product's firmware, including architecture, testing and field support; accountable for its reliability. | Owns firmware architecture across a product line or platform; accountable for reliability, security, update strategy and technical direction. |
| Tolerance for ambiguity | Handles tasks with some gaps by consulting datasheets and asking targeted questions. | Turns product requirements into firmware architecture, identifies timing and resource risks early, and resolves them with hardware and product teams. | Defines the firmware approach from business and product goals; makes platform, RTOS and supplier decisions with incomplete information. |
| People leadership | None formally. | Mentors juniors, reviews code, may lead a small feature or bring-up effort. | Technical lead for firmware engineers, drives design reviews and standards, mentors across teams. |
| Who they deal with | Own team, hardware engineers, test engineers. | Hardware and mechanical engineers, product managers, test and manufacturing, occasionally customers or field support. | Engineering leadership, hardware and product leads, suppliers, certification bodies, key customers. |
What your report would say
Every competency above scored from your own answers, the sentence that cost you quoted back, and your weakest answers rewritten the way a strong Embedded Software Engineer would have said them.
- Gives measured before/after numbers for memory, CPU load or current draw, the techniques used, the trade-off accepted (e.g. latency for sleep), and the tooling that keeps budgets from regressing.
The format, not a result. Scores on your report come from what you actually said.
Is the AI interviewer realistic? See a full sample report