Validation & Reliability interview questions

10 questions, easiest first

1. 1A connector spec says: 'The connector shall withstand 50 mating cycles without contact resistance exceeding 20 milliohms.' You've been asked to write the test procedure that verifies this before the design is signed off. Walk me through what the test actually looks like, and what would make it a bad test.intro

   Answer this one, graded

   Or just show what a strong answer covers

   I'd start by making the pass criterion numeric and traceable: use a four-wire Kelvin measurement of contact resistance at a fixed low current so I'm not measuring lead resistance. I wouldn't just check resistance at cycle 50 -- I'd measure it periodically, say every 5 or 10 cycles, because a connector could develop an intermittent high-resistance contact partway through and recover by the end, which a single end-of-test measurement would miss. The mating cycle itself should be done with a fixture that applies consistent insertion/extraction force and angle, since manual cycling introduces variability that isn't representative of the field. I'd also want more than one sample -- one connector passing doesn't tell you the design margin, especially with plating wear or contact normal force variation from part to part. Finally, I'd think about what environment this connector actually sees -- if it's outdoors, I might combine cycling with temperature or vibration rather than testing it in isolation.

   • Defines measurable pass criterion — States that resistance must be measured quantitatively (e.g., four-wire/Kelvin measurement) and compared numerically against 20 mOhm, not just 'check if it still works'.
   • Specifies measurement timing — Mentions measuring resistance at intervals during the 50 cycles (not just at cycle 50) to catch degradation trends and intermittent failures.
   • Addresses cycle mechanism realism — Notes the mating/unmating action should be automated or controlled to be repeatable and represent real insertion force/angle, not manual haphazard cycling.
   • Mentions sample size — Recognizes that testing one connector isn't sufficient to make a general claim; discusses testing multiple units.
   • Identifies test escape risk — Notes what a bad test would miss, e.g., only checking at cycle 50 and missing an intermittent open at cycle 30.

   Where answers go wrong: Saying you'd 'mate and unmate it 50 times and see if it still works' without defining a measurement · Forgetting to specify how resistance is measured (two-wire vs four-wire matters at 20 mOhm scale) · Testing only one sample and generalizing the result · Not considering that failure could be intermittent and only caught by measuring during the cycles, not just at the end

2. 2You're handed a requirement that says: 'The enclosure shall be rugged enough for outdoor use.' Before you can design a single test for this, what's wrong with the requirement as written, and what information would you need to gather to turn it into something you could actually pass or fail a unit against?intro

   Answer this one, graded

   Or just show what a strong answer covers

   The requirement is unusable as-is because 'rugged' and 'outdoor use' aren't measurable -- two people could write completely different tests from it and both be 'compliant.' Before writing a test I'd push back and ask for the actual environment: temperature and humidity range, exposure to dust/water, expected drops (height, orientation, surface), vibration during transport, and how long or how many cycles it needs to survive. I'd also need explicit pass/fail criteria -- does 'survive' mean fully functional afterward, or is cosmetic damage acceptable? Ideally these numbers come from real data: field studies, customer surveys, or an applicable standard, not just an engineer's gut feeling. Only once I have quantified stress levels and a clear definition of failure can I design a test that actually verifies the requirement.

   • Flags the ambiguity — Explicitly states that 'rugged' and 'outdoor use' are not measurable and can't be tested as written.
   • Asks for concrete environmental bounds — Proposes gathering specifics like temperature range, drop height/orientation, humidity, dust/water exposure, expected duration or cycle count.
   • Defines pass/fail criteria — States that the requirement must specify what counts as failure -- full functional loss vs. cosmetic damage vs. degraded performance.
   • Ties it back to real use — Mentions deriving these numbers from actual field data, customer use patterns, or relevant standards rather than guessing.

   Where answers go wrong: Jumping straight to naming a standard (e.g., IP67) without first establishing that the requirement needs quantification. · Proposing a test plan before clarifying what 'survives' actually means. · Ignoring duration/cycle count and only thinking about a single stress event.

