All jobs / Embedded / hardware

Hardware / Firmware Integration interview questions

Hardware / Firmware Integration questions a Embedded / hardware can be asked, from first job to senior. Open one to see the strongest answer and why it works.

  1. A new sensor will not ACK. Where do you look first?

    The strongest answer: The datasheet: address, voltage, pull-ups, timing, and the first command — then the scope, not a random GitHub driver as step one

    Why it works: Exactly. Pins and timing first. Forums and max-speed bit-bang are how you cook a bus.

    • Datasheet: address, rails, pull-ups, timing.
    • Then a scope.
    • Not a random driver first.
    • Do not max the bit rate to wake it.

  2. You need to know what an MCU pin is actually connected to on a new board.

    How do you read that off the schematic?

    The strongest answer: Find the pin on the MCU symbol, read its net name, and search that name across every sheet — nets cross pages by label, not by a drawn wire — then note series parts, pull-ups and do-not-populate marks

    Why it works: Right — and confirm it on the board with a meter before trusting it, because fitted parts and the schematic can differ.

    • Follow net names, not drawn wires.
    • Search the net label on every sheet.
    • Note series parts and pull-ups.
    • Check do-not-populate against the board.

  3. New board: what is a sane bring-up order?

    The strongest answer: Rails, clocks, a blink, then the next interface you can see on a scope — I do not flash the full app first and pray

    Why it works: Exactly. Prove power and a heartbeat. Radios are late. One glow is not a rail log.

    • Rails → clocks → blink → next scoped I/O.
    • Not the full app first.
    • Not the radio first.
    • One LED glow ≠ rails proven.

  4. A peripheral behaves unlike the nice diagram. Second book?

    The strongest answer: The errata / silicon notice — then the scope — I do not assume I am the first to see it

    Why it works: Exactly. Silicon has footnotes. Languages and overclocks do not repeal them.

    • Read errata when hardware is “weird.”
    • Then measure.
    • Language will not fix the FIFO.
    • Do not treat errata as legal fluff.

  5. First samples of a new MCU. How do you spend week one?

    The strongest answer: Rails, clock, a blink, SWD/JTAG you can attach after a crash, then one peripheral — I do not port the full product on day two

    Why it works: Exactly. Attach after death. Full-app and cellular-first are how you lose the week.

    • Rails, clock, blink, attachable debug.
    • Then one peripheral.
    • Do not port the product on day two.
    • Do not skip SWD for USB.

  6. A heater can burn a house. What do you refuse to treat as “just firmware”?

    The strongest answer: The fail-safe — independent cut-outs, a safe default, and a process I will not skip for a sprint — I do not invent a SIL number we never earned

    Why it works: Exactly. Independent hardware and a real process. Invented SIL/rates and stickers are how you meet a lawyer.

    • Independent fail-safe, safe default.
    • Do not skip process for a sprint.
    • Software-only is not enough for a house fire.
    • No invented SIL or 10⁻⁶.

  7. The bench is happy; the chamber is not. Firmware’s job?

    The strongest answer: Tighten timing, retries, and watchdogs for the noise you will see — I do not say “hardware’s problem” and leave

    Why it works: Exactly. Firmware is part of EMC survival. Hope and disabled CRC are how you fail a retest.

    • Retries, CRC, watchdog for noise.
    • Do not dump it on hardware only.
    • Do not disable CRC to look clean.
    • Bench ≠ chamber.

  8. Firmware dies. What must the hardware still do?

    The strongest answer: Put actuators in a safe default — I design that with EE, I do not assume a crash leaves pins polite

    Why it works: Exactly. Safe default on death. Last-value and floating are how you hold a heater or a valve in the worst state.

    • Hardware safe default on death.
    • Do not hold last value by habit.
    • Do not assume the RTOS lives.
    • Do not float actuators.

  9. Factory wants a debug image with open JTAG. What do you ship to customers?

    The strongest answer: A field image with debug locked and secrets gone — factory and field are different artefacts I can name

    Why it works: Exactly. Two artefacts. Open-in-field and keys-on-the-web are how you donate the product.

    • Field image ≠ factory image.
    • Lock debug; strip secrets.
    • Do not publish map files with keys.
    • Do not ask customers not to attach.

  10. The factory asks what firmware they will be running on the line, a week before the first build.

    What do you owe them?

    The strongest answer: A test image that exercises every fitted part with a pass or fail limit for each, programs the unit’s identity and calibration, fits the line’s time budget, and records a result per serial number

    Why it works: Right — the records are what turn a field failure into a traceable batch instead of a rumour.

    • Prove each fitted part; record every unit.
    • Give every measurement a pass limit.
    • Program identity and calibration on the line.
    • Fit the line’s time budget.

  11. How do you staff a first-silicon week so it is not hero theatre?

    The strongest answer: A written sequence, two people who can attach a debugger, and a daily leftover — I do not send one genius and a prayer

    Why it works: Exactly. A sequence and a bench. Solo genius and parallel guesses are two ways to lose a spin.

    • Written sequence + two who can attach.
    • Daily leftover.
    • Not one genius.
    • Do not parallel the app on guesses.

  12. A vendor PM says “ignore that timing; the PDF is old.” What do you require?

    The strongest answer: A written spec you can test, dated — I do not design to a hallway comment

    Why it works: Exactly. Dated paper. Hallways and kinder-of-two are how you fail a retest.

    • Demand a dated, testable spec.
    • Hallway comments are not timing.
    • Do not pick the kinder rumour.
    • Do not let the field be the lab.

  13. What belongs in the hardware/software contract you will sign?

    The strongest answer: Power-up defaults, clock sources, who owns which pin, and the fail-safe — I do not keep it in a Slack scroll

    Why it works: Exactly. Defaults, clocks, pins, fail-safe. Whiteboards and shouts fail the second spin.

    • Write defaults, clocks, pin owners, fail-safe.
    • Not Slack folklore.
    • Not a whiteboard photo.
    • Schematic alone is not the contract.