Debugging Methodology interview questions

10 questions, easiest first

1. 1You build a simple circuit: a battery, a switch, a resistor, and an LED in series. You close the switch and the LED does not light. You have three candidate explanations: dead battery, dead LED, or an open connection somewhere in the loop. Walk me through how you'd decide which one it is — what you check first, in what order, and what specific measurement would rule each one out.intro

   Answer this one, graded

   Or just show what a strong answer covers

   I'd start with the cheapest test: measure the battery voltage directly with a meter, ideally under load since a weak battery can read fine open-circuit and collapse under current draw. If that's healthy, I'd check continuity through the switch and wiring with the circuit open, since a broken wire or bad switch contact is common and easy to test. Only then would I suspect the LED itself — I'd check its polarity first, since a backwards LED looks identical to a dead one, then swap in a known-good LED or apply a small test voltage directly across it. Each of these is a specific measurement that can independently confirm or rule out one cause, so I'm not guessing — I'm eliminating possibilities one falsifiable test at a time, cheapest and most likely first.

   • Battery voltage checked first with a meter — States measuring battery voltage under load (not just open-circuit) as the first, cheapest test before touching other components.
   • Names a specific measurement per hypothesis — For each of the three causes, states an exact measurement (e.g. voltage across LED, continuity across switch/wire) rather than 'inspect it'.
   • Considers LED polarity/orientation as a failure mode — Recognizes that an LED installed backwards looks identical to a 'dead LED' fault and must be checked separately.
   • Justifies the ordering — Explains why the chosen order (e.g. battery before disassembly) minimizes wasted effort, not just lists steps.

   Where answers go wrong: Jumping straight to replacing the LED without measuring anything first. · Checking components in physical order left-to-right instead of by likelihood or ease of test. · Confusing 'no voltage across LED' with 'LED is dead' without checking polarity.

2. 2A linear regulator is supposed to output 5.0V but you measure 4.2V at its output pin under load. Before you touch anything else, what is the very first hypothesis you'd test, and what single measurement would prove or kill it?intro

   Assume the regulator has an input capacitor, output capacitor, and a resistive load; you have a multimeter and a bench supply.

   Answer this one, graded

   Or just show what a strong answer covers

   My first hypothesis is that the input rail itself is sagging under load — either the source can't supply enough current, or there's too much drop across upstream wiring/connectors. I'd test this by probing the regulator's input pin directly, with the same load applied that caused the 4.2V reading, not at idle. If the input is already below the regulator's minimum (output + dropout voltage), that fully explains the low output and I don't need to suspect the regulator itself. If the input looks healthy — say a clean 5.2V — then the hypothesis is dead and I move to checking the feedback network or whether the load is drawing more current than the regulator can supply, checking the datasheet current limit. I prioritize this first because it's a one-probe measurement that either explains the whole symptom or eliminates an entire class of causes.

   • States a specific first hypothesis — Names a concrete candidate cause (e.g. input undervoltage, excessive load current, wrong feedback resistor) rather than 'check the circuit'.
   • Describes a measurement that would falsify it — Explains exactly what to measure and where (e.g. probe input pin under load, not just at no-load) and what result would rule the hypothesis in or out.
   • Justifies the ordering — Gives a reason this is the first thing to check, such as it being upstream of everything else or trivially cheap to test.
   • Avoids shotgun debugging — Does not propose swapping parts or replacing the whole regulator before measuring anything.

   Where answers go wrong: Jumping straight to 'replace the regulator' without measuring anything first. · Measuring input voltage with no load, which hides a sag that only appears under load. · Treating the datasheet dropout voltage as irrelevant to the hypothesis.

