This page is for electronics engineers, from freshers to people who have shipped several boards. Hardware interviews usually mix circuit theory you can work on a whiteboard, practical questions about power supplies, layout and test equipment, and stories about boards that did not work the first time. Expect to be asked to calculate something small, like a gain or a cutoff frequency, and to explain your thinking out loud. Each question shows what the interviewer is really checking, a shape for your answer and a sample you could say. Replace the stories with your own boards before the day.
Search all questions by round, difficulty and level, or save the ones you want to practise.
Spark: the first thing you built or fixed that pulled you in.
Growth: the course, project or job where you got serious.
Next: the kind of circuits or products you want to work on, and why here fits.
"I started by repairing things at home, mostly chargers and speakers, and I was hooked the first time I found a dead capacitor and the thing worked again. In college I leaned toward analog and power, and my final-year project was a small battery charger with its own PCB, which taught me more than any exam did. In my last role I worked on sensor boards, doing schematics, bring-up and a lot of debugging on the bench. What I want next is more ownership of a board from requirement to production, especially the power and analog front end. That's why this role interested me, since your products seem to need both."
A vague love of 'technology' with nothing you have actually built, measured or fixed.
What they make: the products and the environment they run in.
What that means electrically: power source, noise, safety or size limits you'd expect.
Where you fit: the block you'd most like to own and the experience behind it.
"From your product pages, you make monitoring units that run in factories, powered from a 24 volt industrial supply and talking back over a wired bus. That tells me the electronics have to cope with noisy power, long cables and a lot of electrical interference, and they need to run for years without anyone touching them. The part I'd most like to work on is the power input and the interface circuits, the protection, filtering and the transceivers, because that's where industrial boards tend to fail. I've done input protection and a buck supply on my last board, so I'd be building on something I already know rather than starting cold."
Repeating the company slogan without any thought about what the circuits inside must handle.
Purpose: what the board does and its main constraints.
Your part: the specific blocks you designed and the key choices.
Hindsight: one or two things you would do differently on the next revision.
"The one I'm proudest of is a data logger board with four analog inputs, a microcontroller and a buck converter running from a 12 volt input. I did the full analog front end, which was op-amp buffers, anti-aliasing filters and input protection, plus the power supply. I also did the first layout pass, and a senior engineer reviewed it. It worked on the first spin apart from one footprint error on a connector. If I did it again, I'd put the ADC reference on its own filtered supply, because we saw a little noise from the digital side, and I'd add more test points. We ended up soldering wires on to probe signals during bring-up."
Describing the whole team's board as if you did everything, or saying you would change nothing.
Forward bias: the barrier shrinks and current flows once you pass roughly 0.6 to 0.7 volts for silicon.
Reverse bias: the depletion region widens and only a tiny leakage current flows until breakdown.
Zener use: built to break down at a set reverse voltage, so it's used for clamping and simple references.
"In a PN junction there's a depletion region at the boundary that acts like a barrier. When I forward bias it, positive on the P side, that barrier shrinks, and once I'm past about 0.6 to 0.7 volts for a silicon diode, current rises steeply. Reverse bias widens the depletion region, so only a tiny leakage current flows. If the reverse voltage gets high enough, the diode breaks down. An ordinary rectifier isn't meant to live there, but a Zener is designed to break down at a specific voltage and hold it fairly steady. So I'd use a Zener to clamp a signal, protect an input, or make a rough reference with a series resistor. For precise references, I'd use a proper reference IC."
Saying a reverse-biased diode conducts nothing at all and has no breakdown, or treating a Zener as a precision reference.
BJT: current-driven; size the base resistor so it saturates hard.
MOSFET: voltage-driven; pick one fully on at 3.3 volts of gate drive, add a gate pull-down.
Flyback diode: across the coil to catch the voltage spike at turn-off.
"Either can work, so I'd start from the coil current. A BJT is current-controlled, so for an NPN low-side switch I'd pick a base resistor that pushes enough current to saturate it well, not just the collector current divided by the typical gain. A MOSFET is voltage-controlled and draws current only while the gate charges, which is nice from a microcontroller pin, but I must pick a logic-level part whose on-resistance is specified at 2.5 or 3.3 volts on the gate, not just look at the threshold voltage. I'd add a pull-down on the gate so the relay stays off while the pin floats during reset. In both cases I put a diode across the coil, cathode to the 12 volt side, because the coil's current can't stop instantly and would otherwise spike the transistor."
Forgetting the flyback diode, or choosing a MOSFET by its threshold voltage alone.
Ideal rules: no input current, and with negative feedback the inputs sit at the same voltage.
Gain: one plus Rf over Rg, so 10.
Real limits: gain-bandwidth product, slew rate, output swing and input offset.
"Using the ideal rules, no current flows into the inputs, and with negative feedback the output drives the inverting input to match the non-inverting one. The divider sets the inverting input at the output times 10k over 100k, so the output must be ten times the input. The gain is one plus 90k over 10k, which is 10. In a real part, a few things limit that. The gain-bandwidth product means a 1 megahertz op-amp at a gain of 10 only gives about 100 kilohertz of bandwidth. Slew rate limits how fast large signals can change. The output can't swing all the way to the rails unless it's a rail-to-rail part, and input offset voltage gets multiplied by the gain too."
Getting the gain as 9 by using the inverting formula, or assuming the op-amp gives that gain at any frequency.
Formula: cutoff is 1 over 2 pi R C.
Values: pick a standard capacitor, then solve for R, keeping R sensible for the source and load.
Response: minus 3 dB at cutoff, then falling 20 dB per decade, with loading as the practical catch.
"The cutoff of a first-order RC filter is 1 over 2 pi R C. I'd start with a standard capacitor, say 100 nanofarads, and solve for R, which comes to about 1.6 kilohms. That gives a cutoff just under 1 kilohertz. At the cutoff the output is 3 dB down and the phase has shifted by 45 degrees. Above it, the output falls by 20 dB per decade, so a signal at 10 kilohertz comes out at roughly a tenth of its amplitude. The practical catch is loading. The source impedance adds to R, and whatever the filter drives sits in parallel with C, so if the load is heavy I'd buffer it with an op-amp. If I need a steeper roll-off, I'd use an active second-order filter rather than stacking plain RC stages."
Getting the formula without the 2 pi, or ignoring what the filter is driving.
Latch: level-sensitive, transparent while enable is active.
Flip-flop: edge-triggered, samples input only on the clock edge.
Divider: feed Q-bar back to D to divide by two, chain two stages to divide by four.
"A latch is level-sensitive. While its enable is active, the output follows the input, and it holds when enable goes inactive. A flip-flop is edge-triggered, so it only samples its input on the clock edge, which is why synchronous designs use flip-flops. To divide by two, I take a D flip-flop and feed its inverted output back to D. Every rising edge it toggles, so the output runs at half the clock. If I clock a second one from the first stage's output, I get divide by four. That's a ripple counter, and its weakness is that each stage adds delay, so the outputs don't change at exactly the same moment. If I decode those outputs, I can get glitches, so for anything wider I'd use a synchronous counter where every flip-flop shares one clock."
CLK --> [D FF 1] Q1 --> clock of [D FF 2] Q2
D1 = not Q1 D2 = not Q2
Q1 = CLK / 2, Q2 = CLK / 4
Saying a latch and a flip-flop are the same thing, or not knowing why ripple counters glitch.
Universal: any logic function can be built from NAND alone, or from NOR alone.
NOT and AND: tie a NAND's inputs together to invert; a NAND followed by that inverter is an AND.
OR: invert each input first, then NAND them, which is De Morgan's law.
"They're called universal because you can build any logic function from just one of them, so in principle a whole design could use a single gate type. With NAND, a NOT is easy. I tie both inputs together, so NAND of A with A is just not A. An AND is a NAND followed by that inverter, so two gates. For OR, I use De Morgan's law. A or B is the same as not the result of not A and not B, so I invert each input with a NAND and feed both into a third NAND. That's three gates. An XOR takes four. In CMOS, NAND is usually preferred over NOR, because a NAND puts its NMOS transistors in series, while a NOR stacks the slower PMOS transistors in series."
NOT A = NAND(A, A)
A AND B = NAND(NAND(A, B), NAND(A, B))
A OR B = NAND(NAND(A, A), NAND(B, B))
Not being able to derive the OR, or saying a gate is universal because it's cheap.
3.3 to 5: a 3.3 volt high may be below the 5 volt chip's minimum input high level.
5 to 3.3: a 5 volt signal can exceed the input rating and drive current through protection diodes.
Fixes: TTL-threshold inputs, level translators, dividers, or 5 volt tolerant pins.
"I look at the two directions separately. Going from 3.3 to 5 volts, the question is the receiver's input high threshold. A 5 volt CMOS input often wants about seven tenths of its supply, around 3.5 volts, so a 3.3 volt high may not be read reliably. If the chip has TTL-level inputs, like the HCT family, the threshold is around 2 volts and it's fine. Going from 5 down to 3.3, the risk is the microcontroller pin. Unless the datasheet says it's 5 volt tolerant, 5 volts drives current through its protection diodes into the 3.3 volt rail, which can damage it. For fixes, I'd use a proper level translator, a resistor divider for slow one-way signals, or a MOSFET-based shifter for an open-drain bus like I2C."
Saying 3.3 volts is always read as a high by 5 volt logic, or connecting 5 volts to any pin without checking.
Power: clean rails, decoupling at each pin, a filtered analog supply if it has one.
Clock and reset: crystal with the right load capacitors, a defined reset pin, boot pins strapped.
Access and protection: a programming or debug header, test points and protection on external connectors.
"I start with power. That means the right supply voltage, decoupling at every power pin, and if the chip has a separate analog supply or ADC reference pin, I filter that from the digital rail. Next is the clock. If it needs precise timing, I add a crystal with load capacitors calculated from the crystal's specified load, placed right at the pins. Then reset, so the reset pin sits in a defined state, often a pull-up with a small capacitor, plus any boot-mode pins strapped with resistors so it always boots from the right place. I always bring out the programming and debug pins to a header, add test points on the key rails, and put protection on anything that leaves the board, like a USB port or a sensor connector."
Leaving out the debug header or treating crystal load capacitors as any small value.
Step size: reference divided by 2 to the number of bits, about 0.8 millivolts here.
Sampling: sample faster than twice the highest frequency present, or it aliases.
Anti-alias filter: removes content above half the sample rate before the ADC sees it.
"One LSB is the reference divided by 2 to the 12th, so 3.3 volts over 4096, which is about 0.8 millivolts per step. That's the resolution on paper. The real accuracy also depends on the reference, noise and the ADC's own errors, so the effective bits are usually fewer than 12. The filter is about aliasing. The sampling theorem says I have to sample at more than twice the highest frequency in the signal. Anything above half the sample rate doesn't disappear. It folds back and shows up as a false lower frequency that I can't separate from the real signal afterwards. So I put a low-pass filter in front of the ADC with its cutoff well below half the sample rate, and I make sure its output can charge the ADC's sampling capacitor in time."
Believing the filter can be added later in software, or quoting 12-bit resolution as 12-bit accuracy.
R-2R: each bit switches its leg between reference and ground, contributing a binary-weighted share.
Output: reference times the code over 2 to the number of bits.
No DAC: filter a PWM output with a low-pass, trading ripple against response time.
"An R-2R ladder uses only two resistor values. Each bit drives a 2R leg that's switched to either the reference or ground, and the ladder is arranged so each bit contributes half as much as the one above it. The output ends up as the reference times the digital code divided by 2 to the number of bits. The nice part is you only need two well-matched values. On a microcontroller with no DAC, I'd use PWM and a low-pass filter. The average of a PWM signal is the duty cycle times the high voltage, and the filter strips out the switching. The trade-off is ripple against speed. A lower cutoff gives a smoother output but responds slowly to changes, so I'd run the PWM as fast as the resolution allows and maybe use a second-order filter."
Saying PWM is already an analog voltage with no filtering needed.
Baseline: short the input or use a known voltage to see the ADC's own noise.
Look for the pattern: use a scope and a capture of the samples to see if the noise is random or tied to a clock or supply.
Fix at the source: reference, grounding, filtering and source impedance, then average only what's left.
"First, I'd find out where the noise enters. I'd replace the sensor with a clean, known voltage, or short the input to ground, and see how much the reading still moves. That tells me if the ADC and reference are the problem, or the sensor path. Then I'd capture a few thousand samples and look at them. Random noise looks very different from noise at a fixed frequency, and a fixed frequency usually points to a switching regulator, a clock or a motor. I'd put the scope on the reference and the analog supply and look for ripple there. Common fixes are a cleaner reference, better filtering on the analog supply, an RC right at the ADC pin, a lower source impedance, and sampling when noisy parts aren't switching. Averaging comes last, for whatever random noise is left."
Going straight to averaging in software without asking where the noise comes from.
Linear loss: the voltage drop times the current becomes heat.
Numbers here: 8.7 volts times 0.5 amps is about 4.35 watts, too much.
Buck trade-off: far less heat, but switching noise, more parts and layout care.
"I'd do the power sum first. A linear regulator drops the difference as heat, so that's 12 minus 3.3, which is 8.7 volts, times half an amp, about 4.35 watts. That's more than twice the power the load actually uses, and a small regulator would need a big heatsink or would shut down. So here I'd use a buck converter, which converts the voltage by switching and wastes much less. The price is switching ripple and noise, an inductor, more careful layout, and some EMI work. If a sensitive analog block needs a very clean rail, I might follow the buck with a small low-dropout linear regulator, which only drops a few hundred millivolts and cleans up the ripple without much heat."
Picking a linear regulator without calculating the heat, or saying a buck converter is always better.
Operation: a switch chops the input, the inductor and output capacitor average it; duty cycle is roughly Vout over Vin.
Hot loop: input capacitor, high-side switch and low-side switch carry pulsed current; keep that loop tiny.
Sensitive parts: small switch node, feedback divider close to the chip and away from noise, solid ground.
"A buck converter switches the input on and off into an inductor. When the switch is on, the inductor current ramps up and feeds the load. When it's off, the low-side switch or diode keeps the current flowing and it ramps down. The output capacitor smooths the ripple, and in steady state the duty cycle is roughly output over input voltage. For layout, the most important thing is the loop through the input capacitor, the high-side switch and the low-side switch, because the current there turns on and off sharply every cycle. I keep that loop as small as possible, with the input capacitor right at the chip. I keep the switch node copper small, since it radiates, and I route the feedback divider close to the chip, away from the inductor and switch node, sensing at the output."
Describing the output loop as the critical one and placing the input capacitor wherever it fits.
Conduction loss: current squared times on-resistance, present at DC too.
Switching loss: each transition spends time with high voltage and high current together, and it scales with frequency.
Fixes: stronger gate drive, lower frequency, a better-suited part, or better cooling.
"When it's just on, the only loss is conduction loss, the current squared times the on-resistance, and that's small for a good part. With PWM I add switching loss. During every turn-on and turn-off there's a short time when the device has both a large voltage across it and a large current through it, and that energy is lost each transition, so the loss grows with frequency. The usual cause of slow transitions is weak gate drive. A microcontroller pin can only source a small current, so it takes a long time to charge the gate. It may not fully enhance the MOSFET at 3.3 volts either. I'd add a proper gate driver, check the gate charge in the datasheet, lower the PWM frequency if the application allows, and remember on-resistance rises as the part heats up."
Blaming only the on-resistance and picking a bigger MOSFET, which can make the gate even slower to drive.
Purpose: supply fast current spikes locally so the rail doesn't dip or spread noise.
Mix: small ceramics at each pin, plus bulk capacitance nearby.
Placement: as close as possible, short wide connections, vias straight to the planes.
"When a digital chip switches, it pulls short bursts of current. The supply further away can't deliver them fast because of the inductance of the traces between them. The decoupling capacitor sits right at the pin and supplies that burst locally, so the rail doesn't dip and the noise doesn't spread across the board. Usually I put a small ceramic, often 100 nanofarads, at each power pin, and a larger bulk capacitor nearby for slower changes. Placement matters more than the exact value. I put the capacitor as close to the pin as I can, keep the connection short, and drop vias straight to the power and ground planes. A capacitor at the end of a long, thin trace barely helps, because the trace inductance cancels out its benefit at high frequency."
Treating decoupling as a value to copy from a reference design while ignoring where the capacitor sits.
When: the trace delay becomes a meaningful fraction of the signal's rise time.
Controlled impedance: set by trace width, dielectric height and material, agreed with the fab via the stack-up.
Keep it clean: termination to stop reflections and an unbroken reference plane for the return current.
"It's the edge speed that matters, not the clock rate. A slow clock with very fast edges can still ring. Signals on ordinary FR-4 travel at roughly 15 centimetres per nanosecond. Once the trace delay is more than a small fraction of the rise time, a common rule of thumb says about a sixth, reflections from impedance changes start to show up as ringing and overshoot. Then I treat it as a transmission line. I design the trace to a target impedance, often 50 ohms single-ended, by setting width against the stack-up the fab confirms. I terminate it, usually a series resistor at the driver for point-to-point lines. And I route it over a solid reference plane, because the return current flows right under the trace. Crossing a gap in that plane forces a detour, which causes ringing and radiation."
Saying it only matters above some clock frequency, or ignoring where the return current flows.
Differential: the receiver reads the difference between two wires, so noise hitting both cancels.
Ground offset: it tolerates a difference in ground voltage between distant ends, within its common-mode range.
Wiring: twisted pair, termination at both ends of the bus, bias for a defined idle state.
"A single-ended signal is measured against ground, so any noise picked up along the cable or any difference in ground voltage between the two ends lands directly on the signal. With a differential pair, the transmitter drives two wires in opposite directions and the receiver only looks at the difference between them. Noise from a motor or a long cable run tends to hit both wires equally, so it cancels out. That's why RS-485 can run over long distances and let several nodes share one pair. To get that benefit, I use twisted pair cable, put termination resistors matching the cable impedance at the two far ends of the bus, not on every node, and add biasing so the line sits in a known state when nobody is transmitting."
Saying differential signalling just means using two wires for more current, or terminating every node.
Identify: match the frequency to clocks, switching regulators and their harmonics.
Locate: use a near-field probe and cables to find what's radiating.
Fix and verify: the smallest change first, like filtering, snubbing or edge slowing, then pre-scan before retesting.
"I'd start with the frequency. I'd list every clock, switching regulator and fast interface on the board and check whether the spike is one of them or a harmonic. Then I'd find where it's coming from. I'd use a near-field probe on a spectrum analyser to scan the board, and I'd check the cables, because a cable acting as an antenna is a very common cause. If unplugging a cable changes the spike, that's a strong clue. For the fix, I'd try the least invasive options first, like a ferrite or common-mode choke on the cable, a series resistor to slow a fast edge, a snubber on a switch node, or spread-spectrum if the clock allows it. I'd pre-scan each change myself before booking the lab again, and note which fixes need a layout change for the next revision."
Adding shielding everywhere and hoping, with no attempt to find the source.
Bandwidth: the scope and probe must be fast enough for the edge you're measuring.
Probe: compensate the 10x probe, and replace the long ground lead with a short spring tip.
Ripple: AC coupling, bandwidth limit, probe right at the output capacitor.
"First, I check bandwidth. A rough rule is that the rise time a system can show is about 0.35 divided by its bandwidth, so a 100 megahertz scope can't show edges much faster than about 3.5 nanoseconds. Next is the probe. I compensate a 10x probe on the scope's calibration square wave, and for fast edges I drop the long ground clip. That clip forms an inductive loop that adds ringing that isn't really on the board, so I use a short spring ground right at the point I'm measuring. For supply ripple, I use AC coupling so I can zoom in, turn on the bandwidth limit if I only care about low-frequency ripple, and measure right across the output capacitor with that short ground, so I'm not picking up the switching noise through the air."
Blaming the circuit for ringing you created with a long ground lead.
Series, not parallel: break the circuit, move the lead to the current jack and pick a range.
Burden voltage: the meter's shunt drops voltage, which can upset a low-voltage circuit.
Common mistakes: leaving the lead in the current jack, measuring resistance with power on or in circuit.
"Current is measured in series, so I break the supply path, often at a jumper or by lifting a link, move the red lead to the current jack, and start on a high range. The catch is that the meter measures current through a small internal resistor, so it drops some voltage, which is called burden voltage. On a microamp range that drop can be large enough to make a 3.3 volt microcontroller brown out when it wakes up, so the reading looks odd or the board resets. The classic mistake is leaving the lead in the current jack and then touching it across a supply to measure voltage. That's a dead short through the meter and it blows the fuse. I also only measure resistance with power off, and remember that in circuit I'm reading every parallel path too."
Putting the meter across the supply to read current, or not knowing the meter itself changes the circuit.
Symptom: what failed, how often, and why it was hard.
Narrowing: the measurements and experiments that ruled things out.
Root cause and fix: what it really was and how you proved it.
"At my last company, a motor controller board would randomly reset, maybe once an hour, and only with the motor under load. Firmware was the first suspect, but the reset flags showed a brownout, so I moved to power. I put the scope on the 3.3 volt rail and triggered on a dip, and I caught short drops each time the motor current stepped up. The regulator itself was fine. The cause was the layout. The motor's return current shared a thin ground path with the logic supply, so every current spike lifted the logic ground. I proved it by adding a thick jumper wire to separate the returns, and the resets stopped completely. On the next revision, we split the high-current return and joined the grounds at one point near the input."
A story where the fix came from swapping random parts, with no measurement that proved the cause.
Protect: power off, then retry only from a current-limited supply.
Look and measure: inspect for orientation and solder faults, measure each rail's resistance to ground.
Isolate: find the hot part, split rails at links or regulators, compare with a second board.
"First, I'd switch it off and only power it again from a bench supply with a low current limit, so nothing burns while I look. Then I'd inspect it under magnification, checking the orientation of diodes, polarised capacitors and ICs, and looking for solder bridges, especially on fine-pitch parts. Next, with power off, I'd measure the resistance from each rail to ground and compare against a known-good board or what I expect. A very low reading tells me which rail to chase. With the current limited, I'd look for the part that heats up, using a thermal camera or a careful finger. If the rails are joined, I'd lift a zero-ohm link or a regulator output to split them. I'd also check whether a second board from the same batch shows the same fault."
Turning the supply up to 'see what happens', or starting to swap parts before measuring anything.
Mistake: what it was, stated plainly.
Impact: how it was found and what it cost in time or boards.
Change: the check or habit you added so it doesn't happen again.
"On one board, I used a voltage regulator footprint from our library without checking the pin order against the datasheet. That footprint was for a different variant with the input and output swapped. It was caught at bring-up when the rail came up wrong on the first board I powered, and luckily I was using a current-limited supply, so nothing burned. We fixed the prototypes by lifting and rewiring the part, which cost a couple of days, and the next spin fixed it properly. What I changed is that I now check every new or reused footprint against the actual datasheet pinout, and I print the power section and trace each rail by hand before sending files out. I also power every new board from a current-limited supply first."
Picking a mistake that was really someone else's fault, or one with no change in process after.
Situation: which part, and the pressure on the schedule.
Checks: pinout, electrical specs, behaviour at the corners, and testing on real boards.
Result: what you shipped and what you did to reduce the risk next time.
"In my last role, the op-amp on our sensor board went on long allocation right before a production run. The distributor offered a pin-compatible part from another maker. I didn't assume it was drop-in. I compared the datasheets line by line, including input offset, bias current, output swing near the rails and stability with our capacitive load, and found its input bias current was much higher, which mattered because we had a high-value resistor in the input path. I tested it on a few boards anyway, and the offset error was visible. So I picked a different substitute with a lower bias current, tested it across temperature on the bench, and got it approved. Afterwards we started listing a checked second source for critical parts on every new design."
Swapping in a 'compatible' part from pinout alone with no electrical check or test.
Assess risk: what the wire carries and how it could fail with vibration, heat or handling.
Control it: a written rework instruction, fixing and inspection, and testing on reworked boards.
Decide openly: put the risk in writing and agree on when the proper revision takes over.
"I wouldn't say no by reflex, because reworked boards do ship sometimes. It depends on what that wire is doing. First, I'd look at the risk. Is it a low-speed signal or a power path, and will the product see vibration or temperature swings that could break the joint? If it's reasonable, I'd make it controlled. That means a written rework instruction with photos, the wire glued down so it can't flex, a clear inspection step, and a sample of reworked boards through the same stress testing as normal. I'd also want the batch size limited and the date for the new revision agreed. If the wire carries a fast signal or high current, I'd show my manager why the risk of field failures outweighs the delay, and suggest shipping fewer units first."
Either agreeing silently with no controls, or refusing without looking at the actual risk.
Disagreement: what each side wanted and why.
How you handled it: evidence, test or trade-off you brought.
Outcome: what was decided and how the relationship stayed.
"At my last company, the firmware engineer wanted every spare pin routed to a header so he'd have flexibility, and I wanted to keep the board small and the routing clean around a sensitive ADC. We were both right about something. Instead of arguing in the abstract, I sat with him and we went through what he actually expected to need. It came down to a debug UART, two spare GPIOs and a test pad on the reset line. I routed those to a small header away from the analog section and left the rest unrouted. He got what he actually needed, the analog layout stayed clean, and afterwards he started bringing his pin requests to the schematic review early, which saved us both time."
A story where you simply overruled the other person, or where the disagreement is still going.
Context: who needed to understand and what decision they had to make.
Translation: how you explained it without jargon.
Result: what they decided and whether it worked.
"Our product manager wanted to know why a board revision would push the schedule back by three weeks for what looked like a tiny change. The real issue was that the new radio module needed a different antenna layout, which meant new boards, new testing and a repeat of the emissions test. Instead of talking about ground planes, I drew the board on a whiteboard, showed which area had to change, and listed the three steps that each took about a week. Then I gave him two options, ship the old module now or wait for the better range. Once he saw the choice in terms of time and what the customer would get, he decided in the meeting, and he later asked me to join the customer call to explain it."
Blaming the listener for not understanding, or explaining with more jargon.
Before: share the design early with the requirements and your open questions.
During: go through power, interfaces, footprints and testability, and welcome hard questions.
After: track every comment to closed, and thank people who found problems.
"To me, a good review happens early enough that changes are still cheap. I send the schematic with the requirements and a short list of the things I'm least sure about, so people spend their time where it matters. In the review, we go through the power tree, every connector and interface, footprints for new parts, and whether the board can be tested and debugged. I honestly want people to pick it apart, because a comment in a review costs an hour, and the same mistake on a fabricated board costs weeks. If I disagree with a comment, I explain my reasoning, but I don't take it personally. After the review, I log every comment and close each one, so nothing gets lost before release."
Treating reviews as a formality or getting defensive when someone finds a real problem.
Before: isolate supplies, and know where the stored energy is on the board.
While working: discharge and verify with a meter, use isolation or proper differential probes, one hand where you can.
Team: label live setups, never leave them unattended, and speak up when you see risk.
"I treat anything connected to mains as dangerous until I've proven it isn't. Before I touch a board, I switch off and unplug it, and I remember that big capacitors can hold a charge long after power is gone. So I discharge them through a proper resistor and then check with a meter before touching anything. When I have to measure a live mains circuit, I use an isolation transformer or a proper differential probe, not a normal scope probe with the ground clip on the wrong node. I keep one hand out of the circuit where I can. For the team, I label live setups clearly and never leave one running unattended. If I see someone working in a way that looks risky, I say so, even if they're more senior."
Saying you're careful without naming a single concrete habit, or treating capacitors as safe once power is off.
ClapAssist is an AI interview assistant for Mac and Windows. It listens to the interview on your computer and shows you what to say, in short lines you can read while you talk. Your resume and notes are never stored on our servers. It stays out of screen share on every plan; only you can see it.