Lab Instrumentation interview questions

10 questions, easiest first

1. 1You're asked to measure the resistance of a resistor that's still soldered onto a populated circuit board. Your DMM reads 340 ohms, but the resistor is marked 1 kilohm (brown-black-red). What's most likely going on, and how would you get a trustworthy reading?intro

   Answer this one, graded

   Or just show what a strong answer covers

   An in-circuit resistance reading almost never matches the marked value because the ohmmeter's test current also flows through any parallel paths - other resistors, traces to a ground plane, or semiconductor junctions. A reading of 340 ohms against a 1k nominal is consistent with something roughly 510 ohms in parallel with it. Before condemning the part, I'd check the schematic for anything connected between those two nodes, make sure the board is fully powered off with caps discharged since a live circuit gives garbage or unstable readings, and if I need certainty, physically isolate the resistor by lifting one leg or clipping a trace, then remeasure it out of circuit.

   • Identifies parallel current paths — Recognizes other board components in parallel between the same nodes lower the apparent resistance, e.g. 1k || 510 ~= 340.
   • Proposes isolation method — Suggests lifting one leg, desoldering, or otherwise isolating the part before condemning it.
   • Notes DMM ohmmeter mechanism — Mentions the meter injects a small test current/voltage across whatever is electrically connected between the probes.
   • Checks power state and schematic — States the board must be fully powered off and discharged, and that the schematic should be checked for parallel paths first.

   Where answers go wrong: Assuming the resistor itself is out of spec or bad without considering the rest of the circuit. · Blaming DMM accuracy instead of circuit topology. · Measuring resistance on a board that is still powered, which gives meaningless or dangerous readings.

2. 2You want to measure how much current a small 3.3V sensor board draws during normal operation. You put your DMM in series between the supply and the board, select the mA current range, and close the loop. The sensor board now resets randomly and its behavior looks glitchy. When you instead clip a clamp-on current probe around the same wire without breaking the circuit, the board runs perfectly fine and you read about 45 mA. What's going on, and how would you change your DMM-based measurement so it stops disturbing the circuit?intro

   Answer this one, graded

   Or just show what a strong answer covers

   A DMM in current mode is basically a low-value shunt resistor with a spec'd burden voltage, often a few hundred millivolts on the low-current range. On a 3.3V rail with tight headroom, that drop is enough to brown out the sensor board, which explains why the glitching disappears with a non-invasive current probe. I'd confirm by checking the meter's datasheet burden voltage spec for that range, or by putting a second meter across the DMM's terminals while measuring to see the actual drop. To fix it, I'd either switch to a higher current range with lower burden voltage, use a low-value external sense resistor and read the voltage across it with a scope or DMM in voltage mode, or just use a clamp-on current probe like I did to confirm the real number.

   • Identifies burden voltage as root cause — States that the DMM's current-mode shunt resistor drops a voltage in series with the circuit that is disturbing the board.
   • Explains why 3.3V rail is sensitive — Connects the burden voltage magnitude to the low headroom of a 3.3V supply causing brownout/reset.
   • Proposes a concrete fix — Suggests at least one of: appropriate/higher current range, external shunt resistor read differentially, or a clamp-on current probe.
   • Describes a verification step — Mentions checking the DMM's burden voltage spec or measuring voltage across the meter itself to confirm the cause before changing setup.

   Where answers go wrong: Assuming a DMM in current mode has zero series resistance/impedance · Blaming the sensor board's firmware or a separate hardware fault first · Not realizing burden voltage changes with selected current range

3. 3You want to see a 100 mV ripple riding on a 12V rail. You connect the probe, set coupling to DC, and set the vertical scale to 2 V per division. The trace looks like a flat line. What do you change, and why?easy

   Answer this one, graded

   Or just show what a strong answer covers

   Two things are working against me. First, at 2V/div the scope has to display the full 12V range, so a 100mV signal is a fraction of a division regardless of anything else - effectively invisible. Second, I should switch to AC coupling, which capacitively blocks the DC average and lets the scope devote its full vertical range and gain to just the ripple. Then I'd drop the scale to something like 20-50mV/div so the ripple fills several divisions, confirm the probe is compensated correctly, and set the trigger to the ripple's frequency, likely the switching frequency, so the trace is stable instead of drifting.

   • Switches to AC coupling — States that AC coupling blocks the DC offset so the display isn't dominated by the 12V level.
   • Reduces vertical scale — Proposes dropping to a scale like 20-50 mV/div so the ripple fills multiple divisions.
   • Explains why scale alone was the problem — Notes that even with correct coupling, 2V/div would still make 100mV invisible without rescaling.
   • Mentions triggering or bandwidth limiting — Adds a note about stabilizing the trigger on the ripple frequency or engaging a bandwidth limit to cut noise.

   Where answers go wrong: Believing AC coupling alone fixes visibility without also adjusting the vertical scale. · Confusing AC coupling with probe attenuation settings. · Ignoring probe compensation or bandwidth limiting when chasing a small signal.

