All jobs / Embedded / hardware

Testing interview questions

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

  1. Host unit tests pass. The board fails. What do you remember?

    The strongest answer: The host is not the clocks, the pins, or the IRQ load — I still test on the device for anything that touches hardware

    Why it works: Exactly. Both layers. LEDs are not an oracle.

    • Host tests ≠ the chip.
    • Still test hardware paths on hardware.
    • Keep host tests for logic.
    • Do not oracle from an LED.

  2. What do host unit tests still miss that HIL catches?

    The strongest answer: Pin timing, IRQ load, and the real clock tree — I keep both; I do not pick a religion

    Why it works: Exactly. Different bugs. Friday shows are souvenirs.

    • Unit = logic; HIL = pins/IRQs/clocks.
    • Keep both.
    • x86 is not the device.
    • Friday bench ≠ a suite.

  3. How do you unit-test firmware logic on a PC when the code talks to hardware?

    The strongest answer: Put the hardware behind a small interface and test the logic against a fake that returns canned values and records the calls; the logic includes our header, never a vendor one, so it builds on the host

    Why it works: Right — and be honest about what host tests cannot see: timing, interrupts, and how the peripheral really behaves.

    • Test logic against an interface you own.
    • Hide vendor headers behind that interface.
    • The fake returns values and records calls.
    • Say what host tests cannot cover.

  4. What clock condition do you test besides the happy crystal?

    The strongest answer: The slow/fast corners you allow — HSI, PLL lock fail, and the clock you run after a backup — I do not only test the lab oscillator

    Why it works: Exactly. The ugly source. Eval crystals flatter you. Overclock-as-margin is a different chip.

    • Test allowed slow/fast sources.
    • Include backup clocks.
    • Eval crystal ≠ the field.
    • Do not overclock and call it margin.

  5. A fault that only ever appeared in the field has been found and fixed.

    What do you require before the ticket closes?

    The strongest answer: The reproduction turned into an automated test that runs on every build — on the host if it can be, on hardware if it must — and proof that it fails on the old build and passes on the new

    Why it works: Right — a test that has never been seen to fail proves nothing, so the run against the old build is part of the requirement.

    • Every field bug leaves a test behind.
    • Automate the reproduction.
    • Run it on every build.
    • Prove it fails on the old build.

  6. A customer asks if you are “SIL-3 certified.” What do you not do?

    The strongest answer: I do not invent a level — I say what process we actually ran, what is independent hardware, and what we have not claimed

    Why it works: Exactly. Claims need evidence. Vendor slides and borrowed numbers are how you meet a regulator angry.

    • Say the process you ran.
    • Name independent hardware.
    • Do not invent a SIL level.
    • Do not borrow a certificate.

  7. How do you talk about safety standards without theatre?

    The strongest answer: The clauses we actually follow, the independent functions, and the gaps — I do not tattoo a standard number on a slide

    Why it works: Exactly. Clauses and gaps. Smiles, parts, and weekends are not a safety case.

    • Name clauses, independents, gaps.
    • No tattooed standard number.
    • A part ≠ a system case.
    • No weekend certification claim.

  8. What is the test shape you will fund?

    The strongest answer: Host logic, HIL for pins/time, and a few system benches — I do not fund only a Friday hero demo or only a million host mocks

    Why it works: Exactly. Layers. Religions and a drawer unit fail the second SKU.

    • Fund host + HIL + a few system benches.
    • Not only Friday demos.
    • Not only mocks.
    • Not one drawer unit.

  9. Sales wants “certified firmware” on the datasheet. Your line?

    The strongest answer: Certified to which standard, which version, which configuration — I do not let a word wander onto the sheet

    Why it works: Exactly. Scope or silence. Later, borrowed marks, and compiler-as-system are how you meet a lawyer.

    • Name standard, version, configuration.
    • No wandering “certified.”
    • Do not borrow a mark.
    • A certified compiler ≠ certified firmware.

  10. The board wants one number for firmware quality. What do you give?

    The strongest answer: Field reset rate on a defined population, plus one leftover risk — I do not invent a quality percentile

    Why it works: Exactly. A defined field story and a leftover. Crowns and LOC are games.

    • Defined field reset story.
    • One leftover-risk sentence.
    • No invented quality percentile.
    • No IDE crown as the answer.

  11. A slide says “MTBF 1e6 hours.” What do you do?

    The strongest answer: Remove it unless we have a measurement and a method I will defend — I do not invent reliability theatre

    Why it works: Exactly. Method or delete. Zeros, copied cell numbers, and customer-pleasing fiction are the same lie.

    • No MTBF without a method.
    • Do not invent zeros.
    • Do not copy a part’s MTBF onto the product.
    • Customer taste ≠ a measurement.

  12. A date wants to ship with an untested fail-safe on a heater. What do you do?

    The strongest answer: I stop that path — date is not a substitute for a safe default I have seen work — and I write the leftover so nobody “forgets”

    Why it works: Exactly. Energy plus untested cut-out is not a launch. Disclaimers and invented SIL are costumes.

    • Stop an untested fail-safe on energy.
    • Write the leftover.
    • Dates ≠ a cut-out.
    • No invented SIL to hold a date.