All jobs / Embedded / hardware
Firmware Architecture interview questions
Firmware Architecture questions a Embedded / hardware can be asked, from first job to senior. Open one to see the strongest answer and why it works.
You wait for a bit in a `while (1)` with no timeout. What is wrong?
The strongest answer: A silent forever if the bit never arrives — I want a timeout, a counter, and a path to a safe state
Why it works: Exactly. Hardware can miss. A kicked watchdog around a dead wait hides the bug.
- Timeout every hardware wait.
- Safe state on expiry.
- Do not kick the dog in the spin.
- Optimisation level ≠ a timeout.
When is `delay_ms(100)` acceptable, and when is it a smell?
The strongest answer: Acceptable in bring-up or a one-shot wait you measured — a smell when it is how you “schedule” five features
Why it works: Exactly. Measured waits vs a fake RTOS made of sleeps. ISR delays are a hard no.
- OK for measured bring-up waits.
- Not a scheduler.
- No delay in an ISR.
- Do not stack sleeps as architecture.
Describe how a super-loop firmware should be structured.
The strongest answer: Interrupts do the urgent minimum and leave a flag or a buffered item behind; the main loop walks a set of small state machines that each run to completion quickly and never block
Why it works: Right — the whole contract is short, non-blocking passes. Break it once and every other job’s latency becomes unpredictable.
- Short, non-blocking passes; tiny ISRs.
- The ISR sets a flag or buffers.
- Each module runs to completion.
- No delays or spins in the loop.
Why split bootloader and application?
The strongest answer: So I can recover and update without a probe on every unit — I still treat the bootloader as sacred, small, and tested
Why it works: Exactly. Recovery. A playful app that eats the bootloader is a brick factory.
- Split for recover and update.
- Keep the bootloader small and tested.
- Do not let the app eat the bootloader.
- One blob bricks harder.
A peer writes `while(!ready);` with no other path. Strongest critique?
The strongest answer: If ready never happens we hang — add a timeout, a counter, and a defined failure, especially around locks and buses
Why it works: Exactly. Short is not safe. A kicked dog around a dead wait is a silent brick.
- No naked forever-waits.
- Timeout + defined failure.
- Macros do not add safety.
- Do not bless a hang with a kick.
The app team wants to “just patch the bootloader in the field.” Your pushback?
The strongest answer: A bad bootloader bricks the fleet — I want a dual path, a signed image, and a tested failure, not a casual field edit
Why it works: Exactly. Boot is the last door. Casual and unsigned are how you recall a year.
- Treat bootloader updates as brick-risk.
- Want dual path and a tested fail.
- Do not casual-edit boot in the field.
- Do not fleet-ship a debug boot.
You are receiving framed packets over UART. How do you structure the parser?
The strongest answer: A byte-at-a-time state machine: hunt for the sync byte, read the length, bound-check it, collect the payload, verify the check, hand the frame over — plus a timeout that returns it to hunting
Why it works: Exactly — and the timeout is what stops one lost byte wedging the parser until the next reset.
- Parse byte by byte, in explicit states.
- Hunt for sync before anything else.
- Bound-check the length before copying.
- Time out back to hunting.
What must an OTA design have before the first customer update?
The strongest answer: A rollback or a two-bank story, a signature check, and a failed-update that still boots — I do not OTA a single slot and hope
Why it works: Exactly. Hope and “do not unplug” are not a design. Signatures are not optional in 2026.
- Rollback or two banks.
- Signature check.
- Failed update must still boot.
- Do not single-slot-and-hope.
Marketing wants “secure boot” on the box. What do you actually build?
The strongest answer: A chain you can explain: ROM or fused root, signed next stage, locked debug — a flag in a header is not a chain
Why it works: Exactly. A chain and locked debug. Defines, banners, and skipped verify are theatre.
- Root, signed next stage, locked debug.
- A header flag ≠ secure boot.
- No UART password as the chain.
- Do not skip verify for line rate.
An OTA bricks 2% of units. What should already exist?
The strongest answer: A way back or a factory path that does not need the dead app, plus a halt on the campaign — I do not push “one more try” blind
Why it works: Exactly. Stop the campaign. Retry-blind and unsigned retries spend the other 98%.
- Halt the campaign.
- Need a path that survives a dead app.
- Do not blind-retry the same slot.
- Do not disable signatures to “help.”
The product must be interactive in 400 ms. What do you defer?
The strongest answer: Anything not needed for the first safe UI or actuator — I do not run a full self-test novel before the user can abort
Why it works: Exactly. Safe first, then the rest. Cloud-before-local and vanity POST miss the number and the user.
- Boot the safe path first.
- Defer the rest.
- Do not skip safe defaults for 20 ms.
- Do not block on the cloud.
Where do device identity keys not live?
The strongest answer: In the public repo, in a header, or in an OTA you can unzip — I want a secure element or a fused provision story I can rotate
Why it works: Exactly. Provisioning and rotation. One fleet key and Slack are how you revoke the product.
- No keys in git/headers/unzippable OTA.
- Prefer SE or fused provision.
- No Slack keys.
- No one key for the fleet.
Eight SKUs, one repo. What do you refuse?
The strongest answer: A maze of `#ifdef` with no build matrix — I want named variants I can test, not a compile-time folklore
Why it works: Exactly. Named, tested variants. Eight repos and desk-only are how you ship the wrong heater table.
- Named variants + a build matrix.
- Not an #ifdef folklore.
- Not eight rotting repos.
- Do not test only your desk SKU.
What is a staff-level OTA policy?
The strongest answer: Signed images, rings, a halt switch, and a brick budget you have funded — not “push latest to 100% at Friday 17:00”
Why it works: Exactly. Rings and a halt. Fairness-blasts and invented 99.9% are how you spend a weekend.
- Sign, ring, halt, funded brick path.
- No Friday 100% push.
- No unsigned chat hotfix.
- No invented 99.9%.
Who is allowed to change the boot chain?
The strongest answer: A short list, with review, because a bad boot is a fleet brick — I do not let feature teams drive-by the vectors
Why it works: Exactly. A small door. Drive-bys, interns-as-owners, and bots are how you brick on a Tuesday.
- Short list + review on boot.
- No feature drive-by on vectors.
- Not “anyone who can merge.”
- Not a bot from a ticket.
What is in an OTA threat model you will sign?
The strongest answer: Who can sign, what happens if we lose the key, and what a hostile image must not be able to do — I do not skip this because “it is just an update”
Why it works: Exactly. Signers, loss, hostile image. HTTPS-only and CDN-trust are 2016 answers.
- Signers, key-loss, hostile image.
- HTTPS ≠ the whole model.
- No single fleet key in CI.
- Do not outsource trust to the CDN.
The product has to move to a second MCU family, and the application code calls the vendor’s HAL directly everywhere.
What boundary do you set, and what do you hold the team to?
The strongest answer: One narrow interface we own — read this sensor, set this output — with the vendor HAL only behind it, so the application builds on the host and new silicon touches a single layer
Why it works: Right — the test is whether the application layer still builds with no vendor header in sight. That is also what makes host tests possible.
- Own the interface; hide the vendor behind it.
- Define it by what the app needs.
- The app builds with no vendor header.
- One layer changes when silicon changes.
A third-party blob must go in the image. What do you require?
The strongest answer: A pinned version, a licence you can ship, and a sandbox or MPU fence — I do not vendor-drop latest from a random URL on build day
Why it works: Exactly. Pin, licence, fence. Latest-main and supervisor-for-ease are how you import a Tuesday.
- Pin version + shippable licence + fence.
- Do not fetch latest on build day.
- Do not strip licences.
- Do not give the blob the keys.
When do you stop OTA-supporting a SKU?
The strongest answer: When you say so in writing, with a last image and a parts story — I do not silently stop and hope the field never asks
Why it works: Exactly. A written end. Silence, intern-leave, and fashion are how you fail a hospital or a factory.
- Write the end: last image, parts.
- Do not silently stop.
- Eternal OTA is not free.
- Do not follow radio fashion.
An update will disable a feature people paid for. What do you do?
The strongest answer: Tell them, give a choice or a path, and do not hide it in release notes as “stability” — a silent take-back is a trust incident
Why it works: Exactly. Honesty and a path. “Our device” and fake security are how you earn a class of angry owners.
- Tell users; give a path.
- Do not hide as “stability.”
- Do not fake a security reason.
- Do not brick to ease support.
A device must live ten years in a closet. What do you plan now?
The strongest answer: How you will build an image in year nine: pinned tools, keys, and a spare board — I do not assume today’s laptop will boot then
Why it works: Exactly. Year-nine build. Memory, only-cloud, and “offline so no keys” are how you fail a decade.
- Pin tools, keys, a spare board.
- Do not assume today’s laptop.
- Do not rely on memory.
- Offline ≠ skip integrity.