A firmware lead at a product engineering firm has three interviews booked on a Saturday. The first candidate talks well about an RTOS but cannot say what happens when two interrupts arrive together. The second has shipped a motor controller and speaks slowly. The panel picks the first one, and the project slips by a quarter.
Embedded hiring goes wrong when the round rewards fluency over judgement. This guide sets out a short technical round that tests the work itself, and how to run it without wasting a good candidate's day.
Start with the role, not the title
Embedded engineer covers very different jobs. One person brings up a new board and reads schematics. Another writes drivers against a vendor SDK. A third builds test rigs and automates regression on hardware. Write down which of these your next project needs before you draft a single question.
- Bring-up and board support: reading datasheets, scope and logic analyser habits, boot sequence.
- Driver and middleware work: peripherals, DMA, interrupts, memory limits, build systems.
- Application firmware: state machines, communication stacks, update paths, field logging.
- Test and validation: hardware in the loop, scripting, fault injection, traceability.
A product engineering client may ask for a mix. Even so, name the main skill and the second skill. Panels that skip this step end up testing everything and measuring nothing.
The three parts of a one-hour round
A long take-home test loses good people who already have jobs. A short live round keeps the process fair and quick. Three parts fit into sixty minutes and each shows something different.
- 1
Ten minutes on a real project
Ask the candidate to describe one device they worked on: the processor, the clock and power setup, the interfaces, and their own part. Listen for specifics such as which bus, which fault, which tool.
- 2
Twenty minutes on a debugging story
Ask for the hardest bug they chased. Probe the steps: what they measured, what they ruled out, what they got wrong first. A candidate who has never been wrong has not debugged much.
- 3
Twenty minutes on a small code read
Show forty lines of C with an interrupt handler, a shared buffer and a missing volatile or a race. Ask what could go wrong on the target. Do not ask them to write on a whiteboard.
- 4
Ten minutes for their questions
Good candidates ask about the test setup, the toolchain and who owns the hardware. Note the quality of those questions.
What to ask in the code read
The code read is the part that separates people. Keep it close to your own work. If you ship battery-powered sensors, include a sleep and wake path. If you ship industrial controllers, include a watchdog and a communication timeout.
- What happens if this handler runs while the main loop is halfway through reading the buffer?
- Where would you put a breakpoint, and what would you check on a scope?
- How much stack and RAM does this use, and how would you find out on the target?
- What would you do differently if the part ran at a tenth of the clock speed?
The answers matter less than the way the candidate reasons. Someone who says they would measure it before guessing is showing the habit you need.
What to leave out
Skip algorithm puzzles with no link to hardware. Skip trivia such as the exact register names of one vendor's chip, since datasheets exist. Skip questions that depend on one tool, because a strong engineer can pick up your debugger in a week. Do not ask for a full design document in the round either. That belongs in a later conversation with the engineering manager.
Score it on written lines
Write the scoring lines before the first interview. Give each line a plain description of what a strong, fair and weak answer looks like. Each panel member scores alone first and then the group compares. This keeps a confident speaker from carrying the room.
Role focus: bring-up, driver, application or test (choose one).
Hardware reasoning: reads datasheets, uses instruments, measures before guessing.
Real-time and interrupt judgement: shared data, timing, priority, stack use.
Debugging method: steps taken, mistakes admitted, how the fix was proven.
Communication: explains a fault to a hardware colleague and to a client.
Learning speed: new toolchain, new part, new protocol.
Overall note: one sentence on the main concern.Calibrate the round once with your own team. Ask two current engineers to take the same round as practice and compare scores. If your best firmware engineer scores poorly, the round or the scoring lines need work. This takes an hour and saves many bad decisions.
Handling the candidate who is strong but quiet
Many good firmware people are not natural presenters. Give them the code read on a shared screen so they can think aloud at their own pace. Ask a second question on the same topic if the first answer is short. You are testing engineering, not stage presence.
After the round
Close the loop within a few days. A tracker with the stage date for each candidate prevents the common failure of silence. If you need help with sourcing and structured screening for specialised roles, see our specialised IT recruitment support. For the wider picture of how product engineering firms organise people, the product engineering companies page is a good next read.
Once someone joins, they will need access to boards and rigs. The lab and prototype access rules post covers what to write down before the first day.