3. 3A board has a chain of 8 identical logic buffer stages wired in series. You confirm the signal is correct at the very first input and completely absent at the very last output. Instead of probing stage 1, then 2, then 3, and so on down the line, how would you localize the faulty stage in the fewest possible measurements? Roughly how many measurements does that take in the worst case?easy

   Answer this one, graded

   Or just show what a strong answer covers

   Since input is good and output is bad, the fault is somewhere between stage 1 and stage 8. Instead of scanning from the front, I'd probe the middle of the chain, say the output of stage 4. If that's good, the fault is in stages 5 through 8; if it's bad, the fault is in stages 1 through 4. Either way I've cut the suspect region in half with one measurement. I'd repeat that on whichever half remains suspect, halving again each time. For 8 stages that converges in about 3 measurements worst case — log base 2 of 8 — instead of up to 8 if I scanned one at a time. This works because I have a clean boundary condition on each end and each stage is independent, so a measurement in the middle definitively splits the problem.

   • Proposes probing the middle of the chain first — States checking around stage 4 or 5 (roughly the midpoint) rather than starting from stage 1 or 2.
   • Describes recursive halving — Explains that after the first measurement, only continue probing whichever half still contains the fault, repeating the halving.
   • Gives a correct or near-correct worst-case count — Estimates roughly 3 measurements for 8 stages (log2(8)=3), or reasons explicitly in terms of log2(N).

   Where answers go wrong: Probing sequentially from stage 1, which takes up to 8 measurements instead of 3. · Assuming you must physically desolder or remove stages instead of just probing test points along the chain. · Forgetting that after the first probe you only need to search the half where the fault must be.

4. 4A board resets itself at unpredictable times — sometimes within an hour, sometimes not for a full day, with no obvious pattern. Before you touch the schematic, swap a capacitor, or change any code, what do you need to establish first, and specifically what would you do to try to make this failure happen more often and more predictably?easy

   Answer this one, graded

   Or just show what a strong answer covers

   Before I change anything, I need to be able to make this happen on demand, or at least reliably within a short window — otherwise I have no way to tell if a fix actually worked versus just got lucky. I'd first add instrumentation: a reset-reason register readout, a data logger, or a scope with a long enough memory and a trigger on the reset line so I capture supply voltage and any error flags right when it happens. Then I'd start stressing plausible variables one at a time — running the board hot and cold, varying supply voltage, adding vibration, or hammering whatever workload seems to correlate with faster failures — to see which condition makes the reset happen more often. Once I find a lever that reliably speeds it up, I've effectively turned a random failure into a reproducible one, and now I can actually test hypotheses and verify a fix.

   • States the need for a reliable repro before attempting a fix — Explicitly says a fix can't be validated if the failure can't be triggered on demand, so reproduction is the priority.
   • Proposes at least two concrete stress techniques — Names specific ways to provoke the failure faster, e.g. thermal cycling, power supply variation, vibration/tapping, extended soak, load stress.
   • Proposes logging or instrumentation to catch the event — Mentions adding logging, a data logger, or a scope with long memory/trigger-and-hold to capture state at the moment of failure.
   • Looks for correlation with environment or usage — Suggests correlating failure timing with external factors like temperature, time of day, or specific operations running.

   Where answers go wrong: Immediately guessing at a root cause (e.g. 'probably a decoupling cap') and changing something before the failure can be reliably triggered. · Assuming a single overnight observation is enough data to declare a fix successful. · Not instrumenting the board to capture what state it was in right before the reset.

5. 5You have a 5-meter wiring harness with 12 inline connectors between a sensor and its controller. Continuity from end to end fails — no signal gets through — but you don't know which connector or wire segment is broken. Walking up and testing each connector one at a time would take forever. How do you find the break efficiently?easy

   You have a multimeter and access to both ends of the harness plus every connector in between.

   Answer this one, graded

   Or just show what a strong answer covers

   Instead of walking connector by connector from one end, I'd test continuity at the middle connector, roughly connector 6, first. If it's good from the sensor end to connector 6, the break is somewhere in the second half; if it's already broken by connector 6, the break is in the first half. Either way I've eliminated half the harness in one test. I repeat that on whichever half still fails — test its midpoint — and keep halving. For 12 connectors that's about 4 tests instead of up to 12, and it scales even better as the harness gets longer. One caveat: the fault could be in a connector itself rather than the wire, so once I've isolated a single segment I check the connector pins directly, not just wire continuity, and I'd also watch for a connector that's fine when wiggled gently but fails under harness tension, which continuity alone won't catch.

   • Proposes testing the midpoint first — Explicitly starts by checking continuity at or near connector 6 of 12, not connector 1.
   • Correctly recurses — Describes how each test result (pass/fail) determines which half to search next, continuing to halve until the faulty segment is isolated.
   • States the efficiency gain — Mentions that this takes roughly log2(N) tests instead of N, or gives a comparable justification for why it's faster.
   • Handles a practical caveat — Notes at least one real-world wrinkle, e.g. connectors themselves can be the fault (not just wire), or that a multimeter needs both ends accessible simultaneously.

   Where answers go wrong: Proposing to check connectors 1, 2, 3... in order from one end, which is correct but not efficient. · Forgetting that a 'pass' at the midpoint tells you the break is on the far side, not that everything is fine. · Not accounting for the connectors themselves being a failure point distinct from the wire segments.

