Behavioral & Communication interview questions

10 questions, easiest first

1. 1Tell me about a time in a class, lab, or personal project when a circuit or system did not behave the way you expected. Walk me through what happened, what you actually did step by step, and how it turned out -- keep it to the parts that matter.intro

   Answer this one, graded

   Or just show what a strong answer covers

   In a microcontroller lab, a servo I was driving jittered even after I rewrote the control code twice. Instead of guessing at code again, I put a scope on the supply rail and saw the voltage sagging every time the servo drew current -- so it wasn't a software timing issue, it was the power supply. I added a local decoupling cap and separated the servo's supply from the logic supply, and the jitter disappeared. I learned to check power integrity with a scope before assuming a control problem is in software.

   • Concrete situation stated — Answer names a specific system, symptom, and context rather than speaking in generalities.
   • Specific sequence of actions — Answer lists actual diagnostic or corrective steps taken, in the order taken, not just a summary like 'I debugged it'.
   • Observable result given — Answer states what changed or was confirmed as a result of the actions, not just that the problem 'got fixed'.
   • Reflection or lesson stated — Answer names something learned or something they would do differently next time, tied to the specific event.

   Where answers go wrong: Answering with a general self-description like 'I'm good at troubleshooting' instead of a specific event. · Skipping straight from problem to solution with no steps in between. · Including irrelevant backstory that does not affect the outcome. · Ending without stating what was learned or what would change next time.

2. 2During a design review, your mentor asks you a direct question about a component spec you have not actually looked up yet. Walk me through exactly what you say in that moment, and what you do in the hour right after the meeting.intro

   Answer this one, graded

   Or just show what a strong answer covers

   I'd say directly, 'I don't have that number memorized, but here's what I do know—it's likely in this range because of X, and here's why it matters for what we're discussing.' I wouldn't invent a figure just to seem prepared. Right after the meeting, I'd pull the datasheet, confirm the value, and send a quick follow-up message to whoever asked within the hour so it doesn't just sit unresolved. I'd frame it as normal—engineers don't have every spec memorized, what matters is closing the loop fast and not guessing when a wrong number could mislead a decision.

   • States the gap directly — Answer explicitly says something equivalent to 'I don't know that number' rather than hedging or bluffing with a guess dressed up as fact.
   • Uses adjacent knowledge productively — Mentions reasoning from related things they do know (e.g., typical range, why it matters) instead of just stopping at 'I don't know.'
   • Names a concrete follow-up — Describes a specific action with a timeframe, e.g., pulling the datasheet within the hour and reporting back, not just 'I'll look into it.'
   • Maintains composure and credibility — Answer doesn't over-apologize or spiral; frames not knowing as normal and recoverable.

   Where answers go wrong: Guessing a plausible-sounding number to avoid looking unprepared. · Saying 'I don't know' and treating that as the end of the answer with no follow-up plan. · Over-apologizing in a way that undermines confidence in front of the room.