3. 3You could put a board in an oven at 85C for 24 hours (a soak) or you could cycle it repeatedly between -40C and 85C over the same total time. Both stress the board thermally, but they're meant to catch different failures. What does cycling expose that a soak does not, and why?easy

   Answer this one, graded

   Or just show what a strong answer covers

   A soak tells you whether the board can survive and operate at a sustained temperature -- it'll catch things like a component drifting out of spec or leakage current increasing at 85C. But it doesn't stress anything mechanically over time. Cycling between -40 and 85 repeatedly forces materials with different coefficients of thermal expansion -- solder, copper, the PCB substrate, component packages -- to expand and contract at different rates relative to each other. That mismatch creates repeated mechanical strain at interfaces like solder joints, vias, and connector contacts. A single joint might survive one or even a hundred cycles fine, but the strain accumulates as fatigue damage, similar to bending a paperclip back and forth, until a crack initiates and eventually propagates to an open circuit. A 24-hour soak at 85C would never expose that because there's no repeated strain, just one steady-state condition. So cycling is really about catching fatigue failures that only show up as a function of the number of transitions, not the total time at temperature.

   • Identifies mechanical fatigue mechanism — Explains that cycling induces repeated expansion/contraction due to differing coefficients of thermal expansion between materials (solder joints, PCB, package), causing crack propagation over cycles.
   • Distinguishes static vs cyclic damage — Articulates that a soak reveals whether a part functions or degrades at a sustained temperature (e.g., leakage current, drift), while cycling reveals cumulative fatigue that only appears after repeated transitions.
   • Gives a concrete failure example — Names a plausible real failure exposed by cycling, e.g., solder joint cracking, via/pad delamination, or connector contact fatigue.
   • Notes soak still has value — Acknowledges soak isn't useless -- it's for different failure modes like parametric drift or chemical degradation, not a strawman dismissal.

   Where answers go wrong: Saying cycling and soaking are basically equivalent because they both involve the same temperature extremes · Not mentioning material CTE mismatch as the physical driver of fatigue · Describing cycling only as 'more thorough' without explaining the actual fatigue mechanism · Confusing thermal cycling with vibration testing

4. 4You've brainstormed a long list of potential failure modes for a new power board and you have one afternoon before a design review to decide what actually gets mitigated. How do you decide which failure modes are worth your limited time?easy

   Answer this one, graded

   Or just show what a strong answer covers

   With limited time I'd rank the list by a rough combination of how bad the consequence is, how likely it is to happen, and how likely we'd be to catch it before it causes real damage -- basically severity, occurrence, and detectability. The ones I'd prioritize first are failure modes that are both severe and hard to detect, because those are the ones that slip through testing and show up as field failures or safety issues -- for example, on a power board, an overvoltage condition that silently degrades a downstream component over time is scarier than an LED that fails to light, even if the LED failure is more likely, because the LED failure is obvious and low-consequence while the overvoltage one could cascade and isn't easily caught in a quick functional test. I'd explicitly flag what I'm deferring -- lower severity, easily detectable issues -- and be ready to explain in the review why those are acceptable to leave for later rather than pretending the list is fully addressed.

   • Names a structured ranking approach — Describes ranking failure modes by some combination of severity (consequence), likelihood/occurrence, and detectability, rather than gut feel or whichever is easiest to fix.
   • Prioritizes undetectable+severe modes — Specifically calls out that failure modes which are both severe and hard to detect before shipping (or before causing damage) deserve attention first, even if individually less likely.
   • Acknowledges resource/time constraint explicitly — Explicitly ties the ranking decision to the one-afternoon constraint -- says what gets deferred and why that's an acceptable risk, not ignored.
   • Gives a concrete power-board example — Applies the reasoning to something plausible on a power board, e.g., an overvoltage event that damages downstream parts vs. a cosmetic LED failure.

   Where answers go wrong: Saying you'd try to mitigate everything on the list given more time, without triaging · Ranking only by likelihood and ignoring severity or detectability · Picking the failure modes that are simply easiest to fix rather than most important · Treating this as a checklist exercise rather than a judgment call under constraint

