Last updated: October 7, 2026
By Tom Kenaley, President and Senior Partner, KORE1
Good firmware engineer interview questions in 2026 make a candidate bring up a board that has never run code, defend an update path against a power cut, and say who files the vulnerability report. Mutex versus semaphore only sorts out who revised the night before. Shipping hardware is a separate test.
A medical device company in Bothell, Washington, sent us a resume last spring with a note attached that said, roughly, we already interviewed this guy twice and we cannot agree. Twelve years of embedded C. Automotive background. He had answered every question their panel asked, and their panel had asked good questions, the kind you find in a well-written study guide. Volatile qualifiers. Interrupt latency. Stack versus heap.
Then somebody on the second call asked him what he does when a brand new board shows up on his desk and nothing has ever run on it.
He described flashing the application.
That was the whole answer. No clock configuration, no boot mode pins, no checking that the part even comes out of reset at the speed the datasheet promises. He had spent twelve years adding features to platforms other people had already stood up, which is a real job and a useful one, and it was not the job they were hiring for. They needed somebody to take a new infusion pump controller from bare silicon to a blinking LED. Different skill. Nobody had thought to test for it because nobody had thought of it as a question.
Below is what we actually give clients once a firmware engineer staffing search reaches the panel. There are holes in it on purpose. Two other pieces already do that work, and repeating them here would waste your time. Comp bands, sourcing channels, and the bare-metal versus embedded Linux decision that quietly determines which search you are running all live in our guide to hiring firmware engineers. Priority inversion, the interrupt and DMA round, and the rest of the RTOS material belong to the embedded software engineer interview questions guide. Go there for those. What is left is the material almost nobody tests for.
Where my interest sits, so you can discount accordingly. A hire made through KORE1 pays our fee, so I have every incentive to make this sound harder than it is. Take the loop and skip the invoice. Genuinely, that is fine. The version I would like to prevent is the one where a panel signs off on a pleasant conversation and learns the truth in month nine, because in firmware month nine means units are already out there and getting them back costs real money.
Firmware Is the Code That Runs Before Anything Else Works
Firmware is the software that initializes a processor and its peripherals from power-on and keeps a physical product running with no operating system underneath it, or with a small real-time one. It lives in flash, on the thing itself. No dashboard rolls it back. When it is wrong, somebody gets in a car.
That last part is the whole reason this interview is different. A web service that ships a bug rolls back in four minutes. A thermostat that ships a bug in its bootloader is a truck roll to nineteen hundred addresses, and I will come back to that story.
Some market context first. Computer hardware engineering is the occupation federal wage data tracks closest to this work, and its median sits at $161,740 as of May 2025, on about 4,100 openings a year and projected growth of 9 percent over the decade to 2035. Firmware sits next door to that category rather than inside it. In practice the pool reads thinner than the openings figure implies. We have placed embedded talent for more than twenty years, our placements hold at 92 percent through the first twelve months, and we work across upwards of thirty metros. Firmware is still where our searches run longest. Six to twelve weeks is ordinary. All of the comp detail is in the hire guide and I am not re-deriving it here.
Start Where the Part Has Never Run Code
This is the round that separates people who have stood up a platform from people who have inherited one. Both are hireable. You just need to know which you are getting. Most loops never find out.
“A new board lands on your desk. Nothing has ever run on it. Walk me through your first day.”
You are listening for an order of operations, not a list of tools. Strong answers start before any code at all. Check the power rails with a meter. Confirm the part comes out of reset. Verify the boot mode pins are strapped the way the schematic says, because they often are not on a first spin. Then get a debugger attached and halt the core, and only then worry about a clock tree. In that order.
The tell is what they do about the clock. A lot of candidates jump straight to the application and assume the part is running at its rated speed. It is usually running on an internal oscillator at a fraction of that speed, and every timing-dependent thing they write will be wrong until somebody configures the PLL. Somebody who has done this will mention measuring the clock on a pin before trusting it. Few do.
Ask what they use for their first sign of life. The good answer is almost always a GPIO toggle. Not a print statement. The console is not up yet and will not be for a while. People forget that.
“What has to happen between reset and the first line of main?”
This one is unfair to nobody. It is also impossible to fake. Vector table. Stack pointer initialization. Copying initialized data from flash into RAM. Zeroing the bss section. Calling any library init the toolchain expects. Then main.
Candidates who have only worked above a board support package will not know this, and that is diagnostic rather than disqualifying. What I would worry about is a candidate who claims to have done bring-up and still cannot describe it, because the startup file is the first thing you touch when a new part does not boot. Every time.
“Show me how you know how much stack you are using.”
Most people guess. The honest answer is that they fill the stack region with a known pattern at startup, run the worst case they can construct, and then look at how far the pattern got eaten. Some will mention a memory protection unit region at the bottom of the stack to turn an overflow into a fault instead of silent corruption of whatever sits next to it.
Anyone who says the compiler tells them has not been bitten yet. Static analysis gets you a bound on the call graph. Worth having. It still knows nothing about your interrupt nesting depth.
“What is in your linker script and why?”
Ask it plainly and watch for comfort. You are not grading recall of syntax. You want to hear somebody who understands that they decided where things live, that the decision had consequences, and that they have moved something across that boundary on purpose. A buffer into a faster RAM block. A calibration table into a flash sector that survives an update. A function into RAM because it erases the flash it would otherwise be executing from.
That last one is a good follow-up on its own. Why can a flash routine not live in flash? Let them sit with it. If they get there without help, they have written a bootloader.
The Memory Map Round
Short section. One table. The questions only mean something next to what a weak answer sounds like.
Memory on the parts we are talking about is measured in kilobytes. Not gigabytes. Kilobytes. The hire guide makes this point too, and it bears repeating here, because every question below is downstream of it.
| Ask this | Weak answer sounds like | What you want to hear |
|---|---|---|
| How do you allocate memory in production code? | “malloc, but carefully.” | Static allocation, fixed pools sized at build time, no heap in the shipping image, and a reason why. |
| Where does your calibration data live? | “In flash.” | A named sector outside the application region, with a reason it survives a firmware update and a plan for when it does not. |
| Your image grew 2 KB and now it does not fit. What do you cut? | “Optimize for size and hope.” | Read the map file first, find what actually grew, and name the usual culprits by size: floating-point printf, a logging table, an unused driver the linker kept. |
| How much flash do you reserve for the update, and why that much? | “Whatever is left over.” | A number tied to a layout decision, usually half the application space for a second slot, and an honest tradeoff about the part cost that implies. |
That last row is the hinge for the next section. It is also the one question I would keep if I only got one.
Hand Them a Fault Dump, Not a Whiteboard
Give the candidate an artifact and twenty minutes. Not a puzzle. Not a riddle. A thing that actually happened to you.
We suggest two. Either works. The first is a hard fault. Print the register set a debugger would show at the moment of the fault and hand it over on paper, with the stacked program counter, the configurable fault status register, the bus fault address, the stack pointer, and the first dozen words at the top of the stack. Ask them what they would look at first and in what order.
What you are watching for is whether they know the stacked frame holds the address that faulted rather than the address they are sitting at. A lot of people stare at the current program counter. That is the handler. It tells you nothing. Then watch whether they sanity-check the fault address at all, because an obviously garbage pointer and a plausible-but-wrong one lead to different investigations.
The second artifact is a capture. A logic analyzer trace of a bus transaction that is almost right. Clock polarity inverted on a sensor read. An acknowledge that never comes. A chip select that drops a cycle early. Give them the trace and the datasheet page for the part, and let them find the disagreement between the two.
Both exercises take an afternoon to build once, then work for years. Neither is a take-home. The candidate is in the room, or on a call sharing a static image, and you are listening to them think rather than grading a deliverable.
A word on what we do not recommend. We used to suggest handing candidates a block of your own embedded C and asking what they would change. The hire guide still covers that version. It is fine, as far as it goes. We have moved off it for senior roles because the answers converged, and because code review is the one firmware skill a candidate can now rehearse convincingly without ever having touched hardware.
The Update Path Is Where Seniority Actually Shows
Here is the Rockford story I owe you.
An industrial sensor manufacturer in Rockford, Illinois, shipped a firmware update to a fleet of about nineteen hundred wireless gateways. The update worked. It worked on every unit that stayed powered through the write. At the plants that browned out partway through, which was more than a few because these things sit in buildings where large motors start, the device ended up with half of an old image and half of a new one and no way to tell which. There was one application slot. The bootloader verified the image after it had already overwritten the only copy. A field technician visited every one of those sites with a programming cable.
Nobody in that interview loop had asked about power loss. The engineer they hired was good. The question was just never on the list. Nobody wrote it down.
It should be on yours.
“Walk me through a field update, from the server to the device rebooting into the new image.”
Let them talk for a while. Do not prompt. You are looking for an order, and specifically for where verification happens relative to the overwrite. A signature checked before the jump and before the old image is gone. Two slots, so there is something to fall back to. A marker written last, atomically, that says the new image is good, and a bootloader that treats the absence of that marker as a reason to boot the old one.
Then push on the ugly cases. What happens if power drops during the write? During the marker write? Make them answer both. What if the new image boots, passes its self-test, and then bricks itself four hours later under load? The best answer to that last one involves a watchdog-backed confirmation that the application has to actively set, rather than a bootloader that assumes a successful boot means a successful image.
“How do you stop somebody installing an older image on purpose?”
This separates people who have shipped a secure product from people who have shipped a working one. You want to hear about a monotonic version counter stored where the application cannot casually rewrite it, and an acknowledgment that rollback protection and field recovery are in direct tension. Lock it down hard enough and your own support team cannot rescue a unit. That tension is the answer.
Candidates who say “we sign the image” and stop have answered a different question. A signed old image is still a valid signed image. That is the whole trap.
“Our update link is lossy and the device might be unreachable for weeks. Does that change the design?”
Resumable transfers, chunk-level integrity rather than one hash at the end, and a staging area that tolerates an update sitting half-received for days. Somebody with cellular or LoRa experience will bring up the cost of retransmission unprompted, which is a good sign about how they think.
The gap here is wider than you would expect. Nearly 750 embedded developers and architects answered the Eclipse Foundation 2024 IoT and Embedded Developer Survey. Over-the-air updates came back at 32 percent as a security measure in use. Secure boot came back at 19. So a sizeable share of fleets out there will accept a new image and cannot prove the image is theirs.
Security Questions That Have a Deadline Now
Three years ago this round was optional. Not anymore. The reason is a date.
The reporting obligations in Article 14 of the EU Cyber Resilience Act began to apply on 11 September 2026. Once a manufacturer knows an actively exploited vulnerability exists in a product with digital elements, an early warning goes in within 24 hours, a fuller notification within 72 hours, and once a corrective measure is available the final report follows within 14 days. That applies to products already sold, not just ones shipping now. If your device goes to Europe, somebody on your team owns that clock whether they know it or not.
I am not suggesting you quiz a firmware candidate on regulation. I am suggesting you find out whether they have ever been in the room when it mattered.
“Who told you about the last vulnerability in something you shipped, and what happened in the first day?”
Open-ended on purpose. Some candidates will have a real story, with a researcher email and a scramble and an argument about severity. Some will say it has never come up. Fine from a junior. Strange from somebody who has shipped connected products for a decade.
What you are really testing is whether they distinguish a vulnerability from a bug, and whether they have any instinct for who needs to know outside engineering.
“What does secure boot actually verify on your last product, and where is the key?”
Plenty of people can describe a chain of trust in the abstract. Fewer can tell you where the root of trust physically lived on a part they shipped, whether it was in one-time-programmable fuses or a protected flash region, and who at the company could sign a build. One answer you do not want. The signing key sat in the repository.
Follow up with provisioning. Who puts the key on the part, and where does that happen? A candidate who has been through this will mention the factory. Usually somebody else’s factory.
“You locked the debug port on a production unit. Now you need to debug a returned one. What are your options?”
My favorite question in the set. Nothing about it resolves cleanly, and that is the point, because watching somebody sit inside an unresolvable problem tells you plenty. Read-protection on most parts is a one-way door. The honest options are a mass erase that destroys the evidence you were after, an authenticated unlock if the silicon offers one and somebody planned for it a year ago, or a small population of unlocked units that never leaves the building.
Candidates who claim they can just reconnect have not shipped a locked product. Candidates who say “we never locked it” are being honest, and that answer tells you something about the products they have worked on.
“Can you produce a parts list for the firmware image on a device you shipped last year?”
Software bills of materials become a full CRA obligation on 11 December 2027, so this is a forward-looking question rather than a compliance check. What it really probes is build reproducibility. Does a tagged commit plus a documented toolchain version produce the same binary? Do they know every third-party component in the image, including the ones that arrived inside a vendor SDK? Most teams cannot answer this. Not even close. The ones who can tend to have the rest of their build in order too.
On coding standards, keep it light. Genuinely light. If the role is in automotive, medical, or aerospace, ask which standard they worked under and what it actually changed about their day. MISRA C:2025 arrived in March 2025 as an incremental update covering C11, C18, and earlier versions of the language. Somebody who has lived with it will have an opinion about deviations and the paperwork around them. Somebody who has only skimmed it will tell you it makes code safer and stop talking.
Microamps, Not Megahertz
An agricultural sensor company in Eau Claire, Wisconsin, promised eighteen months of battery life on a soil moisture node. Field units came back at about five.
The firmware was correct. Every feature worked. A debug UART had been left enabled in the shipping build, which held a clock domain awake that should have been off, and the part never reached its deepest sleep state. The arithmetic on a coin cell is unforgiving at that scale. Nobody caught it. Nobody had ever measured the thing.
If the product runs on a battery, this round matters more than anything above.
- How do you measure current on a device that sleeps at 2 microamps and wakes to 30 milliamps for 8 milliseconds? A handheld meter cannot do this. You want to hear about a current probe or a dedicated power analyzer, and ideally about averaging over a duty cycle rather than reading an instantaneous number.
- What keeps a part awake that should be asleep? Good answers arrive as a list from experience: a peripheral clock nobody disabled, a pin floating and oscillating, a debug interface, an unserviced wake source that fires immediately.
- What wakes it, and how do you prove that is the only thing that wakes it?
- Tell me about a power number you missed, and by how much. If they have shipped battery products, they have missed one.
The follow-up I like best is simpler than all of those. Ask what the battery life target was on their last product and whether they hit it. Watch the pause. The pause is the answer.
Questions for the Production Line
This round gets skipped almost universally, and then the role turns out to be forty percent manufacturing support.
Ask how firmware got onto the device at the factory. You are listening for whether they have ever thought about it as a process with a yield. A programming fixture, a known-good image, a serial number and a MAC address written per unit, a record of what version went on which board, and a way to tell at the end of the line that it worked.
Then ask what their end-of-line test actually covered. And what it missed that came back from the field later. Anybody who has supported a product in volume has a story here. Usually about a test that passed on a bench and did not represent the line.
One more. Good senior filter. Ask what happens when a part goes end-of-life or a chip shortage forces a second source. The specific thing you want is whether they have read an errata sheet closely enough to have been surprised by one, and whether they treat a pin-compatible substitute as a firmware change rather than a purchasing decision. It is always a firmware change. Always.
How to Sequence the Rounds
You do not need all of this, and you should not run all of it. Four conversations is plenty for most firmware roles.
- First call, half an hour, recruiter or hiring manager. One question. What did you bring up, and what broke first? The answer sorts platform-builders from feature-adders in about four minutes, and it is hard to rehearse.
- Technical conversation, 60 minutes. The bring-up round and the memory map round. No code written. None. This is where you find out whether the resume matches the hands.
- The artifact, 45 minutes. Fault dump or logic capture, candidate talking out loud. For a connected product, swap in the update path walkthrough instead; for a battery product, the power round.
- Team and constraints, 45 minutes. The security round if it applies, the production questions if the role touches manufacturing, and an honest conversation about the parts of the job nobody enjoys.
Do not add a fifth round because somebody on the panel did not get a turn. Firmware candidates are employed, in short supply, and well aware of both. Every extra loop is a window. Somebody else closes in it.
One scheduling note. Not optional. Rounds two and three go badly over a bad connection and better when the candidate can see the hardware, so if you can bring them on site for one visit, make it the one with the artifact in it.
What Candidates Should Be Asking You
The strong ones interview back, and what they ask tells you how they will behave in the job.
Watch for anybody who asks about the state of the hardware. Is the schematic frozen? How many spins have there been? Will I be debugging my software or your board? That is not negativity. That is somebody who has spent three months chasing a firmware bug that was a layout problem and does not intend to do it again.
Questions about the test setup are the second signal. Is there a hardware-in-the-loop rig, or does every change get tested by hand on one board that lives on somebody’s desk? Candidates who ask this have worked somewhere with a rig and somewhere without.
Then there is the one nobody asks until they have been burned. Who decides when it ships? If the answer is a date on a slide rather than an exit criterion, a good candidate hears that clearly.
What Comes Up Once the Req Is Open
“The resume says twelve years of embedded C and not one board bring-up. Is that a dealbreaker?”
No, unless the job is bring-up. Plenty of excellent firmware engineers have spent their careers on established platforms, and that experience is worth a lot on a mature product. Decide which job you have before you reject anybody. If the first six months are a new board from bare silicon, somebody who has never configured a clock tree will learn it slowly and expensively, with your schedule paying for the lesson. If the first six months are features and field support on a platform that already boots, the gap barely matters.
“How much of this can we actually run over a video call?”
Most of it, except the artifact round, which works better in person. The bring-up questions, the update path walkthrough, the security round, and the production questions are all conversation, and they travel fine. The fault dump works on a shared static image if you have to. What does not survive remote is handing somebody actual hardware, so if the role is heavily hands-on and you only get one on-site visit, spend it there rather than on a culture lunch.
“Do we need somebody who has already shipped under IEC 62304 or ISO 26262, or can a strong generalist learn the standard?”
They can learn the standard. What they cannot learn quickly is the habit of working inside one. Close to half the developers in that Eclipse survey said safety certification shapes their work. People who have sat through an audit behave differently. They write the requirement before the code, they expect traceability as a matter of course, and they will not quietly refactor a verified module the week before a submission. Pay a premium for prior regulated experience on a first submission. On a mature product with a working quality system, a strong generalist who respects process will get there.
“Our only firmware engineer leaves in six weeks and documented almost nothing. What do we test for in the replacement?”
Reverse engineering temperament, honestly. Have candidates describe the worst codebase they ever inherited and what they changed in week one. The instinct you want is to get the build reproducible and a debugger attached before touching a single line, not to rewrite the thing in a nicer architecture. Ask outright whether they have stood up a toolchain for an undocumented project, since that is the genuine first task waiting for them. Also spend the six weeks you still have. A recorded walkthrough of the build and the update path beats a document nobody is going to write.
“Who is supposed to answer a 24-hour vulnerability report, and do we interview for that?”
Someone has to, and the firmware engineer is usually in the room even when they do not own the filing. Under the Cyber Resilience Act the obligation sits with the manufacturer, not an individual, so the right answer is a named process rather than a named person. Interview for it indirectly. Ask what happened the last time somebody reported a security problem in something they shipped. You are not hiring a compliance officer. You are checking whether this person has ever had to produce an honest severity assessment under time pressure, which is a different skill from finding the bug.
“We have never shipped a firmware update. Does that change who we should hire?”
It changes it more than almost anything else on your list. Building an update path for a product that has never had one is a specific piece of work with real consequences for getting it wrong, and the Rockford truck roll earlier in this piece is the cheap version of that lesson. Hire somebody who has designed a bootloader, not somebody who has used one. Ask what the second one would look like. And if the product is already out there with no update capability, say so in the interview, because a candidate who has retrofitted one will tell you fast whether your flash layout even permits it.
One Board, One Afternoon
If you take one thing from all of this, take the sequencing. Most firmware loops fail not because the questions were bad but because nobody decided in advance what the job actually was, so the panel defaulted to the questions it already knew how to grade.
Write down the first six months before you write the job posting. New board from bare silicon, or features on a platform that already boots. Battery-powered or wall-powered. Connected and updatable, or sealed for life. Regulated or not. Those four answers pick your rounds for you, and they tell you which of the questions above to drop.
Then put a real board on a real bench for one afternoon of the process. The resume will not tell you what you need to know. An hour with hardware will.
If you want help, that is what we do. Our embedded software recruiters run this loop with clients every week, and we also place C++ developers and embedded systems engineers across the same accounts. Whether the role is a six-month bring-up on contract or a direct hire who will own the platform for years changes the search more than the title does. For comp, the embedded software engineer salary guide has current bands. Our salary benchmark tool narrows them to your stack and metro. When the req is real, start a firmware search with our team and we will say plainly if you are better off doing it without us.
Related reading on adjacent roles: electrical engineer interview questions for the hardware side of the same product, automation engineer interview questions for controls and PLC work, and our engineering staffing agency overview for everything else we cover.
