Embedded / hardware interview questions

A status register never seems to change in your loop, but the scope says it does. First suspect?

The strongest answer: The compiler cached the read — I mark MMIO volatile (or use the vendor accessor) so each access hits the hardware

Why it works: Exactly. MMIO is not a RAM variable. Volatile or the accessor is the contract.

• Treat MMIO as volatile.
• Do not rely on printf to “refresh” a register.
• Do not ban optimisation as the design.
• The scope can be right when C looks stuck.

An LED runs from a 3.3 V pin and its datasheet says it drops about 2 V at the current you want. How do you size the series resistor?

The strongest answer: The resistor takes the leftover 1.3 V, so its value is 1.3 volts divided by the current I want; then I round up to a standard value and check the pin can source that current

Why it works: Right — subtract the drop, apply Ohm’s law, then sanity-check the pin’s current limit, which is the step people skip.

• The resistor sees supply minus the LED drop.
• R is volts across it over current.
• Round up to a standard value.
• Check the pin’s current limit.

Why are people cautious about malloc on a small MCU?

The strongest answer: Fragmentation, no-fail stories, and ISR rules — I prefer static or a pool I can size, I do not malloc in an interrupt

Why it works: Exactly. Size what you can see. Heap in an ISR or a fault is how you lose the chip twice.

• Prefer static or a sized pool.
• No malloc in ISR or fault.
• Heap can fragment and fail.
• Do not copy desktop habits blindly.

An ISR is parsing JSON and printing. What do you change?

The strongest answer: Set a flag or queue a byte/buffer and return — parse and print in thread context

Why it works: Exactly. ISRs are short. Sleep and priority games make a worse real-time mess.

• Flag or queue; return.
• Parse in thread context.
• No sleep in an ISR.
• Do not raise priority to do more work.

What is a watchdog for?

The strongest answer: To reset a stuck system I could not recover in software — I kick it from a path that proves progress, not from a tight empty loop

Why it works: Exactly. Progress, not a heartbeat of a dead loop. Scheduled reboots and disabled dogs are two failure modes.

• Kick from proven progress.
• Not from an empty loop.
• Not a scheduled fashion reboot.
• Do not disable it to look smooth.

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.

What is SWD, and how does it differ from JTAG?

The strongest answer: Both let a debugger halt the core, step, set breakpoints and read memory. SWD does it over two pins; JTAG uses four or five and also gives you boundary scan and a chain of devices

Why it works: Right — on a pin-tight board SWD is the usual pick, and what you give up is boundary scan and the chain.

• Same debug job, different pin count.
• SWD: two pins, plus optional trace out.
• JTAG: four or five, plus boundary scan.
• Check voltage and protocol before probing.

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.

A reset pin “randomly” browns the board. First hardware question?

The strongest answer: Is it floating — pull-up/down, solder, and the reset source — I do not start by rewriting the scheduler

Why it works: Exactly. Floating resets are electrical. Mutexes do not solder a resistor.

• Check float vs pull.
• Look at solder and the reset source.
• Do not start in the scheduler.
• Do not leave reset floating.

On a PWM output, what does the duty cycle control and what does the frequency control?

The strongest answer: Duty is the fraction of each period the output is on, so it sets average power — brightness or motor torque; frequency is how fast that period repeats, chosen to suit the load

Why it works: Right — duty is the lever for output level, frequency is a design choice: audible whine, visible flicker, switching losses.

• Duty sets the level; frequency suits the load.
• Duty is on-time over the period.
• Choose frequency for whine and losses.
• Timer period sets frequency, compare sets duty.

You see no UART data on the PC. Fastest split?

The strongest answer: Loopback on the board, known baud, and a scope on TX — I do not rewrite the protocol first

Why it works: Exactly. Does TX wiggle at the right rate? Loopback splits board vs PC.

• Loopback + known baud + scope TX.
• Do not start at 921600.
• Do not invert all pins at once.
• Split board vs host.

A function works until you add a log line, then you hard-fault. Suspect?

The strongest answer: Stack overflow or a smashed frame — I look at stack size, big locals, and recursion, not “logs are cursed”

Why it works: Exactly. A log line is more stack. Curses and disabled faults are how you ship a bomb.

• Suspect stack when a tiny add faults.
• Check size, locals, recursion.
• Do not disable the fault handler.
• Do not pad with more stack use.