4. 4You need to measure the voltage across the high-side switch of an isolated flyback converter using two single-ended scope probes, both referenced to earth ground through the scope chassis. What goes wrong when you connect the second probe's ground clip, and what should you do instead?easy

   Answer this one, graded

   Or just show what a strong answer covers

   All the probe ground clips on a bench scope are tied to the chassis and, through the power cord, to earth. If I clip the second probe's ground onto the switching drain node, which isn't at earth potential, I create a low-impedance path from that node straight to earth through the probe. That can short part of the converter, blow a fuse, trip a breaker, or destroy the switch, and it also bridges the primary and secondary sides right through my probes, defeating the isolation barrier. The right tool is a differential probe rated for the common-mode voltage and bandwidth involved, which measures the difference between its two tips without referencing either to earth. If one isn't available, isolating the scope itself with an isolation transformer is a fallback, but it still requires care and understanding of what's now floating.

   • Explains shared ground path — States that all probe ground clips are electrically tied together and to earth via the scope's chassis and power cord.
   • Identifies the fault created — Explains that clipping onto a non-earth-potential switching node effectively shorts that node to earth, which can blow fuses, damage the converter, or defeat the isolation barrier.
   • Proposes differential probe — Names a differential probe rated for the relevant common-mode voltage and bandwidth as the correct tool.
   • Mentions an alternative safeguard — Notes options like an isolated scope/isolation transformer, with appropriate caution, as a fallback.

   Where answers go wrong: Assuming each probe's ground clip floats independently per channel. · Not realizing that grounding two different non-earth nodes ties them together through the probes. · Using a math channel (A-B) without checking each probe's common-mode voltage rating.

5. 5You're trying to catch the moment a 5V rail droops during power-up -- it happens once, right as the board turns on, and never again until you power-cycle it. Your scope is connected with the trigger mode left on Auto and the display rolling continuously. You power-cycle the board several times but never seem to catch the droop on screen. What's wrong with your trigger setup, and how would you change it to reliably capture that single event?easy

   Answer this one, graded

   Or just show what a strong answer covers

   Auto trigger mode free-runs and keeps refreshing the display even without a valid trigger, so a single power-up droop just scrolls through and gets overwritten before I can react. I'd switch to Normal or Single trigger mode, set a falling-edge trigger with the level set somewhere between the nominal 5V and the expected droop minimum, and arm the scope right before flipping on power. I'd also shift the trigger point so there's enough pre-trigger record to see the clean baseline before the droop and enough post-trigger record to see the recovery. In Single mode the scope stops and holds the trace the moment it triggers, so I know I've actually captured the event instead of hoping I glimpsed it.

   • Diagnoses the Auto trigger problem — Explains that Auto mode keeps refreshing/free-running and doesn't hold the trace on the single event, so it can be missed or overwritten.
   • Specifies correct trigger mode — States that Normal or Single (single-shot) trigger mode should be armed before the power-up so the scope stops on the actual event.
   • Sets an appropriate trigger level/edge — Chooses a falling-edge trigger level between nominal voltage and the expected droop minimum.
   • Uses pre-trigger record positioning — Mentions adjusting horizontal trigger position so the baseline before the droop and the recovery are both visible in the capture.

   Where answers go wrong: Leaving trigger mode on Auto for a rare, single-shot event · Setting the trigger level too close to nominal, causing false triggers, or too close to the minimum, causing missed triggers · Not repositioning the trigger point and missing the pre-event baseline