5. 5A handheld device will spend the night in an unheated delivery truck near freezing, then get carried first thing in the morning into a warm, humid warehouse. Which environmental test would you prioritize to catch failures caused by this specific use pattern, and what physical failure mechanism are you actually trying to expose?easy

   Answer this one, graded

   Or just show what a strong answer covers

   This use case is a classic setup for condensation, not just thermal stress. When the cold device is brought into warm humid air, moisture in the air condenses on and inside the enclosure because the device surface is below the local dew point. That moisture can bridge exposed contacts, corrode connectors, or cause intermittent shorts. I'd design a test that cold-soaks the unit near freezing, then transitions it into a warm, high-humidity chamber while it's powered and monitored, watching for shorts, leakage current spikes, or functional glitches during the transition rather than just checking it after it's dried out. I'd repeat that transition multiple times since field use will happen daily, and I'd inspect connectors and PCB surfaces afterward for corrosion or dendritic growth.

   • Identifies condensation as the mechanism — States that moving a cold object into warm humid air causes moisture to condense on internal/external surfaces.
   • Proposes a matching test — Describes a cold soak followed by transition into a warm humid chamber (or humidity cycling with dwell), not a generic thermal cycle or a dry high-temp soak.
   • Names the consequence — Mentions concrete failure modes from condensation such as electrical shorts, corrosion, or dendritic growth on exposed traces/connectors.
   • Mentions monitoring during test — Notes that the device should be powered/monitored during the transition to catch transient shorts, not just inspected after the fact.

   Where answers go wrong: Defaulting to a generic thermal cycling test (hot/cold extremes) without addressing the humidity/condensation angle. · Only inspecting the unit after the test instead of monitoring it live during the transition when a transient short would occur. · Focusing on solder joint fatigue, which is the failure mode for repeated thermal cycling, not this single cold-to-humid transition.

6. 6A batch of boards fails a vibration test -- you find cracked solder joints on one connector across several units. It would be fast to just resolder them and move the boards to the next test stage. Walk me through what you'd actually do instead, and why resoldering alone would be a mistake.medium

   Answer this one, graded

   Or just show what a strong answer covers

   I wouldn't resolder and move on, because that fixes the symptom, not the cause -- if the underlying reason the joint cracked is still present, it'll crack again in the field or on the next test. First I'd want to physically examine the failure: pull a failed unit, cross-section the joint or look at the fracture surface, and see whether it looks like a classic fatigue crack propagating from the edge of the joint, or whether there's a pre-existing defect like a void or poor wetting that concentrated stress there from the start. Then I'd look at the mechanics -- is this connector heavy or overhung relative to its support, is there a board resonance near the test frequency that could be amplifying displacement right at that location, is there any strain relief or adhesive missing that other similar connectors on the board have? I'd also check whether every failed unit cracked at the same joint and in the same pattern -- consistency points to a design or process issue, while randomness might point to workmanship variation. Only after I understand which of these it is would I propose a fix, whether that's mechanical support, a different joint geometry, or a process change -- and then I'd re-run the vibration test on the fixed design to confirm the actual cause is addressed, not just the visible crack.

   • Rejects resoldering as sufficient — Explicitly states resoldering only removes the symptom and doesn't explain why the joint cracked, so the failure would likely recur.
   • Proposes physical failure analysis — Describes examining the crack itself -- e.g., cross-section or optical/SEM inspection of the fracture surface -- to distinguish fatigue crack from a manufacturing defect (voids, insufficient wetting) versus mechanical overstress.
   • Considers mechanical root causes — Names plausible mechanical contributors: unsupported connector mass/overhang, board resonance at the test frequency, inadequate stake/adhesive, or connector too close to a fixed boundary.
   • Uses correlation to isolate variable — Suggests checking whether the failure correlates with a specific vibration frequency, connector orientation, or board location to narrow down cause rather than guessing.
   • Considers scope across the batch — Notes the need to check whether all failed units share the same failure mode/location, since inconsistency would point to workmanship rather than design.

   Where answers go wrong: Jumping straight to resoldering and retesting without investigating why it cracked · Assuming it's automatically a workmanship/soldering process issue without checking the mechanics · Not distinguishing a fatigue crack from a pre-existing defect (e.g., a cold joint) using fracture appearance · Skipping correlation with the vibration profile (frequency, axis) and treating it as random

