Six question sets for employers hiring firmware talent without an HR department or a CTO: core screening, memory and timing, board bring-up, field updates and certification, hardware collaboration, and a weighted scorecard. Every question states why it is worth asking and what a strong answer sounds like. Download as DOCX.
The first embedded engineer I ever helped a client interview was chosen because he answered a language question better than anyone else in the room. Nine months later the product had shipped, an update had gone out over the air, and roughly forty units in the field would no longer start. Nobody had asked him a single question about what happens when power is lost halfway through writing a firmware image.
That is the pattern with this role. The standard question lists cover C trivia and operating system definitions, which are the easiest things to grade and the least predictive things to ask. The expensive failures live somewhere else: bring-up method, timing under load, and the consequences of shipping code onto hardware you cannot reach anymore.
At FirstHR, we build for owners and managers who make this hire themselves, usually without an HR department and almost always without anyone in the building who can read the firmware. These six sets cover screening, constraints, debugging, field reliability, collaboration, and a weighted scorecard, with every question stating why it is worth asking and what a strong answer sounds like.
TL;DR
Interview an embedded software engineer on five things: a product they shipped firmware for, how they handle memory and timing constraints, how they bring up a dead board, how they deliver and recover field updates, and how they collaborate and hand over. The fastest authenticity check is asking which microcontroller and toolchain their last product used. Benchmark pay against software developers, national median $135,980 (BLS OEWS, May 2025), since no separate occupation exists. Download six sets and a weighted scorecard as DOCX.
What to Assess in an Embedded Software Engineer
Assess five things: whether they have shipped firmware on a real product, how they reason about memory and timing, how they debug a physical thing that will not cooperate, how they handle the consequences of code that ships onto hardware, and whether they can work with an electrical engineer and leave a buildable project behind. Everything else is a detail of one of those five.
Notice what is missing. Definitions of what an interrupt is, recall of a specific register, and puzzles with one clever trick predict very little about whether someone will get your product out the door. They persist on question lists because they are easy to grade, not because they work.
Shipping signals
Names a product with units in the field
Recalls silicon and toolchain instantly
Knows whether the code still runs today
Method signals
Bring-up in a deliberate order
Measures before optimizing
Reproduces a fault before fixing it
Consequence signals
Designs the recovery path first
Ties firmware versions to serial numbers
Owns a field failure they caused
Red flags
Only evaluation boards, never a product
Every bug was somebody else’s hardware
Cannot explain a decision in plain language
The most useful thing you can do in any of those areas is follow up until the answer becomes specific. Which part, how many units, what failed first, how did you prove it. Strong candidates get sharper under that pressure and weaker ones retreat into generalities, which is a difference a non-technical interviewer can see clearly.
Match the Questions to Your Product
Weight the sets by what your device has to survive, because embedded is not one job. A battery-powered consumer sensor and an industrial controller share a title and share almost none of the failure modes that should shape your interview. Decide which column below is yours before you pick questions.
Product type
What the firmware must survive
Extra question worth asking
Consumer connected device
Field updates at scale, power loss, unreliable networks, battery life
How would you stage a firmware rollout so a bad image does not reach everyone?
Industrial control
Years without a restart, electrical noise, safety interlocks, hard deadlines
How do you design for a device that must run for three years untouched?
What did the documentation burden actually look like on your regulated project?
Automotive or motion
Functional safety process, deterministic timing, bus protocols, temperature
Which functional safety process have you worked inside, and what changed day to day?
Defense or aerospace
Authorization controls, long lifecycles, part obsolescence, qualification
How did you handle a component going end of life on a product with a long service life?
If your product falls in a regulated category, ask the extra question early rather than late. Candidates with genuine regulated experience describe the documentation burden honestly and without complaint, while candidates who have only heard about it either dismiss it as paperwork or become noticeably vague.
The Six Question Sets
Use core screening with every candidate and choose the rest based on what the engineer will actually own. For a first firmware hire who will hold the repository, the build, and the signing keys, the field and handover sets matter more than anything else on this page.
Core Screening
Every candidate
What shipped, on what silicon, and which part was theirs. Includes the fastest authenticity check there is for this role. Start here.
Memory and Timing
The constraint set
Bare metal versus an RTOS, interrupts and shared state, running out of flash, watchdogs, and proving a deadline was met rather than assuming it.
Bring-Up and Debugging
Where the week goes
A dead board, the instruments they actually use, faults that vanish under a debugger, and one failing unit in two hundred.
Field and Certification
The set most lists skip
Updates that cannot be rolled back in a minute, bricked units, version traceability, end-of-life parts, and who holds the signing keys.
Hardware Team and Handover
The cross-discipline job
Working while blocked on a board spin, disagreeing with an electrical engineer, delivering bad schedule news, and leaving a buildable project behind.
Scorecard and Red Flags
Score, do not guess
A weighted 1-to-5 rubric with space for written evidence, a level check to run before the offer, and the red-flag list.
Which Sets to Use for Which Hire
First firmware hire who will own the whole stack: screening, field and certification, bring-up, and handover. Adding to an existing firmware team: screening, memory and timing, and bring-up. A contractor for a defined deliverable: screening, bring-up, and the handover questions, scored strictly. A junior hire with a mentor available: screening and memory and timing only, scored against a junior expectation. Use the scorecard with every combination, and match the result against the level you posted in your embedded software engineer job description. Applicant tracking is coming soon to FirstHR.
6 Free Question Sets to Download
Download all six as a single Word document, or copy the individual sets you need. Each follows the same structure: why the set exists, the questions with a stated reason for asking and what a strong answer sounds like, what to listen for, and space for notes. Fill in the blanks and use them as they are.
Download All 6 Embedded Question Sets
Core screening, memory and timing, board bring-up, field updates and certification, hardware collaboration, and a weighted scorecard with red flags. All in one DOCX.
Set 1: Core Embedded Screening
The opening set for every candidate at every level: what shipped, on what silicon, which part was theirs, and whether it is still running. Includes the fastest authenticity check available for this role.
Ask this set of every embedded candidate at every level. It separates people who
have shipped firmware on a physical product from people who have written code
for a development board and a simulator. That distinction predicts more than any
other single thing you can learn in an hour, and it does not require you to read
a line of C to judge.
QUESTIONS TO ASK
1. Tell me about a product you wrote firmware for that actually shipped. Roughly
how many units are in customers’ hands?
Why ask: shipping is the whole job. A prototype forgives everything that
production punishes.
Strong answer: names the product, a unit count or an order of magnitude, and
what the firmware was responsible for. Says plainly if it never shipped.
2. What microcontroller family, compiler, and toolchain did that product use?
Why ask: anyone who did the work remembers the silicon. It is the fastest
authenticity check available.
Strong answer: names a part family, a compiler, a debugger, and how the build
was produced. Answers in seconds, not after a pause.
3. On that product, what did you personally write, and what did someone else write?
Why ask: resumes describe teams. You are hiring one person.
Strong answer: draws a clear line without embarrassment and credits colleagues
by specific contribution.
4. Did you take a board from first power-on to a working product? Which parts of
that did you do yourself?
Why ask: bring-up is where firmware and hardware skill actually meet.
Strong answer: describes an ordered sequence and names what failed first.
5. What is the hardest bug you have chased that turned out to be hardware rather
than software?
Why ask: an embedded engineer who has never suspected the board has not worked
on real hardware for long.
Strong answer: a specific mechanism (a floating pin, a marginal supply, a
noisy bus) and how they proved it rather than guessed it.
6. How much of your work is C, and when do you reach for something else?
Why ask: reveals whether they have a considered position or a habit.
Strong answer: C for the constrained target, with a reason for each exception,
and no claim of deep expertise in six languages at once.
7. Is any of your firmware still running in the field today? How would you know
if it stopped working?
Why ask: ownership after ship is the difference between a builder and a
contractor who left.
Strong answer: names logs, telemetry, return rates, or support tickets. Admits
plainly when there was no visibility at all.
WHAT TO LISTEN FOR
•A shipped product, not only prototypes and evaluation kits
•Instant recall of silicon, toolchain, and debugger
•A clear line between their work and the team’s work
•Curiosity about the failure rather than blame for the hardware team
NOTES
__
__
Set 2: Memory, Timing, and Concurrency
The set that separates embedded work from every other kind of software: bare metal against an RTOS, interrupts and shared state, running out of flash, watchdogs, and proving a deadline was met.
Memory, Timing, and Concurrency Questions
FIRMWARE CRAFT: MEMORY, TIMING, AND CONCURRENCY
Candidate: __
Target platform: __
Interviewer: __
WHY THIS SET EXISTS
This is the set that distinguishes embedded work from every other kind of
software. The target has a fixed amount of RAM, a deadline measured in
microseconds, and an interrupt that can fire in the middle of anything. General
software questions never reach any of it. You do not need to grade the technical
content yourself: grade whether the candidate takes a position and defends it.
QUESTIONS TO ASK
1. How do you decide between bare metal, a real-time operating system, and
embedded Linux for a new product?
Why ask: it is the first architectural decision and the one you live with.
Strong answer: ties the choice to timing requirements, memory, connectivity,
certification burden, and team size. Starts from the requirement, not a
favorite tool.
2. Walk me through what happens between reset and the first line of your
application code.
Why ask: a candidate who has genuinely debugged a dead board knows this cold.
Strong answer: vector table, clock and power setup, memory initialization,
then the application. Mentions why it matters when things go wrong early.
3. How do you share data between an interrupt handler and the main loop?
Why ask: the single most common source of bugs that appear once a month in the
field and never on a desk.
Strong answer: names a specific mechanism and its cost, and can explain what
goes wrong without it. Any real position beats a vague one.
4. Tell me about a time you ran out of flash or RAM. What did you actually do?
Why ask: constraint is the job. This is where invention shows up.
Strong answer: measured first, then made a specific tradeoff, and knew what it
cost. Weak answers jump straight to a bigger part.
5. How do you use a watchdog timer, and what do you want to happen before it
fires?
Why ask: reveals whether they design for failure or hope for the best.
Strong answer: treats a watchdog reset as a defect to investigate, not a
feature, and captures state before the reset.
6. Describe a hard real-time deadline you had to meet. How did you prove you met
it rather than assume it?
Why ask: measurement discipline is the whole difference in timing work.
Strong answer: an actual measurement method, worst case rather than average,
and a margin they were comfortable with.
7. What is your position on dynamic memory allocation on a constrained target?
Why ask: there is no universally right answer, which makes it a good test of
reasoning.
Strong answer: explains the risk, names when they would accept it, and ties
the decision to how long the device runs between restarts.
8. What does your build produce, and how do you know which exact binary is on a
given unit in the field?
Why ask: reproducible builds and version traceability matter enormously when a
customer reports a fault.
Strong answer: version strings in the image, a build identifier, and a record
tying serial numbers to firmware versions.
WHAT TO LISTEN FOR
•Positions with reasons attached, not rules recited
•Measurement before optimization
•Designing for the failure case, not only the happy path
•Awareness that a device may run for years without a restart
NOTES
__
Still Using Spreadsheets for Onboarding?
Automate documents, training assignments, task management, and track onboarding progress in real time.
Method rather than knowledge: a dead prototype, the instruments they actually use, faults that vanish under a debugger, and one failing unit out of two hundred.
Board Bring-Up and Hardware Debugging Questions
BOARD BRING-UP AND HARDWARE DEBUGGING QUESTIONS
Candidate: __
Interviewer: __
WHY THIS SET EXISTS
Most interview question lists for this role stop at language trivia. The work
that actually consumes an embedded engineer’s week is finding out why a physical
thing is not doing what the code says. This set tests method rather than
knowledge, and method is visible to a non-technical interviewer.
QUESTIONS TO ASK
1. The first prototype boards arrive and nothing runs. Walk me through your
first two hours.
Why ask: bring-up order is a real skill and it is learned only by doing it.
Strong answer: a deliberate sequence, power rails first, then clocks, then
reset, then a single blinking output, then interfaces. Not random probing.
2. Which instruments do you reach for, and what does each one tell you?
Why ask: separates people who own an oscilloscope from people who have seen
one in a photograph.
Strong answer: scope for analog behavior and timing, logic analyzer for
protocol, debug probe for stepping, meter for power. Says what each cannot
show.
3. Tell me about a bug that disappeared as soon as you attached the debugger.
Why ask: timing-dependent faults are the signature problem of this field.
Strong answer: recognizes that observing changed the timing, and describes a
less invasive way they eventually caught it.
4. How do you chase a fault that appears on one unit in two hundred?
Why ask: field failure rates are where small hardware businesses lose money.
Strong answer: gathers the failing units, looks for what differs, suspects
marginal timing, temperature, or supply, and reproduces before fixing.
5. Tell me about a time the schematic and the firmware disagreed. How did it end?
Why ask: cross-discipline conflict is constant and how they handle it matters
more than who was right.
Strong answer: evidence, a measurement, and a conversation. Not a complaint
about the hardware team.
6. You get a part you have never used and a datasheet of four hundred pages.
What do you read first?
Why ask: self-sufficiency with primary documentation is the core daily habit.
Strong answer: electrical limits, pin functions, the register map for the
feature they need, and errata. Mentions errata without prompting.
7. What do you build into firmware specifically so that you can debug it later?
Why ask: a device in a customer’s hands cannot be probed.
Strong answer: logging, fault capture on reset, counters, a serial console, or
a diagnostic mode, plus how they keep it out of production behavior.
WHAT TO LISTEN FOR
•An ordered method rather than a list of tools
•Reproduce, then fix, in that order
•Instruments used regularly and understood, not named
•Firmware designed to explain itself after it ships
NOTES
__
Set 4: Field Updates, Reliability, and Certification
The set most question lists omit and the one that decides whether a firmware defect is a bug report or a recall: updates, bricking, version traceability, end-of-life parts, and signing keys.
Field Updates, Reliability, and Certification Questions
FIELD UPDATES, RELIABILITY, AND CERTIFICATION QUESTIONS
Candidate: __
Product category: __
Interviewer: __
WHY THIS SET EXISTS
Software you host can be rolled back in a minute. Firmware on a device in a
customer’s house cannot. This set covers the consequences of that difference:
updates, bricking, versions, certification, and parts that stop being
manufactured. For a small hardware business, this is where a bad hire becomes a
recall rather than a bug report.
QUESTIONS TO ASK
1. How have you delivered a firmware update to devices already in the field?
Why ask: the update path is a design decision, not an afterthought, and it is
expensive to add late.
Strong answer: describes the transport, the bootloader, image verification,
and how a unit that fails mid-update still comes back.
2. What happens if power is lost at the worst possible moment during an update?
Why ask: this is the failure that turns a product into scrap.
Strong answer: a dual-image or recovery scheme, or an honest account of a
design where this risk was accepted and why.
3. Have you ever bricked units in the field, or come close? What changed
afterward?
Why ask: everyone with real deployment experience has a story. The absence of
one is the signal.
Strong answer: owns the mistake, describes the recovery, and names the process
change that followed.
4. What compliance or certification has your firmware been part of?
Why ask: certified products change how firmware is written, tested, and
documented, and the cost is significant.
Strong answer: names the actual regime for their industry and describes the
documentation burden honestly rather than dismissing it.
5. How do you keep track of which firmware version is on which serial number?
Why ask: without this, a field fault cannot be diagnosed or bounded.
Strong answer: a record at production, a version readable from the device, and
a way to query the fleet.
6. A component goes end of life and the replacement behaves slightly differently.
What do you do?
Why ask: supply chain change is routine and it lands on firmware.
Strong answer: characterize the difference, isolate it behind a driver layer,
test both variants, and keep a build that supports each.
7. How do you handle secure boot, image signing, and keys? Who holds them?
Why ask: key custody is a business risk, not an engineering detail.
Strong answer: understands that the company holds the keys, and has an opinion
on what happens if they are lost.
WHAT TO LISTEN FOR
•Update and recovery designed in from the start
•A real story about a field failure and what changed
•Version traceability tied to serial numbers
•Keys, certificates, and signing owned by the business
NOTES
__
Companies Using FirstHR Onboard 3x Faster
Join hundreds of small businesses who transformed their new hire experience.
The cross-discipline reality of a small hardware company: working while blocked on a board spin, disagreeing with an electrical engineer, delivering bad schedule news, and leaving a buildable project behind.
Hardware Team, Schedule, and Handover Questions
HARDWARE TEAM, SCHEDULE, AND HANDOVER QUESTIONS
Candidate: __
Interviewer: __
WHY THIS SET EXISTS
At a small hardware company the firmware engineer sits between the electrical
engineer, the mechanical engineer, the contract manufacturer, and the owner. The
schedule is set by board spins nobody controls. This set tests whether the
candidate can work inside that reality and leave something behind that the next
person can build.
QUESTIONS TO ASK
1. The board you need is three weeks away. What do you do with those three weeks?
Why ask: hardware schedules slip constantly and idle firmware engineers are
expensive.
Strong answer: works on the previous revision, builds a simulator or a test
harness, writes the test fixture, or gets documentation and tooling done.
2. Tell me about a technical disagreement with an electrical engineer. How did it
end?
Why ask: this friction is guaranteed and the resolution style is what you are
buying.
Strong answer: brought a measurement, understood the constraint on the other
side, and reached a decision. No hint of a running feud.
3. How do you tell someone non-technical that a date is going to slip?
Why ask: at a small business, that someone is you.
Strong answer: early, with the reason, with options, and with a revised date
they can plan around. Not on the deadline itself.
4. What do you leave behind so somebody else can build and flash this product
without you?
Why ask: a firmware build nobody else can reproduce is a business risk.
Strong answer: a documented build, checked-in toolchain versions, a flashing
procedure, and a README written for a stranger.
5. What belongs in a production test fixture, and what do you test by hand?
Why ask: production testing is firmware work that many candidates have never
touched.
Strong answer: separates what must be verified on every unit from what is
verified once per design.
6. Walk me through the last handover you did when you left a project.
Why ask: for a contractor especially, the handover is the deliverable.
Strong answer: source, build instructions, keys, accounts, known issues, and a
live conversation with whoever took over.
7. What is your experience working with a contract manufacturer during a
production ramp?
Why ask: firmware questions arrive from the factory floor at inconvenient
hours.
Strong answer: describes test fixtures, programming at production, yield
issues, and responsiveness during the ramp.
WHAT TO LISTEN FOR
•Useful work while blocked on hardware
•Disagreement resolved with evidence rather than seniority
•Bad news delivered early and with options
•A handover that a stranger could actually use
NOTES
__
Set 6: Scorecard and Red Flags
A weighted 1-to-5 rubric with space for written evidence, a level check to run before the offer, and a red-flag checklist. Use it with every set above and for every candidate.
Embedded Interview Scorecard and Red Flags
EMBEDDED SOFTWARE ENGINEER INTERVIEW SCORECARD
Candidate: __
Role and level: __
Interviewer: __
Interview date: _
HOW TO USE THIS
Set the weights before you meet anyone, so the areas that matter for this
specific product are decided by the job rather than by whichever answer
impressed you most. Score immediately after each interview. Every rating needs a
sentence of written evidence quoting something the candidate actually said. If
more than one person interviews, each scores independently before the group
If these do not match, resolve it now rather than after the paperwork. Scope of
past ownership sets the level, not years of experience and not the title on the
resume.
RED FLAGS
[ ] Only evaluation boards and simulators, never a product that shipped
[ ] Cannot name the microcontroller family or toolchain from the last project
[ ] Every bug in their history was somebody else’s hardware
[ ] No position at all on interrupts and shared state
[ ] Has never used an oscilloscope or a logic analyzer in anger
[ ] Treats field updates as solved, with no recovery or rollback story
[ ] Will not discuss source handover, build reproducibility, or key custody
[ ] Answers only in "we", and gets vaguer rather than sharper under follow-up
[ ] Dismisses documentation, test fixtures, and certification as overhead
DECISION
Recommendation: [ ] Strong yes [ ] Yes [ ] No [ ] Strong no
Biggest strength: _____
Biggest concern: ______
What would resolve the concern: _____
Interviewer signature:
What a Strong Answer Sounds Like
Strong answers share a shape whatever the topic: they are specific, they describe a sequence or a tradeoff, and they admit something. Weak answers stay abstract, present every past decision as obviously correct, and contain no mistakes at all. You can recognize that pattern without reading a line of code.
The first prototype boards arrive and nothing runs. Walk me through your first two hours.
Strong answer: Gives an order and explains why it is that order: confirm the supply rails with a meter, check the clock on a scope, verify reset behavior, get one output toggling, then bring up the interfaces one at a time. Mentions what they would suspect if the very first step failed. You can score this without any electronics knowledge, because you are grading whether a sequence exists.
Weak answer: Jumps straight to the code, or describes probing points at random until something looks wrong. A candidate who has bring-up experience never answers this question in a single sentence.
Have you ever bricked units in the field, or come close? What changed afterward?
Strong answer: Has a story, tells it without being asked twice, names their own part in it, and describes the concrete change that followed: a recovery image, a staged rollout, a signature check, a manual verification step at the factory. The willingness to tell the story at all is most of the signal here.
Weak answer: Claims it has never happened across years of shipping products, or blames the customer, the network, or the contract manufacturer while describing no change to their own process.
What do you leave behind so somebody else can build and flash this product without you?
Strong answer: Describes a documented build with pinned toolchain versions, a flashing procedure a technician can follow, known issues written down, and where the keys and accounts live. Treats the handover as part of the work rather than a favor. This is the highest-value question you can ask a contractor.
Weak answer: Assumes it is obvious, promises to write it up later, or treats the build environment on their own laptop as good enough. That answer is how a small business ends up unable to ship a fix.
None of those three requires electronics knowledge to grade, which is deliberate. That constraint is the one most technical interview advice quietly ignores, and it is the binding constraint for nearly every small business hiring firmware.
First Firmware Hire vs Adding to a Team
Hiring your first embedded engineer and adding a third to an existing firmware team are different jobs sharing a title. The first hire sets conventions nobody will revisit for years, owns the only working build environment, and becomes the single person who can ship a fix to a product already in customers’ hands.
What decides the hire
First firmware hire
Joining an existing team
Field update and recovery design
Build reproducibility and handover discipline
Production test fixtures and factory support
Code review habits and shared conventions
Ramping inside an existing codebase
Bring-up and hardware debugging method
A false value above does not mean the trait is irrelevant, only that it is not what decides the hire. For a first firmware engineer, the question that matters most is what happens the day they leave, which is why handover, build reproducibility, and key custody belong in the interview rather than in the exit conversation. The route you use to find candidates shapes your pipeline more than any single question does, and if you are still weighing a contract engagement, the employee versus contractor distinction changes both the cost and the ownership terms you need in writing.
Work Samples for Firmware Candidates
A short, paid work sample that resembles your real work predicts performance better than a puzzle, and firmware gives you unusually good options. Ask a candidate to review a small driver and find the defect that only appears under interrupt load, or to read a bring-up log and say what they would check next and why.
Keep it to two or three hours with a hard cap, publish the criteria you will score against, and give every candidate the same brief. Pay for the time, and never require candidates to supply their own hardware, because that screens on equipment rather than skill. Federal guidance treats any test used to make employment decisions as something that should be job-related and consistent with business necessity, which is one more reason to keep the task close to the actual work.
The Debrief Matters More Than the Submission
Score the conversation about the work sample, not only the artifact. Ask what they would do with two more days, what they deliberately left out and why, what they would want to measure on real hardware before trusting the fix, and what they would need from you to make the same decision better. A candidate who submits a mediocre patch and debriefs brilliantly is usually a better hire than the reverse, because you are buying judgment across a product lifecycle, not one afternoon of output.
Export-Controlled Work and Citizenship Questions
If your product touches export-controlled technology, determine the specific authorization the role genuinely requires before you write the posting, and apply that requirement consistently to every applicant. Do not reach for a blanket citizens-only rule, which is the most common and most costly mistake small employers make in this corner of embedded hiring.
Export rules can legitimately restrict who may access certain technical data. The problem is that restrictions broader than the regulation requires can violate the anti-discrimination provision of the Immigration and Nationality Act, enforced by the Department of Justice through its Immigrant and Employee Rights Section. Firmware roles hit this more often than most, because defense, aerospace, satellite, and dual-use products are ordinary employers of embedded engineers.
Ask About Authorization, Not About Origin
The safe question is whether the candidate is legally authorized to work in the United States and can meet any authorization the role specifically requires. The unsafe questions are the conversational ones: where are you originally from, what is your citizenship status, are you a permanent resident. Those drift toward national origin and citizenship status, they are the questions an accent tends to prompt, and they are rarely necessary to answer the business question. Determine the real requirement with counsel, write it into the posting, and ask every candidate the identical question. This is general information, not legal advice.
Scoring an Embedded Interview
Score immediately after each interview while the evidence is fresh, and anchor every rating to something the candidate actually said. Set the weights before you meet anyone, so the areas that matter for your product are decided by the job rather than by whichever answer impressed you most on the day.
Scoring area
Suggested weight
What a 5 looks like
Shipped hardware ownership
25%
Named product with units in the field; clear about their own contribution
Memory, timing, and concurrency
20%
Positions with reasons attached; measures before optimizing
Bring-up and debugging method
20%
An ordered sequence; reproduces before fixing; uses instruments regularly
Field reliability and updates
20%
Recovery designed in; versions tied to serial numbers; owns a past failure
Collaboration and handover
15%
Explains firmware plainly; leaves a build a stranger can run
If more than one person interviews, each scores independently before the group talks, so the most technical voice in the room does not anchor everyone else. Compare written evidence first and discuss the gaps second. The same questions and the same rubric for every candidate is the whole of a structured interview, and those scores feed a clean interview feedback step before you decide.
Run one more check before any offer goes out: compare the level the candidate demonstrated against the level you posted. If they do not match, resolve it now rather than after the paperwork, using a consistent evaluation form across everyone you spoke to.
What an Embedded Software Engineer Costs
There is no federal occupation code for embedded software engineers, so benchmark against the nearest classifications rather than hunting for a number that does not exist. Software developers is the closest match, with computer hardware engineers and electronics engineers bracketing the hardware-adjacent end of the range.
Nearest Classifications, National Medians (BLS OEWS, May 2025)
According to the Bureau of Labor Statistics Occupational Employment and Wage Statistics survey (May 2025), software developers earned a national median annual wage of $135,980, with the 25th percentile at $105,210, the 75th at $171,980, and the 90th at $214,670. In the same survey, computer hardware engineers reported a median of $161,740 and electronics engineers except computer $130,220 (U.S. Bureau of Labor Statistics, OEWS national estimates).
Embedded roles usually track the software developer band, with a premium for safety-critical, medical, automotive, and defense work where the candidate pool is thin and the certification experience is scarce. Adjust to your metro rather than using the national median, and publish a good-faith range where pay transparency laws apply. A posting with no range reads to an experienced firmware engineer as a posting that intends to negotiate downward.
Fair, Legal, and Structured Interviewing
A fair interview, a legal interview, and an effective interview are the same interview. Asking the same job-related questions of every candidate keeps you compliant, reduces bias, and produces better hires at the same time. Embedded interviews have a few specific traps worth naming before you sit down.
Ask about the job, not the person
Federal anti-discrimination law prohibits basing hiring decisions on protected characteristics, and questions that touch them create risk even when they are meant as friendly conversation. Avoid age, race, religion, national origin, sex, pregnancy or family plans, disability, and genetic information. Embedded interviews have their own version of the trap: asking when someone first learned assembly as a proxy for age, asking where a candidate is originally from because the role touches export-controlled work, or probing family commitments because the factory ramp runs on weekends. Ask instead whether the candidate can perform the essential functions of the role and whether they are authorized to work. This is general information, not legal advice.
Same questions, same order, every candidate
Structured interviewing is the highest-leverage habit available to a small employer. Write the questions before you meet anyone, ask the same core set of every candidate at the same level, and score against the same rubric. It predicts on-the-job performance far better than a conversation that follows rapport, and it makes bias harder to act on because you compare written evidence instead of impressions. It also protects you: a consistent, job-related process is far easier to explain later than a series of one-off technical chats. The sets on this page are built to be used exactly this way.
Treat a firmware exercise as a selection procedure
A take-home task, a live debugging exercise, or an automated screen is a selection procedure, and federal guidance treats any test used to make employment decisions as something that should be job-related and consistent with business necessity. In practice that means the task should look like the work: read a short driver and find the concurrency defect, or review a bring-up log and say what you would check next. Give every candidate the same brief, the same time cap, and the same stated scoring criteria. Pay for anything that takes meaningful time, and never require candidates to supply their own hardware. This is general information, not legal advice.
Decide the level before you interview
Write down what junior, mid-level, and senior mean at your company, and what the role must accomplish in its first ninety days, before you speak to a single candidate. Embedded titles are unusually noisy: the same words cover someone who writes application code on a Linux board and someone who brings up custom silicon. Without a written definition, interviews drift toward whoever is most impressive in conversation rather than whoever fits the product, and the pay conversation becomes a negotiation you have not prepared for. A written level definition also makes the interview fairer, because every candidate is measured against the same standard.
Structure Is Both the Fairer and the More Effective Choice
A structured interview, where every candidate answers the same questions scored against a consistent rubric, predicts on-the-job performance more reliably than an unstructured conversation. Asking the same job-related questions of everyone also keeps you inside the EEOC rules against basing decisions on protected characteristics, and it gives you written evidence to compare rather than a memory of who seemed impressive.
Keep every question tied to the job, and skip the small talk that drifts toward age, origin, or family commitments. The questions employers cannot ask are worth reading once before you interview, because most violations are accidental rapport rather than intent. This is general information, not legal advice.
Interviewing a Firmware Engineer Without HR
A large company runs an embedded candidate through coordinated panels with a recruiter managing scorecards and a hiring committee calibrating levels. A small hardware business runs the founder, alone, between a board revision and a customer call, usually with nobody available who can read firmware. That reality changes what a good process looks like.
Nobody in the building can read the firmware you are hiring someone to write
This is the normal case at a small hardware company, and it is why generic advice to run a technical screen is useless: it assumes a technical interviewer you do not have. You do not need one to interview well. Every question in these sets is answerable in plain language, and every one states what a strong answer sounds like, so you are grading method, specificity, and honesty rather than syntax. Ask the candidate to explain a past product to you as though you were a customer. An engineer who cannot make firmware legible to a non-engineer will be expensive to work with no matter how good the code is. If you want a technical read on top of that, pay a trusted senior embedded engineer for two hours to sit in on one interview and review one work sample. That costs less than a single bad month.
One person will hold the source, the build, and the signing keys
At a company with a firmware team, no single person is a point of failure. At a small hardware business the first embedded hire usually is: they own the repository, the only working build environment, the programming fixture, and often the keys that sign production images. Weight handover and traceability heavily in the interview, ask directly about a handover they have actually performed, and settle ownership before the engagement rather than at the end of it. Register repositories, toolchain licenses, and signing infrastructure to the company with you holding administrative access, and put the intellectual property assignment in writing, especially for a contractor. A candidate who resists any of this is telling you something worth hearing.
A firmware mistake becomes a truck roll, not a redeploy
Web software fails and gets rolled back before most customers notice. Firmware fails and somebody drives to a site, or ships a unit back, or the product is scrap. That asymmetry should change how you weight the interview. Spend real time on the field and certification set, because a candidate who has only ever worked before a product shipped will not have considered the update path, the recovery image, or the version record that lets you say which units are affected. Ask what would happen if power failed halfway through an update, and treat a shrug as a serious finding rather than a gap to be trained out later. The cost of getting this wrong is measured in returned hardware.
The interview is the easy part; the offer and the first ninety days decide whether it works
Once you choose someone, the job shifts from evaluating to hiring well: a clear written offer, a confidentiality and intellectual-property agreement signed before the first commit, access provisioned from company-owned accounts, lab and toolchain licenses arranged in advance, and a first task small enough to flash onto real hardware in week one. FirstHR fits that side for a small business: send the offer for e-signature, run the new hire paperwork and onboarding workflow, assign the access and safety tasks, and keep the signed documents and interview records on the employee profile where you can find them a year later. To be clear on scope, FirstHR is an onboarding and HR platform, not a code repository, a build system, or an applicant tracking system, so pair it with those. Applicant tracking is coming soon to FirstHR.
The whole point of a written question set and a rubric is to make one person's interview as rigorous as a hiring committee's without the overhead of one. Browse the rest of the hiring templates if you need the posting, the evaluation form, or the offer to go with it, and the broader software engineer question sets if the role is only partly embedded.
From Interview to Onboarding
The interview is step one. Onboarding a firmware engineer carries extra steps because of the access and the equipment involved: a written offer and a confidentiality agreement signed before the first commit, repository and toolchain licenses provisioned from company-owned accounts, debug hardware and bench access arranged in advance, and the standard new hire paperwork alongside it.
Offer, confidentiality, and IP
Confirm role, level, and pay in writing, and have the engineer sign confidentiality and invention-assignment terms before the first commit lands.
Accounts and licenses on day one
Repository, compiler and toolchain seats, debug probes, lab bench access, and signing infrastructure provisioned from accounts the company owns.
Flash something in week one
Name a small, real first change and get it onto hardware. It tests the entire path from a laptop to a device and surfaces every broken step in your setup.
Define thirty, sixty, ninety
Say what good looks like at each mark and who to ask, so a new engineer builds momentum instead of guessing at priorities between board spins.
Give the new engineer something small and real to flash in the first week. Shipping once beats two weeks of reading, because it tests the entire path from a laptop to a device and surfaces every broken step in your setup while somebody is paid to notice. A structured developer onboarding plan and a clear offer letter handle most of the rest.
FirstHR connects the offer, the confidentiality agreement, e-signatures, the new hire paperwork, and the access and equipment checklist in one place, and stores the signed documents and interview records on the employee profile where you can find them a year later. FirstHR is an onboarding and HR platform, not a code repository, a build system, or an applicant tracking system, so connect those separately. Applicant tracking is coming soon to FirstHR.
Key Takeaways
Assess five things: a product they shipped firmware for, memory and timing reasoning, bring-up and debugging method, field update consequences, and collaboration and handover.
The fastest authenticity check is asking which microcontroller family and toolchain their last product used, because anyone who did the work answers in seconds.
Weight field updates and certification heavily, since a firmware defect becomes a truck roll or a recall rather than a redeploy.
Ask about bring-up as a sequence, not a definition; a non-technical interviewer can grade whether an ordered method exists.
For a first firmware hire, handover, build reproducibility, and key custody belong in the interview rather than in the exit conversation.
Determine the specific authorization an export-controlled role requires instead of posting a blanket citizenship rule.
No federal occupation exists for this title; benchmark against software developers at a national median of $135,980 (BLS OEWS, May 2025).
Frequently Asked Questions
What questions should I ask an embedded software engineer?
Ask about five things: a product they wrote firmware for that actually shipped, how they handle memory and timing constraints, how they bring up a board that does nothing, how they deliver and recover firmware updates in the field, and how they work with an electrical engineer and hand a project over. The single fastest authenticity check is asking which microcontroller family and toolchain their last product used, because anyone who did the work answers in seconds. Follow every answer with a request for specifics: which part, how many units, what failed first, how they proved it. Strong candidates get sharper under that pressure and weaker ones get vaguer, and the difference is usually visible within two follow-ups. The six downloadable sets on this page are organized around exactly those areas.
How do I interview a firmware engineer if I am not technical?
You grade method, specificity, and honesty rather than code. Ask a candidate to walk you through the first two hours with a prototype board that does nothing: a real embedded engineer describes an ordered sequence of checks, while someone without the experience answers in one vague sentence. Ask what they personally wrote versus what a teammate wrote, and whether the product is still running in the field. Ask for a story about a firmware update that went wrong. None of those require you to read C. If you want a technical opinion on top of your own, pay a trusted senior embedded engineer for two hours to sit in on one interview and review one paid work sample. That is far cheaper than a bad hire, and it keeps the hiring decision with you.
What is the difference between an embedded software engineer and a software engineer?
An embedded software engineer writes code that runs on the device itself, under constraints a general software engineer never meets: a fixed and small amount of memory, deadlines measured in microseconds, interrupts that fire mid-operation, and no ability to redeploy in a minute when something breaks. The work also crosses into hardware, so bring-up, oscilloscopes, datasheets, and disagreements with electrical engineers are routine parts of the week. Interview questions differ accordingly. Generic engineering questions about system design and code review still apply, but they miss the areas where this role fails expensively: field updates that cannot be rolled back, version traceability tied to serial numbers, and certification. Ask both, and weight the embedded-specific sets heavily if the person will own a shipping product.
What is a good technical test for an embedded engineer?
A short paid work sample that resembles your real work predicts performance far better than a whiteboard puzzle. Good options include reviewing a small driver and identifying the defect that only appears under interrupt load, reading a bring-up log and saying what they would check next and why, or critiquing a firmware update design and naming what happens if power is lost mid-write. Cap it at two or three hours, publish the criteria you will score against, give every candidate the same brief, and pay for the time. Never require candidates to supply their own hardware, because that screens on equipment rather than skill. Score the debrief conversation as well as the submission: what they would do with two more days and what they deliberately left out tells you more than the artifact does.
How much does an embedded software engineer cost?
The Bureau of Labor Statistics publishes no separate occupation for embedded software engineers, so benchmark against the nearest classifications. According to the Bureau of Labor Statistics Occupational Employment and Wage Statistics survey (May 2025), software developers earned a national median annual wage of $135,980, with the 25th percentile at $105,210 and the 75th percentile at $171,980. Computer hardware engineers had a median of $161,740 and electronics engineers except computer $130,220 in the same survey. Embedded roles usually track software developer benchmarks, with a premium for safety-critical, medical, automotive, and defense work where the candidate pool is thin. Adjust for your metro rather than using the national median, and publish a good-faith range where state pay transparency law requires it.
Can I require US citizenship for an embedded role with export-controlled work?
Usually not in the blunt form employers reach for first. Export control rules can genuinely restrict who may access certain technical data, but the anti-discrimination provision of the Immigration and Nationality Act, enforced by the Department of Justice, prohibits restrictions broader than the law actually requires, and a citizens-only posting is frequently broader. The safer practice is to determine which specific authorization the role truly needs, state that requirement precisely, apply it consistently to every applicant, and confirm the analysis with counsel before the posting goes live. Embedded hiring runs into this more than most, because defense, aerospace, satellite, and dual-use products are ordinary employers of firmware engineers. This is general information, not legal advice.
What are the red flags in an embedded software engineer interview?
The clearest signal is a candidate who has only worked on evaluation boards and simulators, never a product that shipped to customers, because every hard lesson in this field arrives after manufacturing. Others: cannot name the microcontroller family or toolchain from the last project, blames hardware for every bug they have ever seen, has no position at all on sharing data between an interrupt and the main loop, has never used an oscilloscope or logic analyzer, treats field updates as a solved problem with no recovery story, and will not discuss source handover, build reproducibility, or who holds the signing keys. Answering everything as we and getting vaguer rather than sharper under follow-up is the meta-signal that ties most of those together.
Should I hire an embedded contractor or an employee?
It depends on whether the firmware is a one-time deliverable or a product you will maintain for years. A contractor suits a defined scope with a clear end: a bring-up, a driver, a certification push. An employee suits a product that will receive updates, field fixes, and new features indefinitely, because the institutional knowledge of why the firmware works the way it does is expensive to rebuild. If you go the contractor route, weight the handover questions heavily and settle intellectual property, repository ownership, build reproducibility, and key custody in writing before work starts rather than at the end. The worker classification rules are their own subject and getting them wrong carries tax and wage consequences, so treat that as a separate decision from the interview.