When do you pick an RTOS over a main-loop, and when not?

The strongest answer: RTOS when I have concurrent deadlines I cannot honestly interleave — main-loop when the work is a simple sequence I can bound

Why it works: Exactly. Concurrency you can name. Fashion and logos are not deadlines.

• RTOS for named concurrent deadlines.
• Main-loop when the sequence is boundable.
• Not a fashion pick.
• Not a logo pick.

A 5 V sensor output goes straight into a 3.3 V MCU pin. What is your concern, and what do you do?

The strongest answer: Unless that pin is rated 5 V tolerant, 5 V pushes current into its protection diode and damages it; I check the datasheet, then add a level shifter, or a divider if the signal is slow

Why it works: Right — tolerance is a per-pin property in the datasheet, and the other direction matters too: 3.3 V may not reach a 5 V input’s high threshold.

• Check pin voltage tolerance in the datasheet.
• 5 V into a 3.3 V pin needs shifting.
• A divider only suits slow signals.
• Check the 5 V input’s high threshold too.

A 50 µs control loop misses when UART RX fires. What do you measure?

The strongest answer: Worst-case ISR time and priority — I move work out of UART and protect the control IRQ, I do not “optimise the C” first

Why it works: Exactly. Budget the interrupt. C micro-opts do not beat a 400 µs parse in RX.

• Measure ISR time and priority.
• Move work out of RX.
• Protect the control IRQ.
• Do not buy a core before a budget.

On an embedded Ethernet board, name the pieces between your firmware and the cable.

The strongest answer: The MAC in the MCU drives a PHY chip over MII or RMII, the PHY feeds the magnetics and the jack, and a management bus reports link state and speed; the IP stack sits above the MAC

Why it works: Right — that split is why “link up but no address” and “no link at all” are two different investigations.

• Link, addressing and stack are separate layers.
• MAC inside the MCU, PHY outside it.
• Magnetics and jack finish the path.
• Read link and speed from the PHY.

You copy ADC samples in a 10 kHz ISR. Better pattern?

The strongest answer: DMA into a buffer, interrupt on block, process in a task — I do not copy in the ISR unless I have measured I must

Why it works: Exactly. DMA is why the CPU exists for control. Print-per-sample is a joke that becomes a bug.

• DMA the stream.
• Block interrupt, then task.
• Do not memcpy in the 10 kHz ISR.
• Do not printf the stream.

A write to an address “does nothing.” First read?

The strongest answer: The memory map and MPU/alignment — is it flash, reserved, cached, or the wrong alias — not a bigger hammer of writes

Why it works: Exactly. Maps lie less than hope. Hammers and deleted MPUs are how you brick a day.

• Open the memory map.
• Check alias, cache, MPU, alignment.
• Do not hammer all-ones.
• Do not delete the MPU as a first fix.

Where should the watchdog get kicked in an RTOS app?

The strongest answer: From a supervision path that has seen the critical tasks run — not from a low-priority idle hook that still runs when workers die

Why it works: Exactly. Kick means progress of the jobs you care about. Idle and ISR kicks lie.

• Kick from a supervisor of critical tasks.
• Not from idle alone.
• Not from every ISR.
• Do not outsource to power-cycles.

Battery dies in hours, not months. What do you measure first?

The strongest answer: Sleep current and what you left awake — clocks, pull-ups, a chatty radio — I do not start by blaming the cell chemistry slide

Why it works: Exactly. Quiescent first. Bigger cells hide leaks. BOD-off on empty is data corruption.

• Measure sleep current.
• Find what you left awake.
• Do not start with a bigger cell.
• Do not disable BOD to sip the last mV.

When do you reach for a logic analyser, and when for an oscilloscope?

The strongest answer: Analyser when the question is “are the bytes right” — many channels, a long capture, protocol decode. Scope when the question is electrical: edge shape, ringing, levels, a glitch too narrow to sample

Why it works: Exactly — they answer different questions, and the classic mistake is decoding a line that is electrically broken.

• Protocol questions: analyser. Electrical questions: scope.
• Analyser: many channels, long capture, decode.
• Scope: edges, levels, ringing, glitches.
• A bad signal decodes as plausible nonsense.

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.

Walk me through what happens between power-on and a login prompt on an embedded Linux board.

The strongest answer: A boot ROM loads a bootloader from a known device, the bootloader brings up RAM and storage and loads the kernel with its device tree, the kernel mounts the root filesystem, and init starts the services