6. 6You have a signal chain: a sensor feeds an instrumentation amplifier, which feeds a low-pass filter, which feeds an ADC. The ADC reads a constant value no matter what the sensor is actually doing. Walk me through how you'd trace this signal chain from source to sink to find where it stops being correct, including what you'd check at each stage, and what a reading 'stuck at a supply rail' versus 'stuck at zero' would tell you differently.medium

   Answer this one, graded

   Or just show what a strong answer covers

   I'd walk the chain in order, starting at the source. First I'd confirm the sensor's raw output is actually varying with the physical quantity it measures — if it's already flat there, none of the downstream circuitry matters yet. If the sensor is fine, I'd probe the amplifier's input to confirm it sees the same signal, then its output; if the output doesn't track the input, I'd check the amp's own supply rails and reference voltage, because a starved or misconfigured amp can output a flat, wrong value that looks like a broken signal path. I'd repeat the same input-versus-output check across the low-pass filter, and finally at the ADC input. Along the way, the specific failure value matters: if a stage is stuck at a supply rail, that suggests saturation, an overdriven input, or a short to that rail; if it's stuck at zero, that suggests an open connection, a dead power rail, or a short to ground. That distinction tells me which stage and which failure mode to investigate first, rather than treating 'wrong' as one undifferentiated symptom.

   • Starts at the sensor output, not the ADC — Proposes verifying the sensor's raw output changes correctly before assuming any downstream stage is at fault.
   • Checks each stage's input vs output — Describes probing the input and output of the amplifier and filter separately to find exactly which stage stops passing a correct signal.
   • Distinguishes rail vs. zero failure modes — Explains that a rail-stuck reading suggests saturation/overdrive/short-to-supply while a zero-stuck reading suggests open circuit, dead power rail, or short-to-ground, and that this changes where to look next.
   • Checks amplifier power and reference, not just signal path — Mentions verifying the amplifier's own supply rails and reference voltage, since a starved op-amp can produce a flat output that looks like a signal-path fault.

   Where answers go wrong: Only probing the ADC input and assuming the fault must be in the ADC itself. · Not checking whether the amplifier or filter stage has proper power before assuming the signal path is broken. · Treating 'stuck at rail' and 'stuck at zero' as the same symptom instead of using them to narrow the hypothesis.

7. 7You're probing a high-impedance analog node — say a 1 MΩ pull-up feeding a comparator input — and every time you touch it with a standard 10:1 scope probe, the voltage you read changes and the fault you were chasing seems to disappear. What's physically happening, and how would you confirm the probe itself is the cause rather than assume you accidentally fixed something?medium

   Answer this one, graded

   Or just show what a strong answer covers

   A 10:1 probe typically has around 10 megohms of resistance in parallel with maybe 10 picofarads of capacitance. Against a low-impedance node that's negligible, but against a 1 megohm source, the probe's resistance is comparable to the source impedance, so it forms a voltage divider that pulls the node toward a different level, and the capacitance forms an RC low-pass with that same high source impedance, slowing down or filtering out fast transitions. So the very act of measuring is changing the voltage and the dynamics at that node — that's the observer effect. To confirm it's the probe and not a real fix, I'd try a probe with different loading characteristics, like a 1:1 probe or a low-capacitance FET probe, and see if the symptom changes again in a way that correlates with probe impedance rather than staying fixed. I would not conclude the circuit is fixed just because the symptom vanished under the probe — if anything, that's strong evidence the fault is real and is being masked by measurement, so I'd look for a way to observe it indirectly, like buffering the node with a high-impedance amplifier before probing.

   • Identifies probe capacitance/resistance loading the node — Explains that the probe's input capacitance (and finite resistance) forms a divider or low-pass filter with the high-impedance source, pulling the node toward a different voltage or slowing its transitions.
   • Notes the node's high impedance makes it unusually sensitive — States that a 1 MΩ or higher source impedance is comparable to or larger than typical probe impedance, unlike a low-impedance node where the same probe would have negligible effect.
   • Proposes a comparison test to confirm loading — Suggests comparing behavior with a different probe (e.g. 1:1 vs 10:1, or a FET/high-Z probe), or briefly disconnecting and reconnecting the probe while monitoring a downstream indicator, to see if the symptom's presence correlates with the probe.
   • Avoids concluding the fault is fixed just because it disappeared — Explicitly states that the symptom vanishing under measurement is itself a clue, not evidence the underlying problem is resolved.

   Where answers go wrong: Concluding the circuit is now working simply because the fault stopped appearing while probing. · Not recognizing that source impedance determines how much a given probe will load a node. · Assuming all scope probes have identical loading effects regardless of node impedance.