6. 6An I2C bus on your board occasionally fails to get an ACK during back-to-back register writes, maybe 1 in 500 transactions. You have both a scope and a logic analyzer on the bench. Walk me through which tool you reach for first, why, and how you'd set it up to catch this.medium

   Answer this one, graded

   Or just show what a strong answer covers

   For something this rare I'd start with the logic analyzer, not the scope, because I need to run long enough to catch maybe thousands of transactions before the failure shows up, and a logic analyzer with deep memory and a built-in I2C decoder lets me trigger specifically on a NACK or a failing address instead of eyeballing a live trace. I'd sample at least 10x the I2C clock rate so edges are timed accurately, and set a protocol trigger on 'no ACK' so the capture only saves when the failure actually happens. Once I have a timestamp and the surrounding transaction, I'd switch to the scope on just that moment to look at analog causes: a pull-up too weak for the bus capacitance giving a slow rise time, ringing that causes a false clock edge, or a glitch from another device driving the bus at the wrong time. The logic analyzer finds when and what; the scope explains why at the electrical level.

   • Chooses logic analyzer first — Explains that catching a 1-in-500 event needs long capture time and deep memory, plus built-in protocol decode to flag the failure automatically.
   • Sets protocol-level trigger — Describes triggering on a NACK bit or specific address so the capture stops only when the failure occurs.
   • Uses scope for root cause after locating event — States that once timing is known, the scope checks rise/fall time, pull-up strength, capacitance, or ringing at that specific moment.
   • Considers sample rate adequacy — Mentions sampling well above the I2C clock rate so edges and timing are resolved accurately.

   Where answers go wrong: Reaching for the scope only and manually watching for a rare event. · Not using a protocol-level trigger condition, relying on manual scrolling instead. · Ignoring sample rate relative to the I2C clock when configuring the logic analyzer.

7. 7Your DMM's datasheet specifies accuracy of plus or minus (0.05% of reading + 3 counts) on the 6V range, where the display resolution on that range is 0.1 mV (a 4.5-digit display). You measure a supply rail and the display reads 3.3000 V. What is the absolute uncertainty in millivolts, and how many of the displayed digits are actually meaningful?medium

   Answer this one, graded

   Or just show what a strong answer covers

   I split the spec into its two pieces. The percentage term is 0.05% of the 3.3V reading, which is 1.65mV. The counts term is 3 counts times the range's resolution of 0.1mV, which is 0.3mV. Adding them gives a total uncertainty of about 1.95mV, call it 2mV. Since the last digit of a 4.5-digit display on the 6V range is the 0.1mV place, and my uncertainty is roughly twenty times that, the last one to two digits of '3.3000' aren't meaningful - they're noise relative to the meter's actual accuracy. I'd report the measurement as 3.300V plus or minus 0.002V, and if I needed better resolution than that I'd need a better meter or a null/differential technique, not just trust the extra digits on the display.

   • Computes percentage term — Calculates 0.05% of 3.3V as 1.65 mV.
   • Computes counts term — Calculates 3 counts times the 0.1 mV resolution as 0.3 mV.
   • Sums to total uncertainty — Adds both terms to get approximately 1.95 mV, roughly 2 mV.
   • Draws digit-significance conclusion — States that with ~2mV uncertainty, the last one to two displayed digits are not meaningful and reports the result as roughly 3.300V +/- 0.002V.

   Where answers go wrong: Forgetting to add both the percentage term and the fixed counts term. · Confusing the range's resolution with the range's full-scale value. · Assuming all digits on a '4.5-digit' display are automatically trustworthy.

8. 8You're setting up a logic analyzer to decode a SPI bus running at a 10 MHz clock. The analyzer on your bench can sample up to 100 MSa/s, but you don't want to just plug in whatever's available -- you want to know the real minimum sample rate you'd trust before believing the decode. Walk through how you'd figure that out, and give me a number.medium

   Answer this one, graded

   Or just show what a strong answer covers

   For decoding digital signals I don't rely on the classic 2x Nyquist rate that's meant for reconstructing a sinusoid's frequency -- I want to resolve actual edge timing and duty cycle, so the rule of thumb is more like 4x to 10x the clock frequency. For a 10 MHz SPI clock that puts the floor around 40 MSa/s, and I'd want as much headroom above that as the analyzer allows to account for clock jitter and any duty-cycle asymmetry, so running the 100 MSa/s analyzer at its full rate is the safer choice. After capturing, I'd validate by checking for framing or parity errors in the decode and, if I'm not sure, cross-checking a section against a scope capture to make sure edges line up where they should.

   • Rejects simple 2x Nyquist reasoning — Explicitly states that Nyquist's 2x rule, appropriate for sinusoids, is not enough to reliably resolve digital edges and duty cycle.
   • Applies an oversampling rule of thumb — Uses roughly 4x-10x the clock frequency as the basis for the minimum sample rate.
   • Produces a concrete minimum number — Computes a minimum sample rate around 40 MSa/s (4x times 10 MHz), ideally noting more margin is better.
   • Describes empirical validation — Mentions checking actual decoded data / framing errors or cross-referencing against a scope capture to confirm the chosen rate is sufficient in practice.

   Where answers go wrong: Applying strict 2x Nyquist sampling as if decoding a sine wave · Ignoring that timing margin around clock edges affects correct bit sampling · Not considering the analyzer's input voltage threshold relative to the bus logic level