Why it works: Right — naming the stages is what lets you say which one went silent when a board stops booting.

• Know the chain so you can bisect it.
• ROM loads the bootloader.
• Bootloader loads kernel and device tree.
• Kernel mounts rootfs; init starts services.

A UART interrupt needs to hand a byte to a task through an RTOS queue. What must the ISR do differently?

The strongest answer: Call the FromISR version of the queue API, which never blocks, and pass the higher-priority-task-woken flag to the yield macro so the woken task runs as the ISR exits

Why it works: Right — no blocking, and the yield is what makes the handoff prompt instead of waiting for the next tick.

• ISRs use the FromISR calls and never block.
• Send with the FromISR variant.
• Pass the woken flag to the yield.
• Keep the interrupt priority RTOS-callable.

A low-priority task holds a lock a high-priority task needs. What do you name?

The strongest answer: Priority inversion — I want inheritance or a ceiling, or I redesign the lock, I do not raise everything to max

Why it works: Exactly. Name it, then inheritance/ceiling/redesign. Max-priority-everything is a busy-loop OS.

• Name inversion.
• Inheritance, ceiling, or redesign.
• Do not flatten every priority.
• Do not sleep-turn-take.

A global initialised to a non-zero value reads as zero in the first function main calls, but only in the release build.

Which part of start-up do you go and read?

The strongest answer: The code that runs before main: it copies .data initial values from flash into RAM and zeroes .bss. If that copy is skipped, or the linker script’s addresses are wrong, initialised globals read as zero

Why it works: Exactly — and that is also why a zero-initialised global costs no flash while a non-zero one costs flash and RAM.

• Start-up builds RAM before main runs.
• .data is copied from flash.
• .bss is zeroed.
• The linker script defines both regions.

One task corrupts another’s stack. What do you add besides “be careful”?

The strongest answer: MPU regions or separate privilege, plus a watermark — careful is not a boundary

Why it works: Exactly. Hardware boundaries. Merging and enlarging hide the thief.

• MPU or privilege split.
• Keep watermarks.
• Careful ≠ a boundary.
• Do not merge smashers.

The idle task still kicks the dog while a motor task is dead. What was wrong?

The strongest answer: The kick did not prove the motor path — I check-in each critical job, I do not treat idle as “the system”

Why it works: Exactly. The dog’s question is “did the plant get served?” Idle is not the plant.

• Kick must prove critical jobs.
• Idle ≠ the plant.
• Do not delete the job to pass.
• Do not stretch the dog to hide death.

A struct is cast straight onto a UART receive buffer, and the fields come out shifted on one of the two boards.

What is going on, and what would you do instead?

The strongest answer: The compiler pads members up to their alignment and the two builds pad differently. I serialise field by field into a byte buffer with a fixed order instead of casting a struct

Why it works: Exactly — a wire format is a byte layout you define, not whatever your compiler happened to lay out today.

• Define the wire format; never cast a struct onto it.
• Padding is per compiler and target.
• Serialise field by field, fixed order.
• Packed still leaves alignment and endianness.

How do you talk power without a fake “months of battery” slide?

The strongest answer: Sleep current, duty cycle I measured, and what radio/sensor policy I chose — I do not invent a month count

Why it works: Exactly. Measured pieces. Invented months and theoretical mAh are ads.

• Measure sleep and duty.
• Name radio/sensor policy.
• No invented month count.
• Do not sack BOD for a slogan.

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.

A low-side MOSFET switching a motor gets hot, even though the datasheet promises a very low on-resistance.

What do you look at?

The strongest answer: The gate drive. On-resistance is quoted at a gate voltage, so 3.3 V into a part that wants 10 V leaves it half on; I check that rating, the drive level and how fast the edges are

Why it works: Exactly — and slow edges heat it too, because it spends longer in the linear region on every switch.

• On-resistance is quoted at a gate voltage.
• Match the FET to your drive level.
• Keep edges fast enough to leave linear.
• Pulldown on the gate for reset.

A device publishes telemetry and a status over MQTT. Which QoS do you choose, and what is the last will for?

The strongest answer: Telemetry rides QoS 0 where losing a sample is fine; what must arrive goes QoS 1 with an idempotent consumer. The last will is the offline message the broker publishes when we drop without disconnecting

Why it works: Right — QoS is a per-topic choice, and the will exists precisely because a dead device cannot announce itself.