7. 7You test 10 prototype units against a minimum operating voltage requirement of 2.7V. All 10 pass, and the lowest voltage at which any unit still worked was 2.85V. Someone on the team says 'great, we have 150mV of margin, we're done.' Do you agree? What would you want to know before signing off?medium

   Answer this one, graded

   Or just show what a strong answer covers

   I wouldn't say we're done yet. Ten units passing with the worst one at 2.85V is a good sign, but it's a small sample, and what we actually care about is the behavior of the whole population we'll eventually build -- thousands of units, each with its own combination of component tolerances. The worst unit in a production run could sit meaningfully lower than the worst of these 10, especially if any of the components involved have wide tolerances. I'd also want to know if 2.85V holds up across temperature -- some parts brown out earlier when cold or hot -- and whether it holds after the board has aged, since components can drift over time. Before I'd sign off, I'd want either a larger sample size to get a better read on the distribution, or a worst-case corner analysis using component tolerance data to estimate how low the minimum operating voltage could realistically go, so 150mV isn't just a comfortable-looking number from a handful of units but something backed by an actual estimate of tail risk.

   • Challenges the conclusion — States clearly that 'we're done' is premature and that 150mV observed across 10 units doesn't guarantee margin across the full population.
   • Raises sample size / tail risk — Explains that with only 10 samples, you haven't characterized the tail of the distribution -- a production run of thousands could include units closer to or below 2.7V even though none of these 10 were.
   • Asks about other stacking variables — Asks whether the 2.85V number holds across temperature extremes, aging/drift, and part-to-part variation (component tolerances), not just at room temp on fresh units.
   • Proposes a path to more confidence — Suggests concrete next steps: testing more units, worst-case corner analysis, or statistical modeling to estimate the probability of failure below spec.

   Where answers go wrong: Agreeing that 150mV is comfortable margin without questioning sample size · Not connecting the question to production yield / tail risk at all · Treating the margin as fixed rather than something that could shrink under temperature or aging · Suggesting an arbitrarily large sample size without justifying why more samples matter statistically

8. 8A voltage regulator's output must stay within 3.3V ± 5% for the unit to be considered good (so between 3.135V and 3.465V). Production data across many units shows a mean output of 3.32V with a standard deviation of 0.03V, and the distribution looks normal. Calculate the process capability index (Cpk) for this output, and tell me whether you'd feel comfortable shipping without 100% functional test based on that number.medium

   Cpk = min[(USL - mean)/(3σ), (mean - LSL)/(3σ)]

   Answer this one, graded

   Or just show what a strong answer covers

   First I find the distance from the mean to each limit: upper distance is 3.465 minus 3.32 equals 0.145, lower distance is 3.32 minus 3.135 equals 0.185. Dividing each by 3 sigma, which is 0.09, gives Cpu about 1.61 and Cpl about 2.06. Cpk is the minimum of those, so about 1.61, and the upper limit is the tighter constraint since the mean sits closer to it. A Cpk of 1.61 is comfortably above the common 1.33 threshold used as a rule of thumb for shipping without full functional screening, implying a very low expected defect rate assuming the distribution stays normal and stable. That said, I'd want to confirm this holds across temperature extremes and over the life of the part, not just from one production snapshot, since sigma can grow with aging or environmental drift.

   • Correct USL/LSL and Cpu/Cpl calc — Computes Cpu = (3.465-3.32)/(3*0.03) ≈ 1.61 and Cpl = (3.32-3.135)/(3*0.03) ≈ 2.06, and takes Cpk as the minimum ≈ 1.61.
   • Identifies the limiting side — States that the upper limit (Cpu) is the binding constraint since the mean sits closer to it than to the lower limit.
   • Interprets the number — Gives a reasoned judgment (e.g., Cpk of ~1.6 is generally healthy, above the common 1.33 threshold, implying very low expected out-of-spec rate) rather than just stating the number.
   • Notes limitations of the estimate — Mentions that this assumes the distribution stays normal and stable over time/temperature/aging, and that sample size affects confidence in the sigma estimate.

   Where answers go wrong: Using 6-sigma total spread instead of the one-sided 3-sigma distance to the nearer limit. · Forgetting Cpk is the *minimum* of the two one-sided indices, not an average. · Concluding a good Cpk means zero risk rather than a low but nonzero defect rate.