8. 8A microcontroller commands a motor driver with a PWM signal at a set duty cycle, but the motor's actual speed doesn't match what the commanded duty cycle should produce. You confirm the MCU is generating the correct duty cycle on its GPIO pin. Walk me through how you'd trace the signal chain from there to find where it stops matching the command.medium

   The signal path is: MCU GPIO -> gate driver IC -> power FET -> motor terminals. You have an oscilloscope.

   Answer this one, graded

   Or just show what a strong answer covers

   Since the MCU output is confirmed correct, I move the probe one stage down at a time: gate driver input, gate driver output, then the FET's drain or the motor terminal itself, comparing duty cycle and edge shape at each point against what I'd expect if that stage were healthy. At the gate driver output I'd expect a slightly shifted duty cycle if dead-time is intentionally inserted, which isn't a fault, just a known offset I need to account for. If the gate driver output looks right but the FET drain doesn't, I'd suspect the gate resistor or Miller plateau slowing switching enough to round off the edges and effectively change the duty cycle seen by the motor, especially at higher PWM frequencies. If the drain waveform still matches the commanded duty cycle and the motor still runs at the wrong speed, then the problem isn't duty cycle at all — I'd shift hypotheses toward current limiting, back-EMF, or load torque affecting actual speed independent of PWM. The key discipline is defining what 'correct' looks like at each stage before probing, so I can tell a real fault from an expected characteristic of that stage.

   • Establishes a stage-by-stage probing plan — Explicitly describes probing gate driver input, gate driver output, and FET drain/motor terminal in order, rather than jumping straight to the motor.
   • Defines expected signal at each stage — States what a correct signal should look like at each point (e.g. duty cycle preserved, clean edges, expected dead-time) so a deviation is recognizable.
   • Proposes plausible root causes for duty-cycle distortion — Names at least two specific mechanisms, e.g. driver dead-time insertion, gate resistor RC rounding edges, FET Miller plateau delay, or PWM frequency aliasing with driver bandwidth.
   • Distinguishes duty-cycle distortion from a downstream effect — Recognizes that even a correct PWM at the FET drain doesn't guarantee correct motor speed — mentions checking whether the mismatch is really duty cycle at all versus current limiting, load, or back-EMF changing apparent speed.

   Where answers go wrong: Assuming the motor itself must be broken without first checking whether the PWM waveform is even correct at the FET. · Only checking one point in the chain and declaring the chain 'fine' if that one point looks reasonable. · Not considering that gate driver dead-time is an intentional, correct distortion of duty cycle, not a fault.