• Pick QoS per topic, not per product.
• QoS 0 where a lost sample is fine.
• QoS 1 plus an idempotent consumer.
• The last will announces the drop you cannot.

Datasheet says 400 kHz I2C; the line looks filthy at 100. What wins?

The strongest answer: The scope and the board — capacitance, pull-ups, length — I do not “trust the PDF” into a flaky field bus

Why it works: Exactly. Physics on your PCB. Faster-into-dirt and extra MCUs are how you fail EMC and time.

• Believe the scope on your board.
• Pull-ups, C, length.
• Do not outrun dirt with MHz.
• A second MCU is not a resistor.

You have a 2 ms control deadline. What number do you present?

The strongest answer: Worst-case with the IRQs you allow, not a mean from a happy bench — and what you disable to hold it

Why it works: Exactly. Deadline is a max. Host cycle counts are a different CPU.

• Present worst-case, allowed IRQs.
• Say what you disable to hold it.
• Means are not the deadline.
• Host cycle counts are not the chip.

A battery divider reads correctly on its own, but a few counts low whenever the channel measured before it was at a high voltage.

What do you suspect?

The strongest answer: The sample-and-hold capacitor has not finished charging through a high source impedance, so it keeps part of the previous channel. I lengthen the sampling time or buffer the divider

Why it works: Exactly — source impedance and sampling window are one budget, and a channel-dependent error is the classic symptom.

• Sampling time must match source impedance.
• A high-impedance source needs a longer window.
• Or buffer it with a follower.
• Channel-dependent error means charge sharing.

When do you allow C++ on the MCU, and what do you ban?

The strongest answer: A written subset: no throwing across the RTOS, no hidden heap in ctors I cannot see — I do not say “modern C++” as a plan

Why it works: Exactly. A subset you can debug at 02:00. Desktop exceptions and macro objects are two cliffs.

• Written C++ subset.
• No hidden heap or throws across the kernel.
• “Modern” is not a plan.
• Do not fragment dialects per app.

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.

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.

A product team wants a coin-cell sensor to run for years, and the first prototype is nowhere close.

Which levers do you actually pull?

The strongest answer: How often we wake and how long we stay awake — the radio dominates, so fewer and shorter transmissions beat any sleep-current tuning; then check the cell survives the transmit pulse, usually with a reservoir capacitor

Why it works: Right — duty cycle is the lever, and a coin cell has enough internal resistance that the pulse, not the average, is what kills it.

• Duty cycle beats sleep-current tuning.
• Wake less often; stay awake less.
• Radio airtime is the budget.
• Check the cell survives the pulse.

A consumer device has to join the customer’s Wi-Fi, and the first prototype has the office network name and password compiled into the build.

What do you require before this ships?

The strongest answer: Credentials come from the customer during setup through a provisioning flow, are stored per device in protected flash, and can be changed or cleared without a firmware update — factory reset included

Why it works: Exactly — per device, changeable, erasable on reset. Baked-in credentials are one teardown away from every unit.

• Credentials belong to the customer, not the build.
• Provision at setup, per device.
• Store them protected, never in the image.
• Make factory reset clear them completely.

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%.

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.

Who owns battery life in a device company?

The strongest answer: A named owner across radio, firmware, and mechanics — I do not let each team quote a month in isolation

Why it works: Exactly. One throat. Isolated month-quotes are how the box lies.

• Name an owner across radio/FW/mech.
• No isolated month quotes.
• Marketing does not own the mA.
• The cell vendor is not the product.

Two teams share one firmware, each has added mutexes, and you have now had two hangs that reproduce about once a week.

What policy do you put in place?

The strongest answer: One documented lock order everybody takes locks in, short critical sections, no blocking call while holding a lock, and a review rule that any new lock joins the order

Why it works: Exactly — circular wait is the condition you can design away, and a written order plus a review rule is how it stays away.

• Remove circular wait by design.
• Write one global lock order.
• No blocking calls while holding a lock.
• Every new lock joins the order.

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.

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.

What does a staff engineer pin on the wall for a control product?

The strongest answer: A worst-case budget with owners for each steal — I do not keep it in one person’s head

Why it works: Exactly. Owned steals. Slogans and invented percentiles are décor.

• Worst-case budget, named owners.
• Not a demo mean.
• Not a slogan.
• No invented deadline percentile.