9. 9A driver IC is spec'd with a 2 ns rise time. You want to verify that spec on the bench to within about 5% measurement error using an oscilloscope. Walk me through how you'd decide the minimum oscilloscope bandwidth you need, including the reasoning, not just a rule you memorized.hard

   Answer this one, graded

   Or just show what a strong answer covers

   The scope doesn't show me the true edge; it shows the signal filtered through its own bandwidth-limited response. For a roughly single-pole system, a scope's own rise time relates to its bandwidth as t_r is about 0.35 divided by bandwidth. What I actually see on screen is the true rise time and the scope's rise time combined in quadrature, t_measured equals the square root of t_signal squared plus t_scope squared, because they're independent filtering stages rather than simply additive. If I want the measured rise time to be no more than about 5% above the true 2ns, so around 2.1ns, I solve for the scope's allowable rise time: t_scope equals the square root of 2.1 squared minus 2 squared, which comes out to about 0.64ns. Converting that back to bandwidth, BW equals 0.35 divided by 0.64ns, roughly 550MHz. So I'd want a scope rated at least around 500MHz, and just as importantly the probe has its own rise time that stacks in the same quadrature sum, so I'd need to check the probe's bandwidth too, not just the scope's front end, or the combined system could still fall short of that number.

   • States bandwidth-rise time relation — Gives the approximate relation between an instrument's rise time and its bandwidth, roughly 0.35/BW.
   • States quadrature combination — Explains that measured and true rise times combine as sqrt(signal^2 + scope^2), not additively.
   • Solves for required scope rise time — Shows the algebra: solves for the scope rise time that keeps the measured rise time near 5% above 2ns, arriving at roughly 0.6-0.7 ns.
   • Converts to bandwidth and notes probe contribution — Converts the required scope rise time back into a minimum bandwidth figure (roughly 500 MHz or higher) and notes the probe's own bandwidth adds another term in the same quadrature sum.

   Where answers go wrong: Assuming the scope only needs bandwidth equal to the simple reciprocal of the rise time without accounting for quadrature combination. · Forgetting the probe itself contributes its own rise time to the same sum. · Quoting a memorized 'rule of thumb' bandwidth without being able to derive where it comes from.

10. 10You're debugging a USB-powered peripheral board that's earth-grounded through its metal enclosure via the USB cable's shield back to your laptop. You're powering the board's separate analog section from a bench supply whose chassis is also earth-grounded through the building's mains wiring. You clip your oscilloscope's probe ground lead onto a ground test point on the board to check a signal. The instant the clip makes contact, there's a small spark and your laptop's USB port shuts down. What just happened, and how would you set up the measurement to avoid it next time?hard

    Answer this one, graded

    Or just show what a strong answer covers

    The scope's probe ground isn't floating -- it's tied through the scope's chassis and power cord to the same building earth ground as everything else. The board was already earth-referenced through the USB cable shield back to my laptop. The instant I clipped the probe ground onto the board, I created a second, parallel path to earth that hadn't existed before, and since the two ground references weren't at exactly the same potential or impedance, current flowed through that new path -- essentially a short between two nominally-same-but-not-identical grounds -- which was enough to trip the USB port's overcurrent protection. Before connecting next time, I'd use a DMM to check the voltage or resistance between the two ground points first. Going forward I'd use a differential probe so I'm not tying a second ground reference to the board at all, or power one of the instruments through an isolation transformer or a floating/battery-powered scope so there's only a single ground path in the whole setup.

    • Identifies the scope's own earth ground path — States that the oscilloscope's probe ground is tied to earth through its power cord, not an independent or floating reference.
    • Explains the mechanism as a real short/current path — Describes clipping the probe as creating a second path to earth in parallel with the USB shield path, and that a potential or impedance difference between them drove fault current, not just audible hum.
    • Proposes a verification step before connecting — Mentions checking voltage or resistance between the two ground references with a DMM before clipping the scope probe onto the board.
    • Names a concrete mitigation — Suggests at least one specific fix: differential probe, isolation transformer/isolated supply, battery-powered or floating scope, or USB isolator.

    Where answers go wrong: Attributing the event only to generic 'ground loop noise' or hum rather than an actual current path being created · Forgetting that the oscilloscope itself is earth-grounded through its own AC power cord · Proposing 'isolate something' vaguely without naming a concrete method like a differential probe or isolation transformer