9. 9During environmental validation, 1 unit out of 30 fails intermittently at high temperature -- it works fine every time at room temperature. It's not consistently reproducible even at high temp; sometimes it passes there too. How would you approach isolating what's going on, and how would you decide whether this is a marginal design issue, a rare statistical outlier, or a flaw in the test itself?hard

   Answer this one, graded

   Or just show what a strong answer covers

   With only one intermittent failure out of 30, I don't have enough to root-cause yet, so my first goal is to get more data on the failure itself before forming a theory. I'd take that specific unit and try to make the failure happen more reliably -- hold it at the max temperature longer, power cycle it repeatedly, maybe sweep voltage or timing margin slightly if that's plausible for this kind of failure -- while adding extra instrumentation, like a scope or logger, so if it does fail again I actually capture what's happening electrically rather than just a pass/fail result. In parallel, I'd want to rule out the test setup itself -- swap the fixture, cable, or connector used for that unit and see if the intermittency follows the unit or stays with the fixture, since a flaky test rig can easily masquerade as a marginal design. If I can reproduce the failure reliably on that one unit and not on others even under the same aggressive conditions, that points toward something specific to that unit -- a marginal component, a workmanship defect, maybe visible under X-ray or by desoldering and inspecting. If instead a couple of the other 29 units start showing marginal behavior once I push them the same way, that tells me it's a design-level tail issue affecting some fraction of the population, not a single bad part. That distinction matters a lot for what happens next: a single bad unit might just need a screening test in production, while a design-level tail issue at 1-in-30 in a production run of thousands means real field failures and probably needs a design change before release.

   • Proposes increasing reproducibility before theorizing — Describes deliberately trying to make the failure happen more reliably -- e.g., holding at the highest temperature longer, adding voltage/timing margin stress, power cycling repeatedly -- rather than jumping to a root cause with one data point.
   • Separates unit-specific from population-level hypothesis — Explicitly frames the investigation as distinguishing 'is this one bad unit' from 'is this a rare tail event that 1-in-30 units of any batch would show', and proposes how to tell them apart (e.g., swap suspect components, retest failing unit extensively, check if any of the other 29 show any marginal signs).
   • Considers the test setup as a suspect — Raises the possibility that the fixture, connector, cable, or measurement chain itself is intermittent, and proposes a way to rule that out (e.g., swap fixtures, monitor with independent instrumentation).
   • Uses instrumentation to catch the failure in the act — Suggests adding logging, a scope, or extra monitoring during the high-temp test to capture what's actually happening electrically at the moment of failure, rather than only noting pass/fail after the fact.
   • Connects decision to risk framing — Ties the outcome of the investigation back to a risk-based decision (severity/likelihood) about whether this needs to block release, need a design change, or just needs a larger sample to characterize rate.

   Where answers go wrong: Dismissing it as a fluke and moving on because 29 of 30 units passed · Assuming it's automatically a bad unit without trying to reproduce or characterize the failure further · Not questioning whether the test fixture or cabling could itself be intermittent · Trying to root-cause from a single failure event without adding any additional monitoring or repeat testing · Ignoring the possibility that this represents a real tail probability that would affect a fraction of a large production run

10. 10A board passed every validation test on the bench, in the thermal chamber, and in vibration -- no issues at all. Six months after shipping, about 2% of units in the field start failing, but only in humid coastal regions; units in dry climates show no failures. Walk me through how you'd approach root-causing this, and what you think validation missed.hard

    Answer this one, graded

    Or just show what a strong answer covers

    I'd start by getting actual failed units back from the field rather than trying to reason from the correlation alone -- geography is a clue, not a root cause. I'd do failure analysis on them: visual inspection under magnification, checking for corrosion, discoloration, or dendritic growth on exposed pads or connectors, and probing to see exactly which node is failing. Given the humidity correlation and the multi-month delay, a strong candidate mechanism is electrochemical migration or corrosion at a spot with exposed metal and enough voltage bias -- something that needs sustained humidity exposure to grow, which explains why a short bench-level humidity test never caught it. That tells me our original environmental test was probably too short in duration or too low in relative humidity to accumulate that stress, or it didn't include a biased/powered humidity test at all. Once I confirm the mechanism, I'd propose an accelerated test, like a longer powered humidity soak or a HAST-style test, that reproduces the failure in a much shorter time, and use it to verify any design or coating fix before it ships again.

    • Prioritizes physical inspection of failed field units — States that the first step is obtaining actual failed units and doing failure analysis (visual/microscopy, cross-section, electrical probing) rather than only reviewing test reports.
    • Connects humidity correlation to a plausible mechanism — Proposes a specific mechanism consistent with humidity and time, such as electrochemical migration, corrosion of exposed pads/connectors, or conformal coating defects, not a vague 'moisture got in.'
    • Identifies the validation gap — Explains why the original humidity/thermal test likely didn't catch this -- e.g., too short a duration, wrong RH level, no cumulative/aging stress, or missing a specific coating/ingress check.
    • Proposes a closed-loop fix and verification — Describes updating the test plan (e.g., extended humidity soak, HAST, or biased humidity test) to catch the mechanism before shipping the fix, and re-validating.

    Where answers go wrong: Assuming it must be a workmanship/random defect without considering a time-dependent mechanism tied to humidity exposure. · Stopping at 'it's a humidity problem' without proposing a specific electrochemical or corrosion mechanism to explain the delay. · Proposing a fix without first confirming, via physical analysis of returned units, what's actually happening.