3. 3Imagine a project lead with no electronics background asks you, in the hallway, why the board you're testing keeps drawing too much current and why the fix will take two more days. Explain it to them exactly the way you actually would, out loud.easy

   This question is about calibrating depth for the listener, not about diagnosing the electronics itself.

   Answer this one, graded

   Or just show what a strong answer covers

   I'd say: the board is pulling more electricity than it's designed to, kind of like a hose with too much water pushed through it -- that usually means a part is shorted or drawing more current than it should. I need two more days because instead of guessing which part is bad and risking damaging something else, I have to test each section with an instrument, isolate the exact component, and confirm the fix works before we build more boards this way.

   • Plain-language cause given — States the actual technical cause (e.g., excess current draw, likely short or faulty part) in words a non-engineer would understand, without dropping the substance.
   • No unexplained jargon — Any technical term used is either avoided or immediately translated in the same breath.
   • Timeline tied to reasoning — Explains why two days specifically -- what steps take that long -- rather than just asserting the number.
   • Respects listener's intelligence — Explanation is not condescending and gives enough real information for the listener to make a decision.

   Where answers go wrong: Using terms like 'overcurrent fault on the rail' without translating them. · Giving a timeline with no reasoning behind it ('it'll just take two days'). · Being so simplified that no real information is conveyed at all. · Sounding dismissive or talking down to the non-technical listener.

4. 4You're in a lab session and your mentor points at your test data and asks why the measured value doesn't match your hand calculation by about 20%. You genuinely don't have an explanation yet. What do you actually say in that moment, and what do you do in the next ten minutes?easy

   Answer this one, graded

   Or just show what a strong answer covers

   I'd say I don't have an explanation yet, but here's how I'd find out. First I'd check the measurement itself -- is the meter on the right range, is the probe placement correct, am I measuring what I think I'm measuring. Second I'd re-check my calculation's assumptions -- right component values, right formula, right units. I'd repeat the measurement once to rule out a fluke, then come back with either an explanation or a narrowed-down list of what it isn't.

   • States uncertainty directly — Explicitly says they don't know the cause yet, without inventing a plausible-sounding guess as if it were fact.
   • Names concrete diagnostic actions — Lists specific checks (e.g., verify measurement setup, re-check calculation assumptions, repeat measurement) rather than a vague 'I'll investigate'.
   • Distinguishes error sources — Separates possible measurement error from possible model/calculation error as different categories to check.
   • Commits to follow-up — States they will report back with an answer rather than leaving it open-ended.

   Where answers go wrong: Guessing a plausible-sounding cause on the spot and stating it with confidence. · Saying 'I don't know' and stopping there with no plan. · Blaming the equipment immediately without checking it. · Getting flustered and changing the subject instead of addressing the gap.

5. 5Tell me about a time you had limited time before a lab checkoff, demo, or project deadline and had to decide which of several possible problems to chase first. Walk me through it with a clear structure so I can follow exactly how you decided.easy

   Answer this one, graded

   Or just show what a strong answer covers

   In a lab session we had about 40 minutes before checkoff and two things looked wrong: the output voltage was slightly off and there was intermittent noise on one line. I chose to chase the noise first because if it was a wiring or ground issue it could be masking the voltage problem too, and it was the cheaper thing to rule out with a scope probe. I checked ground connections, found a floating reference, fixed it, and the voltage reading came back in spec on its own—so one fix solved both symptoms and we passed checkoff with about 10 minutes to spare.

   • Concrete constraint stated — Names a specific, real time or resource limit (e.g., '90 minutes before the checkoff') rather than a vague 'we were busy.'
   • Explicit decision criterion — States the actual reasoning used to prioritize one issue over others (e.g., highest risk to demo, cheapest to test first, most likely root cause).
   • Action matches the stated reasoning — The action taken logically follows from the stated prioritization, not a disconnected narrative.
   • Concrete, checkable result — Result is specific and verifiable (passed checkoff, found root cause, ran out of time and here's what happened) rather than 'it worked out.'
   • No irrelevant tangents — Answer stays on the decision and its outcome without wandering into unrelated background.

   Where answers go wrong: Describing everything that happened in order with no clear decision point highlighted. · Never actually stating why one problem was chosen over another. · Ending with a vague, unverifiable result like 'it turned out fine.'

6. 6A teammate on a group project chose a decoupling capacitor value that you think is wrong based on the datasheet you read, but they have more hands-on experience than you and sound confident in their choice. How do you bring this up, and what happens if they give you a reason you hadn't considered?medium

   Answer this one, graded

   Or just show what a strong answer covers

   I'd bring the datasheet section and my specific reasoning and ask them to walk me through their choice, since they might know a practical reason -- like a supply chain issue or a prior failure with that value -- that I'm not aware of. If their explanation directly addresses what I read, I'd say 'okay, that makes sense, I was missing that' and move on. If it doesn't fully address my concern, I'd suggest we test both in simulation or on the bench, or check with someone else, rather than just leaving it as an unresolved disagreement.

   • Leads with evidence, not authority — Brings a specific datasheet reference or reasoning rather than 'I think this is wrong' or deferring purely because of the teammate's seniority.
   • Frames as inquiry, not accusation — Poses the disagreement as a question inviting the teammate's reasoning rather than a correction or challenge.
   • Updates on better evidence — Explicitly states they would change their position if the teammate's explanation addresses their concern with solid reasoning.
   • Has a path if unresolved — Names a concrete next step (test it, check another source, ask a third party) if the disagreement isn't settled by discussion alone.

   Where answers go wrong: Silently going along with the choice despite having a documented concern. · Insisting on being right without actually listening to the counter-reasoning. · Framing the disagreement as 'you're wrong' instead of 'I noticed X, can you walk me through why you chose this'. · Refusing to update even after being shown solid counter-evidence.

7. 7Describe a time you had to present a technical result -- from a lab, a class project, or a personal build -- to a mixed audience where some people were engineers and some were not. How did you decide what to include and what to leave out?medium

   Answer this one, graded

   Or just show what a strong answer covers

   For a class project on a sensor board, I presented to both the professor and a group of non-technical classmates grading on communication. I led with the result -- the sensor met the accuracy target -- before any circuit detail, then gave a one-slide analogy for how the calibration worked for the non-technical listeners, and kept the actual filter math and component values available only if someone asked. One engineer did ask about the filter cutoff, so I answered that live without dragging the rest of the room through it. Afterward the non-technical listeners could restate the main result correctly, which told me the structure worked.

   • Real, specific example given — Describes an actual event with a real audience and content, not a hypothetical or generic description of good presenting.
   • States audience segmentation strategy — Explains how depth or vocabulary was adjusted for different listeners, e.g., leading with the takeaway before optional technical detail.
   • Names a specific detail cut or kept — Gives at least one concrete example of a detail that was deliberately included or excluded and the reasoning.
   • States the outcome — Describes how the audience responded or whether understanding was actually achieved, not just that the talk happened.

   Where answers go wrong: Describing only what was said, with no reasoning about why those choices were made. · Giving a purely hypothetical answer with no real event. · Treating the whole audience as uniform instead of addressing the mixed backgrounds explicitly. · Ending without any indication of whether the communication actually landed.

8. 8A project stakeholder with no electronics background needs to decide whether to ship a sensor board, even though you've noticed on the bench that its output is noisier than the spec calls for. Explain to them, in the way you'd actually say it out loud, what that noise means for the decision they have to make.medium

   Answer this one, graded

   Or just show what a strong answer covers

   I'd say: 'When we tested the board, the sensor's readings jitter around a bit more than they're supposed to—think of it like a scale that sometimes shows a pound or two off even when nothing's on it. Most of the time this won't matter, but in specific conditions it could give a reading that's noticeably wrong. My recommendation is we either add a quick filter that should fix most of it in a day or two, or we ship now but flag that this feature isn't reliable for precision use yet. Does that tradeoff make sense, or do you want me to go into more of the technical detail?' That gives them the real consequence, a path forward, and a chance to ask more.

   • States the consequence, not just the fact — Explains what the noise actually does to the product/decision (e.g., 'readings could be off by X in edge cases') rather than just repeating 'the noise is above spec.'
   • Avoids unexplained jargon — Any technical term used (e.g., noise, spec, ADC) is either avoided or immediately grounded in plain consequence.
   • Gives an actionable recommendation or tradeoff — Doesn't just describe the problem; offers a clear recommendation (ship with caveat, delay to fix, ship for non-critical use only) with reasoning.
   • Checks for understanding / invites questions — Answer includes a moment of confirming the listener follows or asking if they want more detail before proceeding.

   Where answers go wrong: Reciting the measured noise numbers without explaining what they mean for the product decision. · Oversimplifying to the point of hiding the real risk from the stakeholder. · Making the recommendation without giving the stakeholder any reasoning to evaluate it themselves.

9. 9You and a senior engineer disagree about the root cause of an intermittent hardware failure. You ran one test that supports your theory, but it's not conclusive -- there's a plausible alternative explanation you haven't ruled out yet. In a design review, how do you present your position, and what do you do if it later turns out you were wrong?hard

   Answer this one, graded

   Or just show what a strong answer covers

   I'd present the test result plainly -- say it's consistent with my theory but not conclusive -- and name the alternative explanation myself before anyone else raises it, since hiding it just delays the real answer. I'd propose a specific follow-up test that would separate the two theories cleanly, and suggest we hold off on committing a fix until that test runs. If it later shows my theory was wrong, I'd say directly 'the follow-up test ruled out my explanation, here's what it actually points to instead' and move on to what we do next, rather than dwelling on having been wrong.

   • States confidence level explicitly — Explicitly labels the supporting test as suggestive, not conclusive, rather than presenting it as proof.
   • Names the alternative explanation unprompted — Voluntarily raises the plausible alternative cause instead of waiting to be challenged on it.
   • Proposes a discriminating test — Suggests a specific next test or measurement designed to distinguish between the two explanations before committing resources.
   • Handles being wrong without defensiveness — Describes acknowledging the disproof directly and factually, sharing what was learned, without minimizing or over-apologizing.

   Where answers go wrong: Presenting the one supportive test as if it were proof of the theory. · Hiding or downplaying the alternative explanation to keep the argument winnable. · Becoming defensive or making excuses when later proven wrong. · Over-apologizing to the point of undermining credibility instead of just stating the correction and next step.

10. 10You're on a small team and a senior engineer wants to skip a specific test to save time, arguing it's unlikely to catch anything new. You suspect that exact test is the one that would catch a failure mode you're worried about, but you don't have hard data to prove it. Walk me through how you'd handle that conversation.hard

    Answer this one, graded

    Or just show what a strong answer covers

    I'd say something like, 'I hear that this test hasn't caught anything before, but I'm specifically worried about failure mode X because of Y, and I don't think our other tests exercise that path. I don't have hard proof this will happen, so I could be wrong—but given the cost of missing it, could we run a stripped-down version of the test, maybe 15 minutes instead of the full hour, just to check?' If that comes back clean, I'd drop the concern and move on. If it shows something, we've caught it cheaply. The key is I'm not just asserting I'm right—I'm proposing the fastest way to find out who's right, and I'm genuinely willing to be wrong.

    • States concern with reasoning — Explains the specific failure mode and why this test is the one likely to catch it, not just 'I have a bad feeling.'
    • Explicitly owns the uncertainty — Says clearly that the concern isn't proven and gives an honest sense of confidence rather than overstating certainty to win the argument.
    • Proposes a concrete way to resolve it — Suggests a specific, time-boxed way to get evidence (e.g., a quick reduced version of the test, checking past failure data) rather than just repeating the disagreement.
    • Stays open to being wrong — Answer includes willingness to drop the concern if the quick check comes back clean, rather than digging in regardless of outcome.

    Where answers go wrong: Deferring immediately to seniority without voicing the concern at all. · Overstating certainty about the failure mode to make the argument stronger than the evidence supports. · Refusing to accept the test being skipped even after a reasonable check comes back clean.