Hiring for this role?
Start free with this planFree for your first open role.
Why Hirezen?
- Every interviewer runs the same script and marks the same signals.
- AI drafts the write-ups, and the debrief puts every read side by side.
- No ATS to set up first, and no bot in the call.
Embedded Systems Engineer interview questionsTechnical Interview round
A 60 min interview plan with a time-boxed script, what each question is for, and the signals to score against. Key skills: Interrupt and DMA concurrency, field-failure debugging and power budgeting, on one battery-powered vibration sensor: corrupted readings from its data path, units that hang after a brown-out, and a cell that must last five years.
Opening
Who is interviewing, how the round will run, and a question to settle the candidate in. The standard openingA reading the pump didn't make
What this part is for
Purpose
Runs over one page you show the candidate when the round starts and leave on screen. Nothing is sent ahead and nothing is coded. Give the candidate five minutes with the page before the hour starts, and book 75 minutes: five to read, sixty for the round, ten for their questions. Write the page to this composition, which adds up. The device is a battery-powered vibration and temperature sensor that bolts onto pump and motor housings and reports to a gateway over a sub-GHz radio on its own SPI bus. Its microcontroller is a Cortex-M4F at 64 MHz with 256 KB of flash, 64 KB of RAM and no data cache. A small preemptive RTOS runs two tasks, `radio` at priority 3 and `sense` at priority 2 — the higher number runs first — and sleeps in tickless idle for at most one second at a time. The accelerometer is three-axis, on SPI at 8 MHz; it samples at 1.6 kHz into its own 32-sample FIFO and raises a watermark interrupt each time the FIFO holds 16 samples, every 10 ms. Every 10 minutes `sense` captures 2,048 samples per axis — 128 blocks, 1.28 s — into a 12 KB array, then computes an RMS and a spectrum per axis for a report. The data path: the watermark interrupt starts a 96-byte SPI DMA read of the FIFO into `blocks[w]`, one of two buffers; the DMA-complete interrupt flips `w`, which is declared `volatile`, and gives a counting semaphore; `sense` takes the semaphore and appends `blocks[w ^ 1]`, commented "the buffer the DMA is not filling", to the capture. The temperature sensor is on I2C at 400 kHz, rated down to 1.7 V, and `sense` reads it once a second, three bytes; the I2C driver waits on a semaphore, with no timeout, for its transfer-complete interrupt, and its error interrupts are not enabled. `radio` sends each report and listens for the gateway's acknowledgement; on its own timer it also sends an unacknowledged heartbeat every 5 minutes, with up to 30 s of random jitter, carrying the last temperature and the cell voltage measured at rest. For the 50 ms a transmission is in the air, `radio` polls the radio's status register in a loop. Power comes from one 3.6 V lithium thionyl chloride AA cell, bobbin type, rated 2,600 mAh, through a 3.0 V low-dropout regulator that needs 0.2 V of headroom and supplies the whole board; brown-out reset is set at 2.8 V, the highest level the part offers. Measured at 20 °C: asleep, 10 µA on average, the temperature reads included; capturing, 1.6 mA for 1.3 s; computing, 6 mA for 50 ms; transmitting, 100 mA for 50 ms; listening, 10 mA, usually for 100 ms. In a climate chamber at −20 °C, a cell with 40% of its charge used sags to 2.9 V for the first 5 ms of a transmission and 3.1 V for the rest; at 20 °C the same cell sags to 3.3 V. At boot an init task logs the reset cause to flash, initialises the radio, the accelerometer and the temperature sensor in that order, logging a line after each, and starts `sense` and `radio`. An independent watchdog with a 4 s timeout, which keeps counting in sleep, is refreshed from the RTOS idle hook. Firmware can be updated over the radio, and a unit can be asked to upload its last raw capture. The field report covers 1,200 units over one winter, half of them outdoors. One: 0.4% of reports carry broadband energy the machine does not have, which has tripped high-frequency alarms and sent crews to healthy pumps; every one comes from a capture during which the unit sent a heartbeat. Two: 31 units, all outdoors, went silent until a technician took the cell out and put it back; on each, the log ends with a brown-out reset, "radio initialised" and "accelerometer initialised", then nothing — no watchdog reset — until the cell came out. Three: the reset counters show brown-out resets on most outdoor units and almost none indoors, nearly all between 05:00 and 08:00, at times a transmission was due. Two things are fine and are there to be left alone: `w` being `volatile`, and the 4 s timeout.
I'm [YOUR_NAME], and I look after the firmware on the devices [COMPANY_NAME] ships. This page is a sensor that has spent one winter on pumps, and those are its field reports. For the next hour it's your device: the reports have just landed on your desk, and there is nobody else to hand them to.
What this line is for
Purpose
Makes the candidate the owner of a fielded device rather than a reviewer of a textbook one, so every answer is a decision about units already bolted to machines.
Take five minutes with the page. Paper and a calculator are fine — you'll want them in the last part. We'll take the three reports in order.
What this line is for
Purpose
Gives the reading time before the hour starts and says up front that arithmetic is welcome, so a candidate who works the numbers is not left wondering whether that is the game.
Start with the first report: 0.4% of reports carry energy the pump doesn't have, and every one comes from a capture during which the unit sent a heartbeat. Walk me through what happens in the data path while that heartbeat is in the air, then change the design so a capture comes out right however late `sense` runs.
What this question is for, and what to listen for
Purpose
Tests concurrency between interrupts, DMA and tasks as ownership: which buffer belongs to whom at each moment, and how late the consumer may be. The read is whether the candidate builds a timeline from the page or reaches for a keyword.
Signals to score
- Builds the timeline: `radio` polls for 50 ms at priority 3, `sense` does not run, and the watermark and DMA interrupts carry on every 10 ms regardless
- Sees that with `w ^ 1` worked out when `sense` runs, anything later than one block period reads the wrong buffer — and two buffers could not hold 50 ms of blocks anyway
- Explains the repetition: about five gives wait on the counting semaphore, and each pass appends whatever `w ^ 1` names then — one block five times, the blocks before it lost
- Checks the rate against the page: a 1.3 s capture in a 5-minute heartbeat period is about 0.4%
- Says `volatile` on `w` is neither the bug nor the fix: it makes each access happen, and makes no sequence of accesses atomic
- Rejects disabling interrupts around the copy: the blocks are lost before `sense` runs, so an atomic copy saves none of them
- Hands each finished block over by identity — its index or pointer through a queue, from a pool sized for the worst lateness — or points the DMA straight into the capture array
- Makes `radio` block on the radio's transmit-done interrupt instead of polling, and asks why it outranks `sense` at all
- Detects an overrun — a sequence number per block, or a count kept in the interrupt — and repeats the capture instead of reporting it
- Names the deadline left after the change: about 10 ms to service the watermark interrupt, while the FIFO's other 16 places fill
Follow-up questions
- `w` is already `volatile`. Why isn't that enough?
- Suppose you disable interrupts while `sense` copies the block. Which of the lost blocks does that save?
- One unit's raw capture shows the same 10 ms stretch five times in a row. Why five?
- How many buffers would you need, and which number on the page tells you?
- After your change, what still has a deadline, and how long is it?
Silent until someone pulls the cell
What this part is for
Purpose
One field failure in depth, read from what a unit on a pump leaves behind: a log, a reset cause, and what a technician's hands fixed.
Second report. Thirty-one outdoor units went silent until someone pulled the cell, and every log stops after "accelerometer initialised", with no watchdog reset. Tell me what happened to them, how you would make it happen on your bench this week rather than next winter, and what you would change so a unit gets out of it without a visit.
What this question is for, and what to listen for
Purpose
Tests debugging from field evidence through to recovery that needs nobody on site. The last log line, the missing watchdog reset and the cure by pulling the cell each rule something in or out; the read is whether the candidate uses all three before naming a cause.
Signals to score
- Places the hang in the step after the last log line: the first I2C transfer to the temperature sensor
- Reads "pulling the cell fixed it" as state outside the microcontroller, which the brown-out reset did not clear
- Names the mechanism: a brown-out during a temperature read leaves the sensor — still powered, rated to 1.7 V — mid-byte, holding SDA low and waiting for clocks
- Explains why the first transfer after boot never finishes: no start condition can be made while SDA is held low, and the driver waits with no timeout for an interrupt that will not fire
- Explains the quiet watchdog: a blocked task lets the idle task run, so a refresh from the idle hook proves spare CPU time, not progress
- Answers why only 31: the reset has to land inside a transfer of a fraction of a millisecond — rare per brown-out, routine across a fleet, and more frequent as cells age
- Reproduces it this week — a test build that resets itself at random points in the transfer, or a reset pulse timed from the I2C start — thousands of times, with a logic analyzer on the bus
- Clears the bus at boot and after any I2C timeout: SCL toggled as an open-drain GPIO until the sensor lets go of SDA, at most nine clocks, then a stop condition
- Times out every wait in the I2C driver, and keeps the unit reporting vibration without temperature when the sensor cannot be recovered
- Refreshes the watchdog only when each task, init included, has checked in within its own expected period, so a blocked task ends in a reset the log can explain
Follow-up questions
- The brown-out reset the microcontroller. Why didn't that clear it, when pulling the cell did?
- Most outdoor units brown out on cold mornings. Why have only 31 gone silent?
- The watchdog times out after 4 seconds. Why didn't it fire?
- You clock SCL nine times and SDA is still low. What now?
- Every unit still runs this firmware. What do you send them, and when?
Five years on the box
What this part is for
Purpose
Power budgeting in both of its halves: the charge the cell supplies over its life, and the current it has to supply for 50 ms at −20 °C. The cold-morning brown-outs are where the two meet.
Last report, and a request on top of it. Sales wants a premium tier that reports every minute, and five years stays on the box. From the page, tell me what the cell supplies on average now and what it would then, whether five years survives either — and what the cold-morning brown-outs have to do with your answer.
What this question is for, and what to listen for
Purpose
Tests power budgeting as arithmetic and as electrical behaviour. Many candidates can list low-power techniques; the read is whether they turn a current profile into charge per cycle, and see that a primary cell's useful life can end at a voltage under load before its rated capacity is spent.
Signals to score
- Budgets in charge per cycle rather than from the sleep current: about 8.4 mA·s per report, 10 for two heartbeats and 6 asleep — about 24 mA·s every 10 minutes, about 40 µA on average
- Notices the heartbeats cost more than the reports, and folds the cell voltage and temperature into the reports
- Turns 40 µA into about seven years on paper, then derates for cold, pulse load, self-discharge and the voltage the board needs at the end
- At a report a minute gets about 165 µA, under two years, and says so before proposing anything
- Prices the levers: ten captures per transmission with the heartbeats folded in still leaves about 60 µA, 35 µA of it the capture, so the tier also needs a shorter or slower capture, or a bigger cell
- Works the brown-out from the page: at −20 °C, 2.9 V less 0.2 V of headroom is 2.7 V against a 2.8 V threshold, and even 3.1 V leaves the regulator out of regulation
- Connects the two budgets: the sag deepens as the cell empties, so its useful life ends when the coldest transmission resets the board, possibly long before the rated capacity is used
- Sizes a buffer capacitor from charge and allowed droop — about a millifarad bridges the 5 ms dip, about 12.5 mF would carry a whole burst alone — and counts its leakage against the 10 µA sleep budget
- Treats lowering the brown-out level as a check against every part on the rail, not a fix
- Would settle the life claim with part-drained cells in a climate chamber rather than by division
Follow-up questions
- What does one report cost, in charge?
- Over a day, which costs more: the reports or the heartbeats?
- Seven years on paper. What would you let the box say?
- At −20 °C, what does the regulator give the microcontroller at the start of a transmission?
- Why not set the brown-out level lower?
Closing
That's the device. What would you like to ask about ours — how logs get back from the field, how long an update takes to reach every unit, what our last field failure was and how we found it?
What this line is for
Purpose
Not scored. The close is for the candidate to find out what they would be walking into; anything notable goes in the notes.
And one true thing before you go: [name a current, specific weakness in your own firmware or fleet — a watchdog refreshed from somewhere that proves nothing, a field failure nobody has reproduced, a battery-life figure on the box nobody has re-measured since launch]. That would be yours to fix.
What this line is for
Purpose
A specific, true, unflattering fact about your own devices shows the candidate that this round described the job, and tells one who wanted a finished product that it is not. Check it is still true before you say it.
Embedded Systems Engineer interviews — common questions
- Who is this Embedded Systems Engineer interview plan for?
- It is written for the interviewer, not the candidate: the hiring manager, engineer or panel member running the Technical Interview round for a Embedded Systems Engineer role. It gives you a 60 min script to follow in the conversation — 3 questions with what each one is for and the signals to score against — so you are not writing the round from scratch the night before.
- What does the Technical Interview round assess?
- This round is focused on: Interrupt and DMA concurrency, field-failure debugging and power budgeting, on one battery-powered vibration sensor: corrupted readings from its data path, units that hang after a brown-out, and a cell that must last five years. It works through A reading the pump didn't make, Silent until someone pulls the cell and Five years on the box, scoring against 30 observable signals, with follow-up prompts on all 3 questions for going deeper where an answer is thin.
- How is the 60 min split up?
- 60 min on 3 questions. The questions take in A reading the pump didn't make (22 min), Silent until someone pulls the cell (18 min) and Five years on the box (20 min). The timings are there so the round stays on schedule and every candidate gets the same shape of interview — which is what makes two candidates comparable afterwards.
- What other rounds should I run for a Embedded Systems Engineer?
A single round does not cover a whole role. The other rounds in this library for a Embedded Systems Engineer:
Hiring for this role?
Open this plan in Hirezen and make it a position in one click.
- Every interviewer runs the same script and marks the same signals.
- AI drafts the write-ups, and the debrief puts every read side by side.
- No ATS to set up first, and no bot in the call.
Free for your first open role.