Straight Answers
How Do You Vet an Embedded Firmware Engineer?
Vet an embedded firmware engineer on shipped hardware, not keywords. Ask them to walk through bringing up a new board, explain a bug that only appeared on real hardware, and describe how their update path survives a power cut. Then have them review a real driver or interrupt handler from your codebase. Specific, physical answers point to experience; vague talk about frameworks usually doesn't.
Questions that separate experience from a résumé
- Walk me through bringing up a new board. Strong answers start before flashing: current-limited supply, rails and clocks checked, debug probe connected, then a heartbeat LED or UART log before any peripheral.
- Tell me about a bug that only showed up on real hardware. Listen for specifics: a stack overflow, an interrupt race, DMA and cache coherency, brown-out resets, a silicon erratum.
- How do you share data between an interrupt and the rest of the code? 'Make it volatile' alone is incomplete; look for critical sections, atomic access, or queues and ring buffers.
- If power drops halfway through a firmware update, what happens? Look for image verification, a bootloader with a fallback image, and rollback.
- What do you do when the datasheet and the hardware disagree? Good engineers check the errata sheet and the silicon revision, then measure.
A practical test worth an hour
- Code review beats a coding puzzle: hand over a real, sanitized driver or interrupt handler and ask what they would change and why.
- Have them read one schematic page: which peripheral drives which pin, where the pull-ups are, what the boot pins do.
- Show a logic-analyzer capture of a failing I2C or SPI transaction and ask what's wrong.
- If you use a take-home, keep it small and paid, such as a ring buffer with unit tests, and judge the boundary cases rather than cleverness.
Red flags
- Can't name the microcontroller families, toolchains and debug probes they used on shipped products.
- Debugs only with print statements and has never used a scope, logic analyzer or hardware debugger.
- Every past failure was the hardware team's fault.
- No version-control or written-design habits: the code worked, but nobody else could build or change it.
- For regulated products, no familiarity with IEC 62304 or design controls when the role needs them.
Signs of a senior engineer
- Talks in budgets: RAM, flash, power, interrupt latency and timing margin.
- Asks about production programming, factory test and the field update path before writing code.
- Keeps vendor HAL code behind clean interfaces so application logic can be tested off-target.
- Writes down the bring-up notes and pin map so the next engineer doesn't start from zero.
Common questions
Ask about board bring-up, a hardware-only bug they fixed, sharing data between interrupts and tasks, update safety when power fails, and how they handle datasheet errata. Then ask them to review a short piece of your real code. Their follow-up questions tell you as much as their answers.