9. 9A control board works perfectly on the open bench, but once you close it into its enclosure it glitches intermittently. Opening the enclosure to probe it makes the glitch disappear again. Design a debugging plan: what hypotheses would you form to explain this (thermal, EMI, mechanical/connector flex, light-dependent sensing, grounding, or the act of opening the case itself), in what order would you test them, and how do you deal with the fact that observing the system tends to change it?hard

   Answer this one, graded

   Or just show what a strong answer covers

   I'd first list the hypotheses that are consistent with 'fails closed, works open': thermal buildup since a closed case traps heat that an open bench dissipates; EMI or grounding changes since a metal or plastic enclosure alters shielding and current return paths; mechanical stress since closing the lid may flex a connector or press on a component; and, if there's any optical sensor, ambient light exposure that only the open case allows. Because opening the case to probe destroys the very condition I'm trying to observe, I can't just stick a scope probe in — I need instrumentation that survives closing the lid: onboard data logging to flash, a thermal sensor with a feedthrough or small drilled access hole, or telemetry sent out over a connector that's normally used anyway. I'd test cheapest and fastest first: run the board closed with just a temperature logger to see if internal temperature during a glitch is actually elevated compared to open-bench baseline — that's fast and either confirms or rules out thermal immediately. In parallel, I'd try wrapping the open board in foil to see if simulating a shielded environment reproduces the glitch, which tests EMI without needing to fully close it. I'd test mechanical last since it usually requires physically pressing on connectors while open, which is a more awkward setup. Whichever test actually reproduces the glitch while still being observable is the one I trust, since it means I've found an instrumentation method that lets me see the fault without curing it by looking.

   • Enumerates at least three distinct, plausible hypotheses — Names multiple credible causes such as thermal buildup, EMI/shielding change, mechanical stress on connectors from closing the lid, and light exposure on an optical sensor, not just one guess.
   • Pairs each hypothesis with a specific falsifying test — For each named cause, states a concrete test (e.g. external thermal probe through a feedthrough, EMI can/shield added on open bench, physically flexing connectors without closing the lid, covering the board with an opaque box) rather than vague 'investigate further'.
   • Addresses the observer effect directly — Explicitly explains why opening the case to look changes the very conditions under test (temperature drop, EMI exposure change, mechanical release, light) and proposes measuring without opening it, e.g. internal data logging, feedthrough connectors, thermal camera through a viewport, wireless telemetry.
   • Proposes a sensible testing order — Justifies which hypothesis to test first based on cost, speed, or how many other hypotheses it eliminates, rather than testing them in arbitrary order.

   Where answers go wrong: Only considering one cause (e.g. jumping straight to EMI) instead of laying out and ranking multiple competing hypotheses. · Proposing to 'just open it and probe' as the main plan, ignoring that this destroys the very condition causing the failure. · Not proposing any way to instrument or log the closed system, leaving no way to actually test the hypotheses.

10. 10You're trying to characterize a crystal oscillator circuit's startup behavior. Every time you touch the crystal's oscillating node with your scope probe, the oscillator either fails to start or its frequency shifts noticeably; remove the probe and it behaves differently again, and you can't tell which behavior is the 'real' one. How do you figure out what the circuit actually does, and how would you get a trustworthy measurement?hard

    You're using a standard passive 10:1 probe with several pF of tip capacitance. The oscillator is a low-power crystal circuit designed to just barely sustain oscillation.

    Answer this one, graded

    Or just show what a strong answer covers

    The oscillator node between the crystal and the inverting amplifier is high-impedance and specifically designed with just enough gain margin to sustain oscillation against a target load capacitance; a standard passive probe adds several picofarads right at that node, which shifts the effective load capacitance and can push a marginal oscillator past its startup threshold or pull its frequency. So the discrepancy isn't the circuit being flaky, it's the measurement itself changing the system under test — classic observer effect. To get a trustworthy read, I'd avoid probing the raw crystal node directly: instead I'd look at a buffered output, like the MCU's clock-out pin or a digital pin toggling at a divided version of the oscillator frequency, since that reflects the oscillator's real behavior without loading the sensitive node. If I do need to probe the node itself, I'd use a low-capacitance active probe rather than a 10:1 passive probe, and even then I'd treat the reading as 'behavior under some added capacitance' rather than ground truth, ideally cross-checking against the buffered-output method to see if they agree. The unprobed, undisturbed state is the one that matters for deployment, so my goal is to get as close to zero added capacitance as practically possible and corroborate with an independent measurement rather than trusting either single reading in isolation.

    • Identifies capacitive loading as the root cause — Explicitly names probe tip capacitance interacting with the crystal's sensitive load capacitance/oscillation margin as the mechanism, not just 'the probe is disturbing it.'
    • Proposes a genuinely lower-impact measurement method — Suggests a concrete alternative such as a high-impedance/low-capacitance active probe, probing a buffered digital output instead of the oscillator node, or characterizing behavior indirectly (e.g. via the MCU's clock output) rather than the raw node.
    • Reasons about ground truth, not just the discrepancy — Addresses which state — probed or unprobed — is closer to real operating conditions, or acknowledges that the true unloaded behavior may need to be inferred rather than directly observed.
    • Considers accounting for residual loading — Mentions that even a lower-capacitance probe adds some load, and either quantifies/estimates its effect or proposes cross-checking with a second, independent method (e.g. spectrum analyzer, frequency counter on a buffered pin).

    Where answers go wrong: Concluding the oscillator is simply 'unstable' without identifying probe capacitance as the specific mechanism. · Assuming the unprobed behavior (which you can't directly observe) must be the correct one without justification. · Proposing to just probe harder or longer rather than changing the measurement approach. · Ignoring that even a 'better' probe still has nonzero loading effect.