Foxconn NPI FA — Interview Prep

Electronics Engineer • NPI FA&DOE Engineering • Bangalore

Loading countdown...
15
Sections
80+
Questions
0
Done
✎ Quick Notes — Jot anything here
Study Checklist 0 of 16 done
HIGH
HIGH
HIGH
HIGH
HIGH
HIGH
MED
MED
MED
MED
HIGH
HIGH
HIGH
HIGH
HIGH
HIGH
01 Electronics Fundamentals

Ohm's Law & Power Laws DEFINITELY ASKED

Ohm's Law is the single most fundamental law in electronics. Everything else builds on it. It says that the voltage across a component is directly proportional to the current flowing through it, and the constant of proportionality is resistance.

V = I × R

V = Voltage in Volts (V). Think of voltage as pressure — it's the "push" that drives current through a circuit.
I = Current in Amperes (A). Think of current as the flow rate — how many electrons are moving per second.
R = Resistance in Ohms (Ω). Think of resistance as friction — it opposes the flow of current.

From V = IR, you can derive two more forms: I = V/R (current increases when resistance decreases) and R = V/I (resistance is how much a component opposes current).

Power Laws — How much energy is consumed

Power (P) measured in Watts tells you how much energy a component uses or dissipates as heat per second. There are three forms — all derived from each other using Ohm's Law:

P = V × I   |   P = I² × R   |   P = V² / R

Use whichever form matches what you know. If you know voltage and current, use P = VI. If you only know current and resistance, use P = I²R. The I²R form is particularly important because it shows why high current causes overheating — power increases with the square of current. Double the current = four times the heat.

Worked examples — the type they ask verbally

A 100Ω resistor has 5V across it. What current flows? What power does it dissipate?
I = V/R = 5/100 = 0.05A = 50mA. Power = V×I = 5 × 0.05 = 0.25W. Or P = V²/R = 25/100 = 0.25W. Same answer either way. A standard ¼W (0.25W) resistor would be right at its limit — you'd normally use a ½W resistor here to be safe.
A motor draws 2A from a 12V supply. What power is it consuming?
P = V × I = 12 × 2 = 24W. If the motor is 80% efficient, it delivers 24 × 0.8 = 19.2W of mechanical power and wastes 4.8W as heat.
A wire has 0.5Ω resistance and carries 3A. How much power is wasted in the wire?
P = I²R = 9 × 0.5 = 4.5W lost as heat in the wire. This is why power cables must be sized correctly — thin wires = high resistance = excessive heat = fire risk.

Kirchhoff's Current Law (KCL)

The sum of all currents entering a node (junction) equals the sum of all currents leaving it. In other words, current cannot accumulate — whatever flows in must flow out. This is conservation of charge.

Example: if 3A flows into a junction from one wire and 1A flows out through another wire, then 2A must flow out through a third wire. You can always use this to find an unknown current.

Kirchhoff's Voltage Law (KVL)

The sum of all voltages around any closed loop in a circuit equals zero. Voltage rises (from sources like batteries) equal voltage drops (across resistors, components). This is conservation of energy.

Example: a 9V battery connected to two resistors in series — if one resistor drops 4V, the other must drop exactly 5V, because 9 − 4 − 5 = 0.

My notes

Passive Components — Resistors, Capacitors, Inductors, Diodes DEFINITELY ASKED

Resistors

A resistor limits current flow. It dissipates electrical energy as heat. Resistors are used to: set current through LEDs, create voltage dividers, pull signals to known voltage levels, limit inrush current, and set gain in amplifiers.

Colour code (4-band): first two bands = digits, third band = multiplier, fourth = tolerance. Mnemonic: Black Brown Red Orange Yellow Green Blue Violet Grey White = 0 1 2 3 4 5 6 7 8 9. So Brown-Black-Red = 1, 0, ×100 = 1000Ω = 1kΩ.

Standard values follow the E12 series: 1.0, 1.2, 1.5, 1.8, 2.2, 2.7, 3.3, 3.9, 4.7, 5.6, 6.8, 8.2 — then repeat at ×10. This is why you use 4.7kΩ pull-ups, not 5kΩ.

Series and Parallel Resistors

Series: R_total = R1 + R2 + R3 (resistances add directly)
Parallel: 1/R_total = 1/R1 + 1/R2 (for two: R = R1×R2 / R1+R2)

Series resistors divide voltage. Parallel resistors divide current. In series, more resistance → more voltage drop across that resistor. Two equal resistors in parallel give half the resistance of one.

Voltage divider: two resistors in series from VCC to GND. Output voltage tapped between them = VCC × R2/(R1+R2). Used to scale a 5V signal down to 3.3V for a microcontroller input, or to set a reference voltage.

Capacitors

A capacitor stores energy in an electric field between two conducting plates separated by an insulator (dielectric). It opposes changes in voltage. Key behaviour: it charges up to the supply voltage, then stops conducting. So in DC steady state, a capacitor is an open circuit. In AC circuits, it passes current — higher frequency = lower opposition (impedance).

Energy stored = ½ × C × V² (in Joules)
Time constant τ = R × C (time for cap to charge to 63% of supply voltage)

Types: Ceramic (non-polarised, small values, for decoupling — 100nF near IC power pins), Electrolytic (polarised, large values, for bulk filtering — 10–1000µF), Tantalum (compact electrolytic, more stable), Film (precision, audio).

CRITICAL: Electrolytic capacitors have a positive and negative lead. Connect backwards and they will overheat, swell, and potentially explode. The negative lead is marked with a stripe. Always check polarity.

Series caps: total capacitance decreases (same formula as parallel resistors). Parallel caps: total capacitance adds up. When you add a 10µF and 100nF in parallel near an IC, you get 10.0001µF — the 10µF handles low-frequency bulk demand, the 100nF handles high-frequency transients (because it has lower inductance and responds faster).

Decoupling capacitors: when an IC switches internally, it demands a sudden burst of current. Without a cap nearby, this current must travel from the power supply through long traces — those traces have inductance which causes voltage spikes. A 100nF cap placed right next to the IC's VCC pin supplies that burst current instantly, keeping the power rail clean.

Inductors

An inductor stores energy in a magnetic field when current flows through a coil of wire. It opposes changes in current (the dual of a capacitor). In DC steady state, an inductor is a short circuit (just wire resistance). In AC circuits, it opposes high-frequency current — higher frequency = higher impedance.

Inductors are used in: switching power supplies (buck/boost converters), EMI filters, RF tuning circuits, and current sensing. You'll mostly encounter them in power supply designs at Foxconn.

Diodes

A diode allows current to flow in one direction only — from anode (+) to cathode (−). The cathode is marked with a stripe on the component body. Silicon diodes have a forward voltage drop of approximately 0.6–0.7V — meaning when conducting, the voltage across the diode is ~0.7V regardless of current (within rated limits).

Applications: Rectification (convert AC to DC), reverse polarity protection (protect circuits from accidentally reversed power connections), freewheeling (across motor/relay coils to absorb inductive kickback), ESD protection clamps on IC pins.

Zener diode: special diode that conducts in reverse at a precise voltage (the Zener voltage). Used as a voltage reference or clamp. If you need to clamp a 5V signal to 3.3V, a 3.3V Zener in reverse across the line will clamp it.

LED (Light Emitting Diode): a diode that emits light when forward-biased. Forward voltage is colour-dependent: Red ~2V, Green ~2.1V, Blue ~3.2V. Always use a series resistor to limit current (typically 10–20mA). Without a resistor, an LED will draw unlimited current and burn out instantly.

My notes

Transistors — BJT & MOSFET in Detail LIKELY ASKED

BJT — Bipolar Junction Transistor

A BJT has three terminals: Base, Collector, and Emitter. It is a current-controlled device — a small current into the Base controls a larger current from Collector to Emitter. The ratio is called hFE or beta (β), typically 100–300. So 1mA into the base can control 100–300mA through the collector.

NPN transistor: Current flows from Collector to Emitter when the Base is driven HIGH (positive current into Base). The transistor turns ON when VBE ≥ 0.7V. Used to switch loads connected to the positive supply — the load goes between VCC and Collector, emitter connects to GND.

PNP transistor: Current flows from Emitter to Collector when the Base is pulled LOW (current flows out of Base). Used for high-side switching — load connects between Emitter and the load, Collector goes to GND.

Two operating regions: Saturation (fully ON — like a closed switch, VCE ≈ 0.2V) and Cut-off (fully OFF — like an open switch). For switching applications you want the transistor firmly in one region or the other — never in between (that wastes power as heat).

MOSFET — Metal Oxide Semiconductor Field Effect Transistor

A MOSFET has three terminals: Gate, Drain, and Source. It is a voltage-controlled device — voltage on the Gate controls current from Drain to Source. Almost no gate current flows (extremely high input impedance), making it very efficient to drive.

N-channel MOSFET: Turns ON when Gate voltage is sufficiently higher than Source (typically VGS > 2–4V for logic-level MOSFETs). Current flows from Drain to Source. Used for low-side switching — load between VCC and Drain, Source to GND. This is the most common type in embedded power circuits.

P-channel MOSFET: Turns ON when Gate voltage is sufficiently lower than Source (VGS is negative). Used for high-side switching. Less common because performance is lower than N-channel.

RDS(on): the ON-resistance of a MOSFET when fully turned on. Lower is better — it determines how much voltage is dropped and how much power is wasted. A MOSFET with RDS(on) = 10mΩ at 5A wastes only P = I²R = 25 × 0.01 = 0.25W — far better than a BJT.

Why MOSFETs over BJTs in power circuits: MOSFETs switch faster, waste less power (no base current needed), and have lower on-resistance. Used in all modern power supplies, motor drivers, and battery management systems.

My notes

Power Supply Concepts — LDO, Buck, Boost DEFINITELY ASKED

LDO — Linear Dropout Regulator

An LDO takes a higher input voltage and regulates it down to a fixed output voltage by burning off the excess as heat. It works like a variable resistor in series with the supply — always dissipating power equal to (Vin − Vout) × Iout.

Example: AMS1117-3.3 takes 5V input and gives 3.3V output. If your circuit draws 500mA, the LDO wastes (5−3.3) × 0.5 = 0.85W as heat. At 1A it wastes 1.7W — it will get very hot and needs a heatsink or it will go into thermal shutdown.

Advantages: Simple, cheap, no switching noise, no external inductor needed, very low output ripple — good for noise-sensitive analog circuits.

Disadvantages: Inefficient, especially when Vin is much higher than Vout. Efficiency = Vout/Vin. A 5V-to-3.3V LDO is only 66% efficient. All extra power becomes heat.

"Dropout voltage": the minimum difference between Vin and Vout for the LDO to regulate properly. A standard LDO needs ~1.5V dropout. An LDO needs Vin ≥ Vout + dropout. If Vin falls too close to Vout, the output droops. LDOs are used extensively in consumer electronics for post-regulation.

Buck Converter (Step-Down Switching Regulator)

A buck converter uses a switch (MOSFET), an inductor, and a capacitor to step voltage DOWN efficiently. The MOSFET switches on and off at high frequency (typically 100kHz–3MHz). When ON, current builds in the inductor. When OFF, the inductor releases that energy to the output. By controlling the duty cycle (ratio of ON to OFF time), you set the output voltage: Vout = Vin × duty cycle.

Example: A 12V to 5V buck converter with 75% efficiency at 1A wastes only 12×1/0.75 − 5×1 = 1W compared to an LDO wasting (12−5)×1 = 7W. Massive difference at scale.

Advantages: High efficiency (75–95%), handles large voltage differences, used for all main power rails in modern electronics.

Disadvantages: More complex, requires external inductor and capacitors, generates switching noise that can interfere with analog circuits.

Boost Converter (Step-Up Switching Regulator)

A boost converter steps voltage UP. Same principle — switch, inductor, capacitor — but configured differently. The inductor charges when the switch is ON, then releases energy to the output in series with the input when the switch is OFF, giving a higher output voltage.

Example: boosting a 3.7V Li-ion battery to 5V for USB output, or 3.3V to 12V for a display backlight. Used wherever you need a higher voltage than your source provides.

Common Power Failure Symptoms

Board completely dead
Check: fuse blown? Input voltage present at connector? LDO/buck output at correct voltage? Ground continuity from supply to board?
IC getting hot
Overvoltage applied? Overcurrent (short circuit)? Reversed polarity cap or diode? Wrong component in that position?
Random resets
Power rail drooping under load — check with scope, not DMM. Enable pin floating? Watchdog timer firing due to firmware hang?
Brownout
Supply rail drops below threshold momentarily. Check trace resistance, connector resistance, bulk capacitance insufficient.
Always measure voltage AT THE IC PIN, not just at the input connector. Trace resistance, connector resistance, and fuse resistance can cause significant voltage drop under load.
My notes
02 Lab Instruments

Digital Multimeter (DMM) — Complete Guide DEFINITELY ASKED

The DMM is your first tool for any hardware investigation. You must be able to use every mode confidently and explain what you're doing as you do it. In a Foxconn interview they may literally hand you a board and a DMM and ask you to diagnose it.

DC Voltage (V— or VDC)

Measures steady DC voltage. Red probe to the point you're measuring, black probe to circuit ground. The DMM shows the voltage of the red probe relative to black. Most electronics work at DC — battery voltage, power rails (3.3V, 5V, 12V), logic levels on pins.

Range selection: If you're measuring a 5V rail and set the DMM to the 2V range, it will overrange. Start at the highest range and work down, or use autoranging. Set to a range just above what you expect — measuring 5V on a 20V range gives better resolution than on a 200V range.

Important limitation: DMM measures average steady-state voltage. It cannot show transients, noise, or ripple. A rail that reads 3.28V on a DMM might be bouncing between 3.0V and 3.6V at 100kHz — the DMM won't show that. Use a scope for dynamic measurements.

AC Voltage (V~ or VAC)

Measures AC voltage — mains power (230V in India), transformer outputs, AC signals. Never use AC mode on a DC circuit — you'll get a misleading reading because AC mode measures RMS value of AC signals. If you accidentally measure a 5V DC rail in AC mode you might see 0V or a tiny number — don't be confused.

Resistance (Ω)

Critical rule: always power off the circuit before measuring resistance. If the circuit is powered, you'll get incorrect readings and may damage the DMM. The DMM applies its own small voltage to measure resistance — if an external voltage is present, the reading is meaningless and potentially damaging.

Use resistance mode to: measure resistor values, check if a trace is continuous (should read near 0Ω), check if two points that should be isolated are shorted (should read very high/infinite), measure contact resistance of connectors (should be <1Ω).

Continuity Mode (beep symbol ))))

Continuity mode beeps when resistance between the two probes is below approximately 30Ω. This is the fastest way to check whether a trace is intact or a solder joint is connected — you hear the beep without looking at the display. Use it for: checking solder joints, verifying wire harnesses, checking for accidental shorts between adjacent PCB pads, verifying ground connections.

Remember: a beep means connected, silence means open. But a beep between VCC and GND might be a short — or it might be a legitimate low-resistance path (an LED, a small resistor). Always interpret in context of the schematic.

Diode Test

Applies a small forward voltage and measures the forward voltage drop. A good silicon diode shows ~0.6–0.7V in the forward direction and no reading (OL) in the reverse direction. A short shows near 0V in both directions. An open shows OL in both directions. Use this to test diodes in-circuit or on the bench, and also to identify an unknown component's orientation.

DC Current (A)

To measure current, you must break the circuit and insert the DMM in series. This is different from voltage (where you probe in parallel). The DMM in current mode has very low internal resistance — it acts like a shunt. Steps: power off circuit, break the wire/trace, connect DMM in series, power on, read current.

Critical: use the correct input port for current on the DMM. Most DMMs have a separate port labelled mA or A. If you accidentally measure current using the voltage port, you'll blow the fuse inside the DMM (or destroy it). A DMM in current mode connected across a supply (in parallel) will create a near-short circuit.

Walk-through: Debugging a dead board with DMM

Say this in the interview — step by step
Step 1: Measure input voltage at the power connector — confirm correct supply voltage is arriving (e.g., 5V ±5%). If this is wrong, the problem is upstream — check the supply, cable, or connector.

Step 2: Measure the output of the first power regulator (LDO or buck converter). If input is correct but output is wrong, the regulator itself has failed, or its enable pin is not asserted, or there's a short on the output rail pulling it down.

Step 3: Measure VCC at the main IC's power pin (not just at the regulator output — verify it arrives at the IC). A broken trace or connector can drop voltage between the regulator and the IC.

Step 4: Measure continuity of the ground path. Without a solid ground, no circuit works even if VCC is correct.

Step 5: If all rails look correct, move to checking communication lines, enable signals, reset states. Sometimes a device is powered but held in reset by a stuck reset line.
My notes

Oscilloscope — Complete Guide DEFINITELY ASKED

An oscilloscope shows you voltage over time — it draws a graph. The X axis is time, the Y axis is voltage. This is what a DMM cannot show: how a signal changes moment to moment. It is your most powerful diagnostic tool after the DMM.

Key Controls

Timebase (horizontal, time/div): Sets how much time is represented by each grid division on the X axis. If set to 1ms/div and there are 10 divisions, you're seeing 10ms of signal. To see a 1kHz signal (1ms period), set timebase to 0.2ms/div so one full cycle spans about 5 divisions — filling the screen nicely.

Voltage scale (vertical, V/div): Sets how much voltage each Y division represents. A 3.3V signal on a 1V/div setting would show about 3.3 divisions of height — good visibility. If the signal is clipped at the top and bottom, increase the V/div. If the signal is a tiny line, decrease it.

Trigger: The trigger system decides when to start drawing a waveform. Without it, the waveform scrolls continuously and you can't see it clearly. A rising-edge trigger at a threshold of ~1.65V (half of 3.3V) tells the scope: "every time the signal crosses 1.65V going upward, start a new sweep." This makes a repetitive waveform appear stable on screen. If the trigger isn't set correctly, the waveform appears to drift or show multiple overlapping copies.

Probe ground clip: Always connect the probe's ground clip to the circuit's ground first. The probe tip then measures voltage relative to that ground. If you connect the ground clip to a non-ground point, you'll short it to ground and potentially damage the circuit.

Probe compensation: Before using a new probe, test it on the scope's built-in calibration signal (usually a 1kHz square wave at the front panel). Adjust the small trim capacitor on the probe until the square wave's corners are sharp and flat. An uncompensated probe gives inaccurate readings especially at high frequencies.

×1 vs ×10 probe: A ×10 probe has a 9MΩ series resistor inside, making it draw 10× less current from the circuit — much less loading. But it attenuates the signal by 10× so you need to set the scope to compensate. For most electronics debugging, use ×10 mode. Only use ×1 for very small signals that you can't afford to attenuate.

What to look for on a scope in FA work

  • Power rail noise: a rail that reads 3.3V on a DMM might show 50mV of switching ripple at 500kHz on a scope. This ripple can cause ADC errors, communication failures, and erratic MCU behaviour. Look for: clean flat rail vs noisy rail.
  • Clock signal quality: check frequency (matches expected?), duty cycle (should be 50% for most clocks), rise/fall times (should be fast — slow edges indicate signal integrity issues), and any ringing or overshoot on the edges.
  • Communication signals: UART data — is it present? Is the idle line HIGH (correct for UART)? SPI — does CS go LOW before data starts? I2C — are there ACK bits? Is SDA being held low (bus lockup)?
  • Glitches and spikes: short voltage spikes that a DMM completely misses. These can cause MCU resets, data corruption, and intermittent failures. Use single-shot trigger mode to capture one-time events.
  • PWM signals: measure duty cycle, frequency, and whether it's changing correctly in response to commands.

Scope vs DMM — when to use which

DMM for steady-state values. Scope for anything that changes with time. If the DMM shows correct values but the circuit misbehaves — the scope will find what the DMM missed.
My notes

Power Analyser & Spectrum Analyser LIKELY ASKED

Power Analyser

A power analyser measures electrical power with high accuracy. Unlike a DMM which gives you one reading at a time, a power analyser simultaneously and continuously measures: voltage, current, real power (W), apparent power (VA), reactive power (VAR), power factor, frequency, and efficiency. It logs these over time and can generate reports.

Power factor: the ratio of real power (doing useful work) to apparent power (total power drawn). For a purely resistive load, PF = 1.0. For motors, capacitors, and inductors, PF < 1.0 — meaning you're drawing more current from the supply than the load actually uses for work. Power factor matters for mains-powered products.

In an NPI FA context: used to characterise power consumption of a new product across all operating modes (idle, active, peak), verify the product meets its rated power specs, measure efficiency of power supplies, and identify products that draw more current than expected (which might indicate a failure or design issue).

Difference from DMM: A DMM measures one thing at a time and gives you a snapshot. A power analyser gives you real-time simultaneous multi-parameter measurement with logging. You connect it inline (current path through the analyser, voltage tapped in parallel).

Spectrum Analyser

A spectrum analyser displays signal amplitude versus frequency — the "frequency domain" view. While an oscilloscope shows you what a signal looks like over time (time domain), a spectrum analyser shows you what frequencies are present and at what levels.

How to read it: X axis = frequency (e.g., 1MHz to 1GHz), Y axis = amplitude in dBm (decibels relative to 1mW). Each peak on the display represents a frequency component. A fundamental clock at 100MHz will show a peak at 100MHz. Harmonics will appear at 200MHz, 300MHz, etc. (typically at lower amplitudes).

In Foxconn NPI FA context: consumer electronics (phones, tablets, laptops) must pass EMC (Electromagnetic Compatibility) regulations before sale. The spectrum analyser checks that the device does not emit electromagnetic radiation above permitted levels at any frequency. It's also used to validate RF performance (Wi-Fi, Bluetooth, cellular) — checking that the transmitter is at the right power level, right frequency, and not spreading energy into adjacent channels.

If you haven't used one: "I haven't operated a spectrum analyser directly, but I understand its purpose and how to interpret a spectrum plot — identifying fundamental frequencies, harmonics, and spurious emissions. I'm ready to learn the specific instrument in use here."

Logic Analyser

Although not listed in the JD, you have this on your resume and you have used it. A logic analyser captures multiple digital signals simultaneously and decodes them into readable data. Unlike a scope which shows waveform shape, a logic analyser focuses on timing relationships between many signals and protocol decoding.

You connect it to UART TX, SPI (MOSI, MISO, SCK, CS), or I2C (SDA, SCL) lines and it will decode the actual bytes being transmitted. This is how you verify that an MCU is sending the right commands to a sensor, or that a sensor is responding correctly. Without a logic analyser, you'd have to count bits on an oscilloscope manually — tedious and error-prone.

My notes
03 Hardware Debugging

Systematic Debugging Methodology DEFINITELY ASKED

The most important thing an FA engineer demonstrates is not that they know every answer — it is that they have a systematic, disciplined approach to finding answers. An interviewer at Foxconn wants to see that you don't randomly poke at boards hoping something changes. They want to see methodology.

The 8-step debugging process

  1. Define the failure precisely — "The board doesn't work" is not useful. "The board powers on, the green LED lights, but the UART debug output shows no MCU boot messages" is useful. Be specific about: what symptom, under what conditions, how reproducibly, which units are affected.
  2. Check power first — always — Before touching anything else, verify every power rail is correct. This rule sounds basic but experienced engineers forget it under time pressure. Power issues cause 40–60% of hardware failures. A 30-second power check can save hours of wrong investigation.
  3. Visual inspection — Under good lighting and magnification: look for burnt marks, discolouration, swollen capacitors, solder bridges, missing components, components in wrong orientation, cracked PCB traces, lifted pads, cold solder joints (dull and grainy instead of shiny).
  4. Reproduce the failure — Before trying to fix anything, make sure you can reliably trigger the failure. A failure you can't reproduce consistently cannot be root-caused. How many times does it fail out of 10 attempts? Under what exact conditions?
  5. Isolate the fault domain — Is it in the power section? The communication section? The firmware? The mechanical assembly? You cannot debug all domains simultaneously. Isolate which domain is failing first.
  6. Divide and conquer — Within the fault domain, split it in half. Test the midpoint. Depending on the result, you've eliminated half the possibilities. Repeat. This is how you find a failure in a 1000-component board with 10 measurements instead of 1000.
  7. Measure — never assume — Every hypothesis must be tested with an instrument. "I think it's the capacitor" means nothing until you measure it. The circuit doesn't care what you think — it behaves according to physics.
  8. Document everything — Every measurement you take, every component you test, every result you get. Documentation serves three purposes: (1) helps you track where you've been so you don't repeat yourself, (2) provides evidence for your root cause conclusion, (3) enables others to continue your work if needed.

Common failure modes — know these cold

Cold solder joint
Appears dull, grey, grainy — not shiny. Caused by insufficient heat during soldering, movement during cooling, or contamination. Has high resistance — works intermittently or not at all. Common on SMD pads and through-hole pins. Fix: reflow with fresh solder.
Solder bridge
A blob of solder accidentally connecting two adjacent pads or pins that should be separate. Creates a short circuit. Common between fine-pitch IC pins (QFP, TSOP packages). Visible under magnification. Fix: remove with solder wick or touch with iron tip.
Open trace
A PCB trace that is physically broken. Continuity test between the two ends shows open (infinite resistance). Caused by: mechanical stress, flexing, manufacturing defect, corrosion, or physical damage. Fix: bridge with a bodge wire or conductive epoxy.
ESD damage
Electrostatic discharge destroys IC input stages. The IC may appear physically undamaged but be functionally dead. ESD damage often causes partial failure — the IC works sometimes, fails under certain conditions. Prevention: ESD wrist strap, ESD mat, anti-static bags, ground yourself before handling boards.
Reversed polarity
Electrolytic capacitor or diode placed backwards. Electrolytic caps will heat up, swell, and may vent gas or explode. Diodes in protection circuits placed backwards do nothing — leaving the circuit unprotected. Always check orientation against silkscreen marking.
Wrong component
A component that looks identical but has different electrical specs — wrong resistor value, wrong capacitor voltage rating, wrong IC package pinout. Must be verified by measuring the component value and comparing to the BOM, or by checking the markings against the datasheet.
Lifted pad
A PCB solder pad that has separated from the PCB substrate — usually from excessive heat during rework or mechanical stress. The component lead is now not connected even if it looks soldered. Detected by gently probing the pad — it moves, or continuity test fails.
Moisture damage
Moisture absorbed into PCB substrate or component packages causes leakage currents, corrosion, and delamination. Conformal coating prevents this. In FA, look for corrosion products (white or green deposits), and measure insulation resistance between adjacent conductors.
My notes

Communication Protocols — Deep Dive DEFINITELY ASKED

UART — Universal Asynchronous Receiver Transmitter

UART uses two wires: TX (transmit) and RX (receive). It is asynchronous — there is no shared clock. Instead, both devices must be configured to the same baud rate (bits per second) before communication. Common baud rates: 9600, 115200, 921600. At 115200 baud, each bit lasts 1/115200 = 8.68 microseconds.

Frame structure: Start bit (always LOW) → 8 data bits (LSB first) → optional parity bit → Stop bit (always HIGH). The idle state is HIGH. When a transmission begins, the line goes LOW for one bit period (start bit) — this wakes up the receiver. The receiver then samples each bit in the middle of its period to determine if it's HIGH or LOW.

Common failures: Baud rate mismatch (garbled output — looks like random characters), wrong voltage levels (5V TX → 3.3V RX without level shifting — works sometimes but unreliable), TX and RX swapped between devices (connect TX of one to RX of the other, not TX to TX), parity mismatch.

Debugging: Scope on TX line — you should see a signal going LOW briefly then HIGH for the start bit, then data bits, then returning HIGH. If the idle state is LOW, there's a wiring problem (inverted signal or connection to wrong pin). Check that the line isn't floating (no pull-up, no connection).

I2C — Inter-Integrated Circuit

I2C uses exactly 2 wires: SDA (Serial Data) and SCL (Serial Clock). It supports multiple devices on the same two wires — each device has a 7-bit address (sometimes 10-bit). The master generates the clock and initiates all transactions. Slaves only respond when addressed.

Open-drain: Both SDA and SCL use open-drain (or open-collector) signalling — devices can only pull the line LOW, never drive it HIGH. The line is pulled HIGH by a pull-up resistor connected to VCC. This is why pull-up resistors are mandatory — without them, the line can never go HIGH and nothing works.

Pull-up values: Typically 4.7kΩ for standard mode (100kHz), 2.2kΩ for fast mode (400kHz). Too high = slow rise times, signal doesn't reach HIGH before next clock edge. Too low = too much current, may exceed sink capability of devices. The right value depends on bus capacitance and speed.

Transaction structure: START condition (SDA goes LOW while SCL is HIGH) → 7-bit device address → Read/Write bit → ACK bit from slave (slave pulls SDA LOW for one clock) → data bytes, each followed by ACK → STOP condition (SDA goes HIGH while SCL is HIGH).

Common failures: Missing pull-up resistors (SDA/SCL stuck LOW or floating), wrong device address (ACK not received), bus lockup (slave stuck mid-transaction holding SDA LOW — fix by clocking SCL 9 times then sending STOP), address conflict (two devices with same address), voltage level mismatch (5V device on 3.3V bus without level shifting).

You have real experience here: SHT30, BMP180, SHT40, ALS sensors — all I2C. Hydroponics project, STM32 project. This is genuine knowledge you can talk about.

SPI — Serial Peripheral Interface

SPI uses 4 signals: MOSI (Master Out Slave In), MISO (Master In Slave Out), SCLK (clock), and CS/SS (Chip Select, active LOW). It is synchronous (shared clock) and full-duplex (send and receive simultaneously). Much faster than I2C — can run at tens of MHz.

CS pin: Each slave device has its own CS pin. The master pulls CS LOW to select a device, transfers data, then releases CS HIGH to deselect. Only one CS can be active at a time. This is how you have multiple SPI devices on the same MOSI/MISO/SCLK lines.

SPI modes (CPOL/CPHA): Four modes define clock polarity and phase — when exactly the data is sampled and when it changes. The datasheet for every SPI device specifies which mode it needs. Getting this wrong means the device receives shifted or inverted data. Mode 0 (CPOL=0, CPHA=0) is most common — clock idles LOW, data sampled on rising edge.

Common failures: CS not going LOW before clock starts (device never selected), CPOL/CPHA mismatch (data shifted, garbage received), clock frequency too high for device (data not sampled correctly), MOSI and MISO swapped, CS left permanently LOW (prevents other SPI devices from working).

USB — Universal Serial Bus

USB is a differential pair (D+ and D−) plus power (VBUS = 5V) and GND. Differential signalling means the receiver looks at the difference between D+ and D− — this makes it highly immune to common-mode noise. USB uses a complex protocol with descriptors, endpoints, and enumeration.

USB CDC (Communication Device Class): Makes the USB device appear as a serial (COM) port to the computer. This is what Arduino and ESP32 boards use for programming and debug output. The MCU runs a USB stack that implements the CDC class, and the computer loads a CDC driver (or uses the built-in one) and creates a virtual COM port.

Enumeration: When you plug in a USB device, the host (computer) requests its descriptor — a block of data that identifies the device type, manufacturer, VID/PID, and capabilities. If enumeration fails, the device shows as "Unknown Device" in Device Manager. Common causes: wrong descriptor data, D+ and D− swapped, missing pull-up resistor on D+ (needed for Full Speed USB).

My notes
04 Failure Analysis Techniques

FA Flow in NPI Context — Full Detail DEFINITELY ASKED

Failure Analysis in an NPI environment is not just about fixing a broken board — it's about understanding why it broke, so that every future board doesn't break the same way. The output of FA is not a repaired unit — it's a root cause report with corrective action.

FA Flow — step by step

  1. Receive and document the failed unit — Record the serial number, batch number, when it was built, when it failed, what test it failed, and what the symptom is. Never begin analysis without documenting the incoming state. Take photos before touching anything.
  2. Visual inspection — First with naked eye, then under optical microscope (10×–40×). Look for: burnt or discoloured components, solder bridges, cold joints, missing components, wrong component orientation, physical damage, corrosion, flux residue that might cause leakage. Sometimes the failure is obvious here — a burned resistor, a reversed capacitor — and you don't need to go further.
  3. Electrical characterisation — Power up the unit (carefully, with current limiting) and measure: all power rails against expected values, any available test points, communication line activity. Try to reproduce the failure under controlled conditions. Measure the exact symptom — if the unit fails a specific test, run that test while monitoring with instruments.
  4. Fault isolation — Using measurements, narrow down the failure to a specific section of the circuit, then to a specific component or solder joint. Use the working unit (if available) as a reference — measure the same points on both and find where readings diverge.
  5. Physical analysis tools — If electrical analysis doesn't pinpoint the root cause, use: X-ray inspection (non-destructive, reveals solder joint quality under BGA/QFN), cross-section analysis (destructive — cut through the joint to see its internal structure), SEM (high-magnification imaging), EDS (elemental composition analysis).
  6. Root cause identification — Classify the root cause: Design defect (the design itself is wrong), Material defect (wrong or substandard component), Process defect (assembly/soldering error), Environmental damage (ESD, moisture, mechanical), Workmanship (handling damage). The classification determines who needs to take corrective action.
  7. Corrective action — Implement and verify the fix. Then follow up with: FMEA update (add this failure mode if it wasn't there), 8D report, control plan update, potentially an ECN (Engineering Change Notice) if the design needs changing.
My notes

SEM, EDS, X-ray & Cross-Section — Full Explanation LIKELY ASKED

X-ray Inspection

X-ray inspection is non-destructive — you can inspect a component without removing or cutting it. X-rays pass through the PCB and components at different rates depending on density and thickness. The resulting image shows the internal structure of solder joints that are hidden under components.

Why it's needed: BGA (Ball Grid Array) packages have their solder balls completely hidden under the IC body. You cannot inspect them visually or with a scope. X-ray is the only way to see if the balls are properly formed, or if there are voids (air pockets) or bridges between adjacent balls.

What X-ray shows: Solder voids (dark circular areas inside a solder joint — reduce reliability), solder bridges between adjacent balls/pads, missing solder balls, misaligned components, component tombstoning (one end lifted off the pad).

Voids in solder joints: Small voids (<25% of pad area) are usually acceptable. Large voids reduce the mechanical strength and thermal conductivity of the joint. IPC standards define acceptable void percentages for different applications.

Cross-sectional Analysis

Cross-sectioning is destructive — you physically cut through the sample, then polish the cross-section to a mirror finish, and examine it under a microscope. This reveals the internal structure of solder joints, through-holes, and component packages.

What it reveals: Crack propagation through a solder joint (from thermal cycling or mechanical stress), intermetallic layer thickness between solder and pad (too thick = brittle joint from over-heating), voiding inside the joint, pad delamination from the PCB substrate, plating thickness in through-holes.

Process: The sample is encapsulated in epoxy resin, then ground with progressively finer abrasives, then polished to optical flatness. The cross-section is then viewed under an optical microscope (up to 1000×) or prepared for SEM imaging.

SEM — Scanning Electron Microscope

SEM gives extremely high-resolution images (up to 100,000× magnification — compared to 1000× for optical microscopes) by scanning a focused beam of electrons over the sample surface. Electrons interact with the surface and produce signals that are detected to form an image.

What SEM reveals that optical microscopy cannot: Fine cracks that are invisible optically, surface texture at the nanometer scale, fracture surface morphology (how a joint fractured — ductile fracture looks different from brittle fracture), minute corrosion products, fine solder structure.

Sample preparation: Samples must be conductive (or coated with a thin conductive layer like gold) and placed in a vacuum chamber. This makes SEM a specialised, expensive tool — usually available in larger labs or sent to external analysis labs.

EDS — Energy Dispersive X-ray Spectroscopy

EDS is always used in conjunction with SEM. When the electron beam hits the sample, it causes each element in the sample to emit characteristic X-rays at specific energies. By measuring these X-ray energies, EDS identifies exactly which chemical elements are present — and in what quantities.

What EDS tells you: Is the solder the correct alloy (SAC305 = Sn 96.5%, Ag 3%, Cu 0.5%)? Is there contamination on the surface (sodium, chlorine, sulphur = corrosion agents)? Is the pad plating the right material (HASL vs ENIG vs OSP)? What are those white deposits (tin whiskers? flux residue? corrosion products?).

Practical use in FA: If you suspect a component is counterfeit (not genuine), EDS can check whether the die composition matches what the manufacturer specifies. If corrosion is found, EDS identifies the corrosive species, pointing to the contamination source.

Honest answer framework for tools you haven't used

Template — adapt for any tool you haven't personally operated
"I haven't operated [SEM/EDS/X-ray] directly in my current experience. However, I understand [tool's] purpose — [explain what it does and what it reveals]. In an FA workflow, I would know when to escalate to [this tool] — specifically when [describe the scenario where it's needed]. I'm ready to work with the lab team or learn the instrument on the job, and the analysis interpretation is something I can contribute to even before I operate the machine myself."
My notes
05 DOE, 8D & FMEA

8D Problem Solving — Complete Detail DEFINITELY ASKED

8D (8 Disciplines) is a structured problem-solving methodology developed by Ford and used industry-wide in manufacturing. It ensures that problems are not just fixed but permanently resolved and prevented from recurring. In Foxconn NPI, every significant failure triggers an 8D report.

All 8 Disciplines — in full

  1. D1 — Form the team: Assemble people with the knowledge, skills, and authority to solve this specific problem. Needs people from: engineering, manufacturing, quality, and sometimes supply chain. One person is the team champion — usually a senior engineer or manager who has authority to implement changes. A team is needed because complex problems rarely have a single root cause that one person can see.
  2. D2 — Describe the problem: Write a precise problem statement using the 5W2H framework: Who is affected? What exactly happened? Where (which product, which line, which location)? When (first occurrence, frequency)? Why does it matter (impact)? How did it occur? How many units are affected? The problem description must be specific and measurable — not "boards fail" but "12% of PCBAs from batch #4721 fail the power-on test at station 4 with symptom: 3.3V rail measures 0V."
  3. D3 — Interim containment action (ICA): While you search for the root cause, you must immediately prevent the problem from causing more damage. ICA is a TEMPORARY fix. Examples: quarantine all suspect units from the same batch, add 100% inspection at the failing test station, stop using the suspect component reel, put defective units on hold. ICAs are not permanent and will be removed after the corrective action is implemented. Key interview question: containment is temporary and immediate; corrective action is permanent.
  4. D4 — Root cause analysis: Find the TRUE root cause — not just the symptom. Use tools: 5-Why analysis (keep asking why until you reach a systemic cause), Ishikawa/Fishbone diagram (organise possible causes into categories: Man, Machine, Method, Material, Environment, Measurement — "6Ms"), fault tree analysis. The root cause is usually a process or system failure, not a person's mistake. "Operator placed the cap backwards" is not a root cause — "assembly documentation lacked a polarity indicator, making error possible" is a root cause.
  5. D5 — Permanent corrective action (PCA): Choose the fix that addresses the root cause — not just the symptom. Test the fix to confirm it eliminates the failure mode. Consider: will the fix create new problems? Is it feasible to implement in production? Does it require a design change (ECN), a process change, or a material change?
  6. D6 — Implement and validate the PCA: Roll out the permanent fix. Update: assembly instructions, work instructions, control plans, BOMs, schematics (if design change). Run validation builds to confirm the failure no longer occurs. Collect data to prove effectiveness.
  7. D7 — Prevent recurrence: Update the FMEA to include this failure mode and its new detection method. Update incoming quality control if the issue was a supplier problem. Share lessons learned across similar product lines. Consider if this failure could happen on other products and proactively check. This is the step most teams skip — and it's why the same problems recur.
  8. D8 — Close and celebrate: Formally close the 8D report. Recognise the team's contribution. Archive the report for future reference. Celebrate the resolution — this reinforces the problem-solving culture.
What is the difference between an ICA (Interim Containment Action) and a PCA (Permanent Corrective Action)?
An ICA is immediate and temporary — it stops the bleeding right now while you investigate. Example: quarantine all boards from this batch, add 100% manual inspection. An ICA does not fix the root cause. A PCA is the permanent fix that eliminates the root cause so this failure never happens again — it might be a design change, process change, or supplier change. ICAs are removed once the PCA is validated and implemented.
My notes

FMEA — Complete Guide with Example DEFINITELY ASKED

FMEA (Failure Mode and Effects Analysis) is a proactive tool — you do it before failures happen, not after. The goal is to predict what could go wrong, assess how bad it would be, and take action to prevent it before the product ships. It's the difference between engineering quality in versus inspecting quality in.

FMEA Table Structure

An FMEA is a structured table. Each row represents one potential failure mode for one component or process step. The columns are:

  • Component/Function — What component or process step are we analysing? (e.g., Input capacitor C1, Solder reflow process)
  • Failure Mode — How could this component/step fail? (e.g., C1 open circuit, C1 shorted, C1 reversed polarity)
  • Effect of failure — What happens to the product if this failure occurs? (e.g., Power supply fails, device completely dead)
  • Severity (S) 1–10 — How bad is the effect? 10 = safety hazard or regulatory failure. 7–9 = loss of function. 4–6 = degraded performance. 1–3 = minor annoyance.
  • Cause of failure — What could cause this failure mode? (e.g., Electrolytic capacitor placed with reversed polarity during assembly)
  • Occurrence (O) 1–10 — How likely is this cause to occur? 10 = almost certain. 7–9 = high. 4–6 = moderate. 1–3 = rare.
  • Current controls — What is already in place to prevent or detect this failure? (e.g., Polarity marking on silkscreen, incoming inspection, AOI inspection after reflow)
  • Detection (D) 1–10 — How likely is the current control to detect the failure before it reaches the customer? 1 = almost certain to detect. 10 = almost impossible to detect. Note: LOW Detection score = GOOD detection (counterintuitive — lower is better for Detection).
  • RPN — Risk Priority Number = S × O × D. Range: 1 to 1000. Higher RPN = higher priority for corrective action.
  • Recommended action — What should be done to reduce the RPN? Focus on reducing Severity (design change), Occurrence (better assembly process), or Detection (add inspection step).
RPN = Severity × Occurrence × Detection (max = 10 × 10 × 10 = 1000)

Worked FMEA example — capacitor failure

Component: C1 (100µF electrolytic input capacitor). Failure mode: Reversed polarity during assembly. Effect: Capacitor overheats, vents gas, power supply fails — device completely dead. Severity = 8 (loss of function). Cause: Assembly operator places cap in wrong orientation. Occurrence = 4 (moderate — happens occasionally with unmarked polarised caps). Current control: Visual inspection by operator. Detection = 6 (visual inspection misses some errors — moderate detection). RPN = 8 × 4 × 6 = 192. This is high priority. Recommended action: Add clear polarity marking to silkscreen AND add Automated Optical Inspection (AOI) after reflow. New Detection = 2 (AOI catches almost all), new RPN = 8 × 4 × 2 = 64. Acceptable.

Pareto Analysis — prioritising which failures to fix first

The Pareto principle (80/20 rule) says approximately 80% of your failures come from 20% of the failure modes. A Pareto chart ranks failure modes from most frequent to least, with a cumulative percentage line. Focus corrective action on the top 2–3 failure modes first — they give the most yield improvement for the least effort.

My notes

DOE — Design of Experiments in Full LIKELY ASKED

DOE is a statistical method for efficiently discovering which process variables (factors) affect an output (response) and by how much. Instead of changing one variable at a time (OFAT — slow, misses interactions), DOE changes multiple variables simultaneously in a structured pattern and uses statistics to separate their effects.

Key terminology

  • Factor: An input variable that you can control and vary. Examples: solder reflow peak temperature, paste volume, component placement pressure, conveyor speed.
  • Level: The specific values a factor takes during the experiment. Two levels (low/high) is common — e.g., temperature at 240°C (low) and 260°C (high).
  • Response: The output you're measuring to see how the factors affect it. Examples: solder joint strength (grams-force), void percentage (%), product yield (%), electrical resistance (mΩ).
  • Interaction: When the effect of one factor depends on the level of another. Example: high temperature might only cause joint defects when paste volume is also high — neither factor alone causes the issue. OFAT testing misses interactions; DOE catches them.
  • Full factorial: Test every combination of every factor at every level. For 3 factors at 2 levels: 2³ = 8 experiments. For 5 factors at 3 levels: 3⁵ = 243 experiments. Gets unwieldy quickly.
  • Fractional factorial / Taguchi orthogonal arrays: Run only a carefully chosen fraction of all combinations. Taguchi's L9 array runs only 9 experiments instead of 27 for 4 factors at 3 levels. You lose the ability to detect some interactions but gain huge efficiency.

Real example — solder reflow optimisation

Problem: 15% of BGA components showing voids on X-ray. You suspect three factors: (A) peak reflow temperature, (B) time above liquidus, (C) solder paste type. Each at two levels (low/high). Full factorial = 2³ = 8 runs. For each run, reflow 20 boards and measure average void percentage. Statistical analysis (ANOVA or main effects plots) reveals: factor A (temperature) has the largest effect, factor C (paste type) has moderate effect, factor B (time) has minimal effect. You set temperature and change the paste type. Void percentage drops from 15% to 3%. This is DOE in practice.

Clean interview answer for "explain DOE"
DOE is a structured method to find which process variables truly drive an output — and by how much. Instead of changing one factor at a time, which is slow and misses interactions between factors, DOE tests structured combinations simultaneously. A statistical analysis of the results separates which factors matter most, allowing us to optimise the process efficiently. In an NPI context, I'd use DOE to optimise solder reflow profiles, understand which assembly process parameters affect yield, or identify the root cause of a defect that changes with multiple process variables.
My notes

5-Why Analysis & Fishbone Diagram LIKELY ASKED

5-Why Analysis

The 5-Why technique asks "Why?" repeatedly until you reach a root cause that, if fixed, prevents the problem from recurring. The magic number is approximately 5 — most root causes are found within 5 iterations. But it's not a rigid rule — sometimes 3 whys are enough, sometimes 7 are needed.

The key insight: Each answer to "Why?" becomes the next problem statement. You're not looking for blame — you're looking for the system or process failure that allowed the problem to occur.

Detailed example — board fails power-on test

  • Problem: Board fails power-on test — 3.3V rail measures 0V
  • Why is the 3.3V rail 0V? → The LDO regulator is not outputting voltage
  • Why is the LDO not outputting? → Its input capacitor (C1) is shorted
  • Why is C1 shorted? → It was installed with reversed polarity
  • Why was it installed backwards? → The assembly drawing did not clearly indicate polarity, and the PCB silkscreen had no "+" marking
  • Why did the drawing lack polarity information? → The PCB design checklist did not include a requirement to verify polarity markings for polarised components
  • Root cause: Missing checklist item in PCB design review process → Corrective action: Update design review checklist to mandate polarity verification for all polarised components, update silkscreen guidelines

Notice the root cause is not "operator error" — it's a process gap. The operator had no way to know which way the cap went. Fixing the process (updating the checklist and silkscreen) prevents every future operator from making the same error.

Fishbone (Ishikawa) Diagram

The Fishbone diagram is a visual brainstorming tool for 5-Why — it helps you organise all possible causes before investigating. The "head" of the fish is the problem statement. The "bones" are categories of causes. Standard categories for manufacturing are the 6Ms: Man (training, fatigue, skill), Machine (equipment calibration, wear), Method (process procedures, sequence), Material (component quality, wrong spec), Measurement (test accuracy, calibration), Environment (temperature, humidity, ESD).

You brainstorm potential causes in each category, then investigate to confirm or rule out each one. This prevents tunnel vision — you don't jump to the most obvious cause without considering others.

My notes
06 Sensors — ALS & Proximity

Ambient Light Sensor (ALS) — Full Detail LIKELY ASKED

An Ambient Light Sensor measures the intensity of the surrounding light and outputs a digital value in lux. Lux is the SI unit of illuminance — 1 lux = 1 lumen per square meter. Typical values: bright sunlight = 100,000 lux, office lighting = 300–500 lux, moonlight = 1 lux.

How an ALS works — internally

Inside the ALS IC is a photodiode — a semiconductor junction that generates a small current proportional to the light intensity hitting it. Brighter light = more photons = more electron-hole pairs generated = more current. This tiny current (nanoamps to microamps) is converted to a voltage by a transimpedance amplifier inside the IC, then digitised by an ADC, and made available over I2C as a register value in lux (after internal calibration).

The photodiode response is designed to match the human eye's sensitivity curve — peaked around 550nm (green light), with reduced sensitivity to infrared and ultraviolet. This is because ALS is used for screen brightness adaptation — you want it to respond the same way the human eye does to different light colours.

Integration time — important concept

The ADC inside the ALS accumulates charge over a set time window called integration time (or exposure time). Longer integration time = more charge accumulated = higher sensitivity in low light, but slower response. Shorter integration time = faster response but less sensitive. Most ALS ICs let you configure this via a register. Common values: 100ms (fast), 400ms (slow, high sensitivity).

If integration time is set too short in a dim environment, the reading saturates at its minimum and shows 0 lux when there's actually some light. If too long in a bright environment, the ADC saturates at its maximum. You must choose appropriate integration time for the expected lighting conditions.

Common ALS ICs and their interfaces

BH1750 — I2C, 16-bit, very common APDS-9930 — I2C, combined ALS+proximity OPT3001 — I2C, automotive-grade TSL2561 — I2C, two photodiodes VEML7700 — I2C, 16-bit, high dynamic range

FA issues specific to ALS

  • Protective film not removed: Many phones ship with a transparent protective film over the front panel. If this film is opaque or semi-opaque over the ALS window, readings will be artificially low. In production, a film covering the sensor can cause an entire batch to fail ALS calibration. Check: remove film and retest — if it passes, the film was the issue.
  • Wrong I2C address: Many ALS ICs have an address selection pin — pull it HIGH for one address, LOW for another. If the hardware address doesn't match the firmware's expected address, the device will not respond. Check: probe I2C bus with logic analyser — is the firmware sending to the right address? Is the device ACKing?
  • Gain or integration time registers not configured: After power-on, the ALS IC may be in a low-power or standby state. You must write configuration registers to start measurements. A firmware bug that skips this initialisation will result in the device always returning 0 or the same stale value. Check: verify I2C transactions from firmware are writing the correct register values at startup.
  • Physical damage to optical window: Scratches, cracks, ink contamination, or adhesive over the lens window will reduce or distort light reaching the photodiode. Inspect the sensor window under magnification.
  • Crosstalk from display backlight: If the ALS is positioned near the display and the sensor package has insufficient optical isolation, backlight from the display can bleed into the sensor — causing it to report "bright" even in a dark room. This is a design issue requiring better shielding or sensor repositioning.
My notes

Proximity Sensor — Full Detail LIKELY ASKED

A proximity sensor detects whether an object is near (typically within 0–20cm) without physical contact. In smartphones this is used to detect when the phone is held against your ear during a call — the screen turns off to prevent accidental touches and to save battery.

How a proximity sensor works

The sensor contains two components: an IR LED (infrared light-emitting diode) and an IR photodetector. The LED emits pulses of infrared light (typically 940nm — invisible to humans). When an object is near, some of this IR light reflects back and hits the photodetector. The IC measures the intensity of reflected IR. More reflected IR = object is closer. The IC compares this measurement to programmable thresholds and generates an interrupt signal when the object crosses the near/far threshold.

The IR LED is pulsed (not continuous) to reduce power consumption and to allow synchronous detection — the IC only looks for reflected light during the LED pulse window, which reduces interference from ambient IR sources (sunlight, incandescent bulbs).

Crosstalk — the main FA challenge

Crosstalk occurs when IR from the LED reaches the photodetector via a path that doesn't involve an external object — typically by reflecting off the device's own housing, glass cover, or any nearby surface. This causes the sensor to report "close object" even in open air. Crosstalk is a common NPI failure mode because it depends heavily on the mechanical assembly — the gasket around the sensor, the glass transmittance, the sensor placement relative to the housing.

Diagnosing crosstalk: measure the sensor output in open air at maximum distance from any reflective surface. If the reading is above the near threshold, crosstalk is present. Solution: better optical isolation in the sensor packaging, revised mechanical design, software offset calibration.

Common FA issues

  • IR LED not driving: If the current-limiting resistor for the IR LED is wrong value, open-circuit, or the LED itself is damaged, no IR is emitted and the sensor reads 0 (far) always. Test: measure voltage across the LED — should show ~1.2–1.4V forward voltage drop during the LED drive pulse. Check on scope during drive cycle.
  • Threshold registers wrong: The IC uses upper and lower threshold registers to determine near/far state. If these aren't programmed correctly, the interrupt fires at wrong distances. Verify via I2C: read the current threshold register values and compare to the designed values.
  • Black tape or opaque adhesive over window: In assembly, adhesive from a screen protector or label can cover the sensor window. Infrared light cannot pass through opaque materials — the sensor will always report "far." Inspect the sensor window carefully under IR-pass filter (or smartphone camera, which can see IR).
  • Ambient IR saturation: In very bright sunlight, the IR photodetector may saturate from ambient solar IR even without the LED pulsing. Better IC designs have ambient light cancellation — they measure ambient IR first, then subtract it from the LED-on measurement. If this cancellation isn't configured, bright sunlight causes false near readings.
My notes
07 Analog & Digital Circuits

Analog vs Digital — Full Explanation DEFINITELY ASKED

Analog signals

An analog signal is one that can take any value within a range — it is continuous. Real-world physical quantities are analog: temperature, sound pressure, light intensity, position. A microphone output is analog — as air pressure changes continuously, the output voltage changes continuously from -5V to +5V (for example). An analog signal carries information in its exact voltage level at every instant.

Analog circuits process these signals continuously: amplifiers (increase signal amplitude), filters (remove unwanted frequencies), comparators (compare two analog levels), mixers (combine two frequencies). The challenge with analog is noise — any interference adds directly to the signal and is indistinguishable from real signal.

Digital signals

A digital signal has only two valid states: HIGH (logic 1) and LOW (logic 0). Everything in between is undefined. Digital signals carry information in patterns of ones and zeros — the exact voltage level doesn't matter as long as it's clearly HIGH or clearly LOW. This is the key advantage: digital signals are immune to small amounts of noise. A signal corrupted from 3.3V to 3.1V is still clearly HIGH. Noise has to be large enough to push the signal from HIGH territory into undefined or LOW territory to cause an error.

ADC — Analog to Digital Converter

An ADC converts an analog voltage into a digital number. This is how a microcontroller reads a temperature sensor that outputs 0–5V, or an accelerometer, or a microphone. The ADC samples the analog voltage at regular intervals and quantises it into discrete levels determined by the resolution (number of bits).

Resolution: An n-bit ADC has 2ⁿ possible output values (levels). A 12-bit ADC has 4096 levels. If the reference voltage (Vref) is 3.3V, the resolution (smallest detectable voltage change) is 3.3/4096 ≈ 0.8mV. A 10-bit ADC (1024 levels) gives 3.3/1024 ≈ 3.2mV resolution — coarser.

Resolution (LSB voltage) = Vref / 2^n

Sampling rate: The ADC must sample at least twice the highest frequency in the signal (Nyquist theorem). For audio at 20kHz, you need at least 40kHz sampling rate (CD quality uses 44.1kHz). For slow temperature measurements, a few samples per second is fine.

ADC errors: Offset error (all readings shifted by a constant), gain error (readings scale incorrectly), nonlinearity, noise (random variation in readings). The reference voltage must be clean and stable — noise on Vref directly appears as noise on ADC readings.

DAC — Digital to Analog Converter

A DAC does the reverse — converts a digital number to an analog voltage. A 12-bit DAC can produce 4096 different output voltages between 0 and Vref. Used in: audio output (your MCU generates digital audio data, DAC converts to analog, then amplifier and speaker), motor speed control (DAC generates analog control voltage for motor driver), arbitrary waveform generators.

Logic Voltage Levels — critically important

Different digital systems use different voltage ranges for HIGH and LOW. Connecting systems with different voltage levels without level shifting can cause: (1) the receiving device not recognising the signal correctly, or (2) permanent damage to the lower-voltage device.

5V TTL/CMOS
HIGH: >2.0V. LOW: <0.8V. Undefined: 0.8V–2.0V. Used in classic Arduino Uno (ATmega328P).
3.3V CMOS
HIGH: >2.0V. LOW: <0.8V. GPIO max input: 3.3V. Used in ESP32, nRF52, STM32, Raspberry Pi GPIO.
1.8V CMOS
HIGH: >1.2V. LOW: <0.6V. Used in modern low-power processors and some sensors.
5V-tolerant GPIO
Some 3.3V MCU pins are designed to accept 5V inputs without damage. Check the datasheet — marked as "FT" (five-volt tolerant) in STM32 datasheets. NOT all 3.3V pins are 5V-tolerant.

Level shifting methods: (1) Voltage divider — resistor divider reduces 5V to 3.3V (only works for signals going from 5V → 3.3V, not bidirectional). (2) Level shifter IC — dedicated chips like the TXS0102, BSS138 MOSFET circuits for bidirectional shifting. (3) Zener clamp — Zener diode clamps signal to safe voltage.

My notes

Digital Logic, Op-Amps & Signal Integrity LIKELY ASKED

Logic Gates

Logic gates are the building blocks of all digital circuits. Each gate performs a Boolean operation on its inputs to produce an output. In electronics, these are implemented as transistor circuits inside ICs.

AND gate
Output = 1 only when ALL inputs = 1. Think: "both A AND B must be true." 0+0=0, 0+1=0, 1+0=0, 1+1=1.
OR gate
Output = 1 when ANY input = 1. Think: "A OR B is enough." 0+0=0, 0+1=1, 1+0=1, 1+1=1.
NOT (Inverter)
Output is opposite of input. NOT 0 = 1, NOT 1 = 0. Used to invert enable signals.
NAND gate
AND followed by NOT. Output = 0 only when all inputs = 1. Called "universal gate" — you can build any other gate from NAND gates alone.
NOR gate
OR followed by NOT. Also a universal gate.
XOR gate
Output = 1 when inputs are DIFFERENT. Used in error detection (parity), binary adders, data encryption.

Flip-flop (D-type): A memory element that stores one bit of information. The output Q takes the value of input D on each clock edge. It holds that value until the next clock edge. Flip-flops are the building blocks of registers, counters, and all sequential digital logic.

Op-Amp — Operational Amplifier

An op-amp is a differential amplifier — it amplifies the difference between its two inputs (non-inverting input + and inverting input −). Ideal op-amp has infinite gain, infinite input impedance, zero output impedance. Real op-amps have very high but finite gain (~100,000).

Key rule for op-amp with negative feedback: The op-amp adjusts its output to make the two input voltages equal (virtual short circuit). This is the foundation of all op-amp circuit analysis.

Voltage follower (buffer): Output connected directly to (−) input. Output = Input. Gain = 1. Purpose: isolates the source from the load — the op-amp provides current without loading the source. Used when you need to drive a low-impedance load from a high-impedance source.

Non-inverting amplifier: Gain = 1 + R2/R1 (where R1 and R2 are the feedback resistors). Output is in-phase with input. Used to amplify sensor signals before ADC.

Comparator mode: Op-amp without negative feedback. Output swings to maximum positive when (+) > (−), maximum negative when (−) > (+). Used as a threshold detector — "is this voltage above my reference?" Used in battery under-voltage detection, thermostat circuits, overvoltage alarms.

Signal Integrity basics — for PCB debugging

Ringing: On a scope, you see oscillations at the edges of a square wave — the signal overshoots and undershoots before settling. Caused by transmission line effects — impedance mismatch between the driver, trace, and receiver. Solution: series termination resistor (typically 22–100Ω) at the driver output.

Ground bounce: When many outputs switch simultaneously, the sudden current spike through the ground inductance causes the ground to momentarily rise. This shifts all voltage references and can cause false logic triggers. Solution: good decoupling caps, multiple ground vias, star ground topology.

Cross-talk: A signal on one PCB trace induces a small voltage on an adjacent trace through capacitive or inductive coupling. Particularly affects high-speed signals and sensitive analog inputs. Solution: spacing traces apart, using ground guard traces between sensitive signals, keeping digital traces away from analog.

My notes
08 Python for Hardware

Python in an FA/NPI Role — Full Guide LIKELY ASKED

Python is used in NPI/FA engineering primarily for: automating test data collection, processing large volumes of test results, generating reports and charts, controlling test instruments (via VISA/GPIB), and scripting repetitive tasks. You don't need to be a Python software developer — you need to be able to read, modify, and write basic scripts.

Serial communication — reading instrument data

Many test instruments output data over a serial (UART/RS232) interface. Python's pyserial library lets you read this data:

import serial
ser = serial.Serial('COM3', baudrate=9600, timeout=1)
ser.write(b'READ?\n') # send command to instrument
line = ser.readline().decode('utf-8').strip()
print(f"Reading: {line}")
ser.close()

The port name is 'COM3' on Windows, '/dev/ttyUSB0' on Linux/Raspberry Pi. Baudrate must match the instrument's setting. timeout=1 means wait up to 1 second for data before giving up. .decode('utf-8') converts bytes to text string. .strip() removes trailing newline characters.

Reading and analysing CSV test data

Test systems often output results as CSV files. Python with pandas makes analysis easy:

import pandas as pd

df = pd.read_csv('test_results.csv')

# Count pass/fail
total = len(df)
passed = len(df[df['Result'] == 'PASS'])
yield_pct = (passed / total) * 100
print(f"Yield: {yield_pct:.1f}% ({passed}/{total})")

# Find failures
failures = df[df['Result'] == 'FAIL']
print(failures['FailureMode'].value_counts()) # Pareto of failure modes

df[df['Result'] == 'PASS'] filters rows where the Result column equals 'PASS'. value_counts() counts occurrences of each unique value — perfect for Pareto analysis.

Writing a test report to file

with open('report.txt', 'w') as f:
    f.write(f"Test Report — {date}\n")
    f.write(f"Total tested: {total}\n")
    f.write(f"Yield: {yield_pct:.1f}%\n")
    for mode, count in failures['FailureMode'].value_counts().items():
        f.write(f" {mode}: {count} units\n")

VISA instrument control (concept — you haven't used this, explain conceptually)

VISA (Virtual Instrument Software Architecture) is a standard API for communicating with test and measurement instruments — oscilloscopes, DMMs, power supplies, spectrum analysers — over GPIB, USB, Ethernet, or RS232. In Python, the pyvisa library provides this. You send SCPI (Standard Commands for Programmable Instruments) command strings:

import pyvisa
rm = pyvisa.ResourceManager()
dmm = rm.open_resource('USB0::0x0957::0x0607::INSTR')
dmm.write(':MEAS:VOLT:DC?') # SCPI command: measure DC voltage
reading = dmm.read()
print(f"Voltage: {reading} V")

SCPI commands follow the pattern: subsystem:command:parameter. Every major instrument manufacturer supports SCPI. This is how automated test systems control hundreds of instruments in a test sequence without manual operation.

Your honest Python positioning

Say this
I've used Python for serial communication with microcontrollers and sensors — reading UART output from custom boards and processing the data. I'm comfortable with basic data handling using pandas: reading CSVs, filtering by pass/fail, calculating yield, doing value counts for Pareto analysis. I've also used Python for task automation and report generation. VISA instrument control is something I understand conceptually and can learn quickly on the job — the principle is the same as serial communication, just with a standardised command set.
My notes
09 PCB & EDA

Reading Schematics & PCB Layout — Full Guide DEFINITELY ASKED

Schematic reading is a fundamental skill for any hardware engineer. A schematic is the electrical "blueprint" of a circuit — it shows every component and every connection but does not represent the physical layout. The PCB layout is a separate document that shows where components are physically placed and how traces route between them.

Schematic notation — what everything means

  • Power symbols: VCC, VDD, VBUS, +5V — these are all power rail labels. GND, AGND (analog ground), DGND (digital ground) — ground rail labels. Components connected to the same power symbol are connected even without a drawn wire.
  • Net labels: A label on a wire (e.g., "I2C_SDA") means this wire is connected to every other wire with the same label anywhere in the schematic. This is used to avoid routing wires all across the page. Two wires labelled "UART_TX" are connected even on different pages.
  • Reference designators: Every component has a unique ID. R1, R2 = resistors. C1, C2 = capacitors. U1, U2 = ICs/integrated circuits. Q1, Q2 = transistors. D1, D2 = diodes. L1, L2 = inductors. TP1 = test point. J1 = connector. SW1 = switch.
  • Component values: Written next to the reference designator. R1 = 10k means a 10kΩ resistor. C3 = 100n means 100nF. U2 = ESP32-WROOM-32 is the IC model.
  • No-connect (X symbol): A line with an X at its end means this pin is intentionally not connected. This explicitly tells you it's not a mistake.
  • Dots at wire junctions: A dot where two wires cross means they ARE connected. No dot = they cross but are NOT connected. This is a common source of confusion — always check for junction dots.

How to read a schematic efficiently

  1. Find the power section first: Where does power enter? What regulator converts it? What are the output rails (3.3V, 5V, 1.8V)? This gives you the backbone of the circuit.
  2. Find the main IC: Usually the most complex component. Identify its power pins (VDD, VCC — should have decoupling caps) and ground pins.
  3. Trace the communication lines: From the main IC, follow the I2C, SPI, UART, GPIO lines to peripheral devices (sensors, displays, memory).
  4. Identify protection components: TVS diodes, ESD protection ICs, polyfuses on input connectors — these protect the circuit from external damage.
  5. Note test points: TP1, TP2 etc. These are your measurement targets during debugging — the designer already identified the key nodes for you.

PCB layers and what they mean

A 2-layer PCB has: Top copper layer (components and signal traces), Bottom copper layer (often a ground plane — a solid sheet of copper connected to GND, with other traces). The ground plane is critical — it provides a low-impedance return path for all signals and reduces EMI. When you see a large copper pour in KiCad or Altium, that's typically the ground plane.

Solder mask: The green (or other colour) coating on most PCBs. It covers all copper except the pads and exposed areas. Purpose: prevents solder bridges during assembly (solder won't stick to the mask), protects traces from corrosion and mechanical damage.

Silkscreen: The white (or other colour) text and symbols printed on top of the solder mask. Contains: component reference designators (R1, U2), polarity markers (+, stripe for cathode), orientation indicators (pin 1 marks), board name, revision number. Critical for assembly — operators and technicians use silkscreen to place components correctly.

Vias: Holes drilled through the PCB and plated with copper inside. They connect a trace on the top layer to a trace on the bottom layer. Blind and buried vias (used in multilayer boards) connect only specific layers without going all the way through.

Design rules that affect reliability

  • Trace width: Wider traces carry more current without overheating. A 0.25mm trace handles about 0.5A; a 1mm trace handles about 2A. Always use an online trace width calculator for power traces. Signal traces can be thinner (0.1–0.2mm) because they carry very little current.
  • Clearance: Minimum distance between adjacent copper features. Too small = solder bridges during assembly, voltage breakdown if high voltage. IPC standards specify minimum clearances based on voltage.
  • Decoupling cap placement: Must be as close as physically possible to the IC's VCC pin, with the shortest possible trace back to GND. The effectiveness of decoupling decreases rapidly with distance due to trace inductance.
  • Ground plane copper pour: Should be solid and complete — avoid cutting it with signal traces running across it. A signal trace crossing a gap in the ground plane forces return current to take a long detour, causing noise and EMI problems.
My notes
10 Communication & Teamwork

NPI Meeting Preparation & Customer Handling LIKELY ASKED

In an NPI environment at Foxconn, "customers" are the OEM clients — the brand (like Apple, Xiaomi, Dell) who has contracted Foxconn to manufacture their product. Regular technical review meetings happen during NPI where engineers from both sides discuss: build progress, yield data, failure analysis results, and open issues.

Before the meeting — prepare this

  • Yield data: How many units were built? How many passed first-pass? What is the current yield trend (improving, stable, declining)? Which test stations have the most failures?
  • Open failure modes: For each active failure mode — what is it, how many units affected, what is the root cause status (identified/under investigation/unknown), what containment is in place, what is the corrective action timeline?
  • Closed issues: Failures that have been root-caused and corrected — show the before/after yield data to demonstrate effectiveness.
  • Risk items: What issues exist that might impact the production ramp schedule? Flag these proactively — customers hate surprises more than they hate problems.

During the meeting — how to communicate

  • Lead with data, not opinions: "We see 12% failure at the RF test station, compared to 5% target" — not "we think the antenna is probably the issue."
  • Structure every failure update as: Symptom → Root cause → Action → Status. Example: "Units fail RF TX power test. Root cause: antenna feed point impedance mismatch due to PCB trace length error in rev 1.2. Action: ECN issued for rev 1.3 with corrected trace length. Status: rev 1.3 samples expected next week for validation."
  • Never hide a problem: If you don't know the root cause yet, say so clearly with what you DO know and when you expect to have an answer. "We've isolated the failure to the power management section. Root cause investigation ongoing — we'll have preliminary findings by Thursday."
  • Manage commitments carefully: Only commit to dates you're confident in. Missing committed dates damages trust far more than giving a slightly longer timeline.

Team collaboration in an NPI environment

NPI involves: Hardware engineers (circuit design, component selection), Manufacturing engineers (assembly process, tooling), Quality engineers (inspection, FMEA, 8D), Firmware engineers (embedded software), Test engineers (automated test setup), Supply chain (component availability, supplier quality). As an FA engineer you interface with all of them.

When escalating a failure to another team: describe the symptom clearly, share your measurement data, state what you've already ruled out, and specify what you need from them. Don't just say "it's broken" — say "the I2C bus is showing clock stretching causing 200ms delays which triggers a watchdog reset. Firmware team — can you check whether there's a long blocking operation in the I2C interrupt handler?"

My notes

HR & Behavioural Questions — Full Answers DEFINITELY ASKED

Tell me about yourself. (Opening question — sets the tone)
I'm an electronics engineer with nearly 2 years of professional experience across two companies, plus 4+ years of hands-on work with microcontrollers and sensors starting from my undergraduate days. At Optipace Technologies I worked with custom nRF52 and ESP32 boards — doing hardware bring-up, debugging power and communication failures, leading testing workflows, and performing root cause analysis during validation cycles. At Semicon Media I built hardware demos and technical documentation across a wide range of platforms. I've also designed 2-layer PCBs in KiCad, published a Modbus RTU hardware library that's in the Arduino Library Manager, and run a live IoT platform in production. I'm looking to move into an NPI/FA role where I can bring this hands-on debugging experience into a structured manufacturing environment with proper methodologies like 8D and FMEA. Foxconn's scale and rigour is exactly the environment I want to grow in.
Why do you want to work at Foxconn specifically?
Foxconn is one of the most sophisticated electronics manufacturing operations in the world. The products are complex, the scale is massive, and the engineering challenges are real. An NPI FA role at Foxconn means working with structured quality systems — 8D, FMEA, DOE — and proper FA tools on real production failures. That is the environment where I'll develop the deepest engineering skills. I want to be an engineer who can investigate failures at any level and find root causes that stick. Foxconn is the place to build that capability.
What is your biggest weakness?
I sometimes invest too much time trying to fully understand a failure before escalating — I want to have a complete picture before bringing it to my team. In a production environment where containment speed matters, that approach can slow down D3 (interim containment). I've been working on recognising the point where I have enough evidence to escalate for containment while the deeper root cause investigation continues in parallel. These are separate activities and I've learned they don't have to be sequential.
Where do you see yourself in 3 years?
In 3 years I want to be an engineer who can independently handle the full FA cycle — from receiving a failed unit to delivering a complete root cause report with validated corrective action. I'd like to develop expertise in FA techniques including interpreting SEM/EDS and X-ray analysis results. Longer term, I'm interested in growing into a senior or lead role in FA or quality engineering — someone who builds the capability of the team around me, not just resolves individual failures.
Tell me about a time you worked under pressure with a tight deadline.
At Semicon Media, I had a fixed publication deadline for a technical demo involving a sensor integration that wasn't behaving correctly close to deadline. The sensor — connected over I2C — was returning all zeros. Under time pressure, I resisted the temptation to randomly try things and instead went systematic: checked power, verified I2C clock and data with a logic analyser, confirmed the device was ACKing, then read the raw register values. Found that the measurement trigger command was missing — I'd initialised the sensor but forgotten to start a measurement. Fixed it in 5 minutes. The discipline of staying systematic under pressure saved time that random guessing would have wasted.
Tell me about a time you failed at something and what you learned.
Early in my PCB design work, I designed a board and placed all the decoupling capacitors on the bottom layer, directly under the ICs — it looked neat on the layout. But when I tested it, the MCU had intermittent resets under load. A more experienced engineer pointed out that the decoupling caps were too far from the VCC pins — the trace inductance between them was too high for effective decoupling at the MCU's switching frequencies. I fixed it by placing caps directly adjacent to VCC pins on the top layer, and the resets stopped. I learned that PCB layout is as critical as schematic design — a functionally correct schematic can still produce a poorly performing board if the layout decisions are wrong.
Are you comfortable relocating to Bangalore?
Absolutely — I already have over a year of experience working in Bangalore at Optipace Technologies, so I'm familiar with the city and comfortable there. Relocating for the right opportunity is not a concern for me.
My notes
11 Your STAR Stories

The STAR Method — How to Use It READ THIS FIRST

STAR = Situation, Task, Action, Result. It's a structured way to answer behavioural questions ("tell me about a time when..."). Without structure, answers tend to ramble, miss key points, or focus on the wrong things. With STAR, every answer is complete, clear, and impactful.

  • Situation (10% of your answer): Set the context briefly. What project, what company, what was happening. Don't over-explain — one or two sentences maximum.
  • Task (10%): What was your specific responsibility? What were you trying to achieve? What was the problem or challenge?
  • Action (70% — this is the most important part): What did YOU specifically do? This is where most people underperform — they describe what "we" did instead of what "I" did. Be specific about your individual actions, decisions, and reasoning. Show your thinking process, not just the outcome.
  • Result (10%): What was the outcome? Quantify where possible — "yield improved from 87% to 96%", "debugging time reduced from 3 hours to 30 minutes", "the board came up correctly and the firmware team could continue." Even if you don't have a precise number, describe the impact.
The Action section is where you win or lose the interview. "I checked the board" is not an action — "I systematically verified each power rail starting from the input connector, found that the 3.3V rail was at 0.8V, traced the fault to a reversed electrolytic cap on the LDO input, and confirmed by measuring the LDO's input pin directly" IS an action.
My notes

Story 1 — nRF52 Board Debugging (YOUR ANCHOR STORY) MOST IMPORTANT

This is your primary story. Use it for any question about: hardware debugging, failure analysis, problem-solving, root cause analysis, working under pressure. Fill in the actual details from your memory below — even rough details become powerful when told with the right structure.

Situation
At Optipace Technologies, I was working with custom nRF52-based boards used for wireless embedded reference designs. We received a batch of boards — [some/several/one specific board] was showing [describe the symptom: not powering on / drawing excessive current / BLE not advertising / a peripheral not responding / erratic behaviour]. This was [blocking firmware development / affecting our validation timeline / creating uncertainty about the design].
Task
My responsibility was to identify the root cause of the failure, document the findings, and either repair the board or provide a clear report on what needed to change to prevent it on future boards.
Action
I started with power — checked the input voltage at the connector, then measured the 3.3V rail at the nRF52's VCC pin. I found [the rail was at X volts / the rail was correct but...]. I then [visual inspection: found a reversed cap / probed the LDO output / used the oscilloscope to check for noise on the rail / used a logic analyser to verify I2C communication / checked the enable pins on peripheral ICs]. Based on what I found, I [describe the specific fix]. I then measured again to confirm the fix, and [the board powered on correctly / the peripheral responded / the BLE advertising started].
Result
The board was working correctly. I documented the failure mode — specifically [what was wrong and why] — and shared it with the team so we could inspect the other boards in the batch for the same issue. [If applicable: we found X out of Y boards had the same problem, and we updated the assembly check procedure / PCB silkscreen to prevent recurrence.]
DO THIS NOW: In the notes field below, write the actual details of what happened on your nRF52 board — even rough notes. Symptom? What you measured? What you found? What you fixed? The more specific your real story, the more confident and credible you sound.
Write your actual nRF52 story details here — be as specific as possible

Story 2 — PZEM Library USE FOR: initiative, independent work, protocol knowledge

Situation
I needed to interface the PZEM-004T V4.0 energy monitoring module — which measures voltage, current, power, energy, frequency, and power factor over a Modbus RTU interface — with various Arduino-based boards. The existing libraries available had compatibility issues with the V4 version and didn't support all measurement parameters.
Task
I decided to write a complete, well-documented Arduino library from scratch that fully supported the PZEM-004T V4.0 and worked reliably across multiple board types.
Action
I started by thoroughly reading the PZEM-004T V4.0 datasheet to understand its Modbus RTU register map — which register address contains voltage, which contains current, what function codes to use for reading. I implemented the Modbus RTU request frame construction (device address, function code 0x04 for read input registers, starting register, quantity, CRC16 checksum), and the response parsing (validating CRC, extracting and scaling the raw register values to real engineering units). I tested on Arduino Uno R4, ESP32, and ATmega boards, resolving compatibility issues with hardware serial vs software serial. I wrote complete documentation and examples, then published to Arduino Library Manager and PlatformIO Registry through their submission processes.
Result
The library is publicly available in the Arduino Library Manager and PlatformIO Registry and has been used by the community. It demonstrates my ability to read and implement a hardware communication protocol from a datasheet, write production-quality code, and deliver something useful to other engineers. The process also deepened my understanding of Modbus RTU which is widely used in industrial and energy monitoring equipment — relevant to the kind of equipment used in Foxconn's manufacturing environment.
My notes

Story 3 — Hydroponics System USE FOR: sensor integration, system thinking

Situation
For my undergraduate final year project, I designed and built a complete IoT-based automation system for a hydroponics farm — a soil-less growing system where plants grow in nutrient solution. The system needed to autonomously monitor and control the growing environment 24/7.
Task
Design, build, and validate an embedded system using an ESP32 that monitored multiple environmental parameters and automatically controlled equipment based on threshold logic — without human intervention.
Action
I integrated four sensor types using different protocols: SHT40 (temperature/humidity) over I2C, DS18B20 (water temperature) over 1-Wire, a pH sensor via analog ADC input, and a Sensirion CO2 sensor over UART. For each sensor I read the datasheet, implemented the communication protocol, read raw values, and applied the calibration equations to get accurate engineering values. I wrote threshold-based control logic to drive relays for exhaust fans, grow lights, and a water pump. I built a simple web dashboard using HTTP to display real-time sensor data, and an I2C LCD for local display. The entire system ran autonomously on the ESP32 and was validated over several weeks of operation. The work was published as a research paper.
Result
A fully autonomous working system that controlled a real physical environment. I gained hands-on experience with 4 different sensor communication protocols, threshold-based control systems, and IoT data presentation — all of which directly apply to NPI validation work involving sensors and embedded systems.
My notes
12 Cheat Sheet — Read Monday Morning Only

Every Key Term — Know These Cold

NPI = New Product Introduction FA = Failure Analysis DOE = Design of Experiments FMEA = Failure Mode & Effects Analysis RPN = S × O × D (max 1000) 8D = 8 Disciplines problem solving ICA = Interim Containment Action (temporary) PCA = Permanent Corrective Action SEM = Scanning Electron Microscope EDS = Elemental composition analysis BGA = Ball Grid Array IC package QFN = Quad Flat No-lead package SMD = Surface Mount Device THT = Through-Hole Technology ICT = In-Circuit Test (before assembly) FCT = Functional Test (after assembly) AOI = Automated Optical Inspection AXI = Automated X-ray Inspection LDO = Linear Dropout Regulator ALS = Ambient Light Sensor ESD = Electrostatic Discharge EMI = Electromagnetic Interference EMC = Electromagnetic Compatibility PCBA = Printed Circuit Board Assembly BOM = Bill of Materials ECN = Engineering Change Notice Cold joint = Dull grainy solder — high resistance Solder bridge = Unwanted connection between pads Void = Air pocket inside solder joint Tombstone = One end of SMD lifted off pad Pareto = 80% failures from 20% causes KCL = Sum of currents at node = 0 KVL = Sum of voltages in loop = 0 VBE = ~0.7V to turn on silicon BJT RDS(on) = MOSFET on-resistance Lux = Unit of illuminance for ALS SCPI = Instrument command language VISA = Instrument communication API

All formulas — one place

V = IR  |  P = VI  |  P = I²R  |  P = V²/R
Series R = R1 + R2  |  Parallel R = (R1×R2)/(R1+R2)
Series C: 1/Ctotal = 1/C1 + 1/C2  |  Parallel C = C1 + C2
RPN = Severity × Occurrence × Detection
f = 1/T (frequency = 1 / period)
ADC resolution = Vref / 2^n  (12-bit, 3.3V: 3.3/4096 ≈ 0.8mV)
Yield = (Units passed / Total tested) × 100%
LDO efficiency = Vout/Vin  |  LDO heat = (Vin−Vout) × I
Buck Vout = Vin × duty_cycle

5 things to walk in knowing

  1. Check power first — every debugging question starts with power rails
  2. Root cause not just fix — WHY it failed, not just what you replaced
  3. Containment ≠ Corrective action — one is temporary, one is permanent
  4. Your nRF52 story — if you go blank, anchor to this real experience
  5. Honest beats bluffing — "I understand conceptually, ready to learn hands-on" is a good answer
My notes
13 Resume-Based Q&A

Questions from Your Profile & Experience Gap DEFINITELY ASKED

Your resume says nearly 2 years experience but this role asks for 3. How do you justify that?
My formal employment totals nearly 2 years across Optipace and Semicon Media, but my hands-on electronics work started during undergraduate in 2019 — that's over 6 years of active involvement with microcontrollers, sensors, PCBs, and debugging. I've published a hardware library, designed and fabricated boards, led testing workflows, and run a live production IoT system. The hands-on depth is comparable to someone with 3 years of formal employment who spent those years on a narrower set of activities. I'm being honest about my formal work history, and I'd rather demonstrate capability directly than inflate a number on paper.
What testing and debugging tools have you personally used?
I've used digital multimeters for all standard measurements — DC voltage, continuity, resistance, diode testing. Oscilloscopes for signal integrity verification, power rail noise analysis, and protocol timing. Logic analysers for decoding I2C, SPI, and UART communication — specifically for debugging sensor communication failures where I needed to see the actual bytes being transmitted. Power supplies for bench testing with current limiting. I've also used serial terminals for UART debug output from microcontrollers. I'm comfortable setting up a complete debug bench independently.
Your resume mentions FreeRTOS — explain it and how you used it.
FreeRTOS is a real-time operating system for microcontrollers. It lets you structure firmware as multiple independent tasks that run concurrently, managed by a scheduler. Key primitives: tasks (like threads — each with its own stack), queues (for passing data between tasks safely), semaphores (for synchronisation — one task signals another that data is ready), and task priorities (higher priority tasks preempt lower priority ones). In practice on ESP32 and nRF52, I used FreeRTOS to separate sensor polling — which needed to happen on a strict schedule — from BLE communication — which had variable timing depending on connection events. Without RTOS, one would block the other. With separate tasks at appropriate priorities, both ran correctly. The most important thing to remember is that shared data between tasks must be protected — using mutexes or disabling interrupts — or you get race conditions.
My notes

Questions from Optipace & Semicon Media DEFINITELY ASKED

You "led an engineering team in testing workflows." How big was the team and what did leading mean practically?
It was a small cross-functional group — firmware developers and hardware engineers working on the same product. Leading the testing workflow meant I was the point person who: organised the test sequence (what to test, in what order, on what units), tracked results as they came in, triaged failures as they appeared (is this a known issue or a new one?), and coordinated with the firmware or hardware engineer responsible for each failing area. I maintained the test result log and drove the validation cycle forward — making sure failures didn't just get noted but got actively investigated. I wasn't managing people's careers — I was coordinating a technical activity so it moved efficiently.
Why did you leave Optipace after 16 months?
The specific projects I was supporting reached their completion milestone — the reference designs were validated and handed over. That's a natural end point in project-based work. Rather than wait for the next project cycle, I took the opportunity to broaden my experience at Semicon Media. In hindsight, the Semicon role was valuable for breadth but it's a content-focused environment, not a product engineering environment. This role at Foxconn is the environment I should have sought next — structured engineering, real production scale, proper quality methodologies.
What USB work did you do — what exactly did you implement and test?
Primarily USB CDC — the Communication Device Class that makes an embedded device appear as a virtual serial port on the host computer. I worked on getting correct enumeration, which requires the USB descriptor structure to be right — device descriptor, configuration descriptor, interface descriptor, endpoint descriptors. I verified enumeration using a protocol analyser and resolved descriptor issues that caused "Unknown Device" errors. I also tested data transfer — throughput, latency, correct framing. My USB experience is at the application layer — using a USB stack library — not at the physical signalling or protocol stack implementation level.
Tell me about MAX98357A — what is it and how did you use it?
The MAX98357A is a Class D audio amplifier IC with an I2S digital audio input. Class D means it uses PWM switching at high frequency to drive a speaker — very efficient compared to linear amplifiers. I2S (Inter-IC Sound) is a three-wire synchronous serial bus for audio data: bit clock, word select (left/right channel), and serial data. I connected it to an ESP32, configured the I2S peripheral on the ESP32 to output audio data at the correct sample rate and bit depth (44.1kHz, 16-bit), and verified the audio output. The MAX98357A has a shutdown pin and a gain control pin — I configured these for the required output level. It was used as a demo project for streaming audio from the internet through the ESP32 to a speaker.
My notes

Deep Dive: PZEM Library & Modbus RTU Questions DEFINITELY ASKED

What exactly is Modbus RTU and how did you implement it?
Modbus RTU is a serial communication protocol originally developed for industrial automation. RTU means "Remote Terminal Unit" — it transmits data as binary bytes (not ASCII). It runs over UART, typically over RS485 physical layer for multi-device bus use, or RS232 for point-to-point. Every Modbus transaction: Master sends a request frame containing — device address (1 byte, identifies which slave), function code (1 byte, tells the slave what to do), data (register address + quantity for read requests), CRC16 checksum (2 bytes, detects transmission errors). The slave responds with: its address, function code, byte count, data, CRC. In my library I implemented: CRC16 calculation (using the Modbus polynomial 0xA001), building the request frame for function code 0x04 (Read Input Registers), sending it over serial, waiting for the response, validating the CRC of the response, and parsing the register values — scaling the raw 16-bit integers by the appropriate factors (e.g., voltage raw value / 10 = volts).
What were the specific register addresses for the PZEM-004T V4?
From the datasheet: Voltage at 0x0000 (raw value / 10 = volts), Current at 0x0001-0x0002 (32-bit value / 1000 = amps), Power at 0x0003-0x0004, Energy at 0x0005-0x0006, Frequency at 0x0007 (raw / 10 = Hz), Power factor at 0x0008 (raw / 100). The V4 uses a default device address of 0xF8. One of the main improvements in my library over existing ones was correctly handling the 32-bit registers — reading them as two consecutive 16-bit registers and combining with correct byte ordering.
How did you make it work on Arduino UNO R4 specifically?
The UNO R4 uses a Renesas RA4M1 MCU — different from the classic ATmega328P. The UART timing and interrupt handling behave slightly differently. I had to verify that the serial timing was accurate enough for Modbus (Modbus has strict inter-character timing requirements — a gap of 3.5 character times between frames). I tested with a logic analyser to confirm the byte timing was within spec, and adjusted the inter-frame delay in my library to work reliably on the R4's serial implementation.
My notes

Skills Section Deep Dive DEFINITELY ASKED

I2C vs SPI — in detail, when would you choose each and why?
I2C advantages: only 2 wires for any number of devices (address-based selection), simple wiring especially for many sensors, pull-ups handle bus contention gracefully, standard 100kHz / 400kHz speeds are sufficient for most sensors, clock stretching allows slow slaves to hold the clock. Choose I2C for: slow sensors (temperature, humidity, light), many devices on limited pins, low-speed configurations. SPI advantages: faster (can run at tens of MHz vs 400kHz max for I2C standard), full-duplex (simultaneous send/receive), simpler protocol (no addressing, no ACK), no pull-ups needed, better noise immunity. Choose SPI for: fast peripherals (displays, ADCs, flash memory), when you need maximum throughput, when you have spare GPIO for CS pins. In my hydroponics project, I used I2C for the SHT40 temperature sensor and the LCD — both slow, both worked well at 100kHz. For a data logger that needed to write to flash memory quickly, SPI would be the right choice.
You list BLE — what specifically have you done with Bluetooth Low Energy?
On the nRF52 platform, I worked with BLE for wireless data transfer. BLE uses a GATT (Generic Attribute Profile) model. You define a Service — a logical grouping of related data. Inside the service are Characteristics — the actual data items. Each characteristic has a UUID, a value, and properties (read/write/notify). I defined custom services and characteristics for the reference designs — for example, a service for sensor data with characteristics for temperature, humidity, and battery level. The central device (phone or PC) discovers the peripheral, connects, and reads or subscribes to notifications on characteristics. I used the Nordic nRF5 SDK and also the Arduino BLE library depending on the project. I'm familiar with BLE advertising (periodic broadcasts for discovery), connections, and GATT read/notify operations — but not at the protocol stack level (HCI, L2CAP layers).
Soldering and reworking — what have you actually done?
Through-hole soldering with a temperature-controlled iron — PTH components, connectors, pin headers. SMD hand-soldering — 0805 and 0402 passive components, SOT-23 transistors, SOIC ICs. For 0402 components I use flux, fine-tip iron at 320°C, and tweezers. Rework: removing SMD components with solder wick, hot air for ICs. Identifying cold joints visually — the dull, grainy appearance compared to a good shiny joint. I haven't done BGA rework (requires hot air rework station, reballing, and X-ray verification) but I understand the process. For inspection I use a USB microscope — it makes cold joints and solder bridges easy to spot.
My notes
14 General Interview Questions

Technical Rapid-Fire — Full Answers DEFINITELY ASKED

What is the difference between a microcontroller and a microprocessor?
A microcontroller integrates the CPU, RAM, flash memory, and peripherals (UART, SPI, I2C, ADC, PWM, GPIO) all on a single chip. It's self-contained and designed for embedded applications — it runs firmware directly from its internal flash without an operating system (or with a lightweight RTOS). Examples: ESP32, nRF52, STM32, ATmega328P. A microprocessor is just the CPU — it needs external RAM, external storage, and external peripherals on separate chips connected via high-speed buses. It's designed to run a full operating system. Examples: ARM Cortex-A53 in Raspberry Pi 4, Intel Core i5. The Raspberry Pi 4 uses a microprocessor running Linux. The ESP32 is a microcontroller running firmware you write.
What is a pull-up resistor and why is it needed on I2C?
A pull-up resistor connects a signal line to the supply voltage (VCC) through a resistance, so that when nothing is actively driving the line, it defaults to HIGH. I2C uses open-drain (or open-collector) signalling — devices can only pull the line LOW by turning on a transistor to GND. They have no ability to actively drive the line HIGH. Without a pull-up resistor, when all devices release the line (stop pulling it LOW), the line floats — it has no defined voltage and will sit at whatever noise picks up. With pull-up resistors, the resistor continuously pulls the line toward VCC, so the line goes HIGH when released. Typical I2C pull-up value: 4.7kΩ for 100kHz standard mode, 2.2kΩ for 400kHz fast mode. Too large = too slow rise time. Too small = excessive current and may exceed device sink capability.
What is PWM and where is it used in electronics?
PWM stands for Pulse Width Modulation. A digital output signal is switched rapidly between HIGH and LOW. The duty cycle — the percentage of time the signal is HIGH — controls the effective average voltage. A 50% duty cycle at 3.3V delivers an average of 1.65V. Applications: LED brightness control (dim an LED without wasting power in a resistor), motor speed control (average voltage determines motor speed — duty cycle from 0% to 100% gives full speed range), servo motor position control (specific pulse widths from 1ms to 2ms control angle), DAC approximation (a low-pass filter on a PWM output gives an analog voltage), battery chargers. Key parameter: PWM frequency must be high enough that the load doesn't respond to individual pulses — for LEDs, above ~1kHz prevents visible flicker; for motors, typically 10–50kHz; for audio applications, hundreds of kHz.
What is ESD and how do you protect circuits from it?
ESD — Electrostatic Discharge — is the sudden transfer of static electrical charge built up on a person or object to a circuit. Human body can accumulate several thousand volts of static charge just from walking on carpet. When this discharges through an IC pin (which happens in nanoseconds), the resulting current pulse can permanently destroy the IC's input stage. The damage may be immediate (device completely dead) or latent (device works initially but fails weeks later under normal operating conditions). Protection methods — at design level: TVS diodes (Transient Voltage Suppressors) or dedicated ESD protection ICs on all external-facing pins (USB, connectors, GPIOs that connect to external cables), proper grounding, ESD protection in the IC's process technology. At manufacturing level: ESD wrist strap connected to ground, ESD mat on workbench, ionising air blower for large assemblies, anti-static bags for component storage and shipping, humidity control (dry air is more prone to static build-up).
What is a watchdog timer and why is it important?
A watchdog timer is a hardware timer that runs independently of the main CPU. The firmware must periodically "kick" the watchdog — reset the timer — before it counts down to zero. If the firmware fails to kick the watchdog within the timeout period, the watchdog resets the entire microcontroller. This is a fundamental reliability mechanism for embedded systems that must operate unattended. If firmware enters an infinite loop (due to a bug, data corruption, or hardware glitch), gets stuck waiting for a peripheral that never responds, or has a stack overflow, the watchdog detects the stuck condition and forces a recovery reset. Without a watchdog, a stuck firmware would stay stuck forever. Critical for any product that can't be manually power-cycled by a user — industrial controllers, IoT sensors, medical devices, automotive systems. The watchdog timer in most MCUs is in a separate clock domain specifically so it continues running even if the main CPU clock fails.
What is the purpose of a decoupling capacitor and where exactly does it go?
A decoupling capacitor (bypass capacitor) filters noise from a power supply rail and provides instantaneous current to an IC when it switches. Every time a digital gate inside an IC switches state, it demands a brief pulse of current from the power supply. Without a local charge reservoir, this current pulse travels from the distant power supply through PCB traces — which have inductance — causing a voltage dip (the IC is momentarily starved of current) and an inductive voltage spike. Both cause noise that affects the IC's own operation and couples to adjacent circuits. A 100nF ceramic capacitor placed right next to the IC's VCC pin acts as a local reservoir — it supplies the switching current instantly without waiting for the distant supply. The capacitor must be as close as physically possible to the VCC pin with the shortest trace back to the GND pin. Distance kills effectiveness because trace inductance defeats the purpose. For ICs with high current demands, add a 10µF bulk capacitor nearby in addition to the 100nF ceramic — the ceramic handles high-frequency switching transients, the bulk cap handles slower, larger demand variations.
What is the difference between volatile and non-volatile memory?
Volatile memory loses all data when power is removed. SRAM (Static RAM) and DRAM (Dynamic RAM) are volatile. In microcontrollers, SRAM holds variables, stack, and heap during execution — all of this disappears on reset or power loss. Non-volatile memory retains data without power. Flash memory retains the program code (firmware) through power cycles — this is why a microcontroller restarts from your code after power-on. EEPROM (Electrically Erasable Programmable ROM) retains small amounts of data (calibration values, device ID, user settings) across power cycles — but has limited write endurance (typically 100,000 write cycles). For any data that must survive a reset — user settings, calibration coefficients, fault logs, device configuration — you must explicitly save it to flash or EEPROM. It doesn't happen automatically. Many debugging headaches come from firmware that assumes a variable retains its value across resets when it's in SRAM and actually resets to its initialisation value every boot.
RS232 vs RS485 — what's the difference and when do you use each?
RS232 is a single-ended serial standard — voltage is measured relative to a common ground. Typically ±12V swing (higher voltage than logic levels for better noise immunity). Point-to-point only (one transmitter, one receiver). Maximum cable length about 15 metres at 9600 baud. The voltage levels are incompatible with logic-level UARTs (which operate at 0–3.3V or 0–5V), so a MAX3232 or similar level shifter is needed. RS485 is a differential serial standard — uses two wires (A and B), and the receiver detects the difference between them. If A is 200mV higher than B, it's a "1". This differential nature makes RS485 highly immune to common-mode noise (noise that affects both wires equally is cancelled out). Supports multi-drop (up to 32 devices on one bus), long distances (up to 1200m at 100kbaud), higher speeds at shorter distances. Modbus RTU (my PZEM library) uses RS485. Industrial equipment, building automation, energy meters — all RS485. You'll encounter both at Foxconn — RS232 for local instrument communication, RS485 for production line control systems.
My notes

NPI & FA Specific Questions — Full Answers DEFINITELY ASKED

What is NPI? What does an NPI engineer do day to day?
NPI — New Product Introduction — is the engineering phase that transitions a product from design completion to full mass production. The NPI phase validates that the design can be manufactured reliably and at scale, with acceptable yield. An NPI FA engineer's day-to-day: receive failed units from the production line or test stations. Triage them by symptom. Investigate root causes using electrical measurements, visual inspection, and physical analysis tools. Write FA reports. Participate in 8D corrective action processes. Work with design engineers on ECNs. Participate in FMEA reviews. Monitor yield trends across builds. Present findings in customer review meetings. Update test procedures when new failure modes are found. Essentially: be the person who figures out why things break and ensures they break less often.
What is yield? How do you measure it and how do you improve it?
Yield is the percentage of manufactured units that pass all required tests and meet specifications. First-pass yield (FPY) = units passing all tests on first attempt / total units attempted, expressed as a percentage. Rolled throughput yield (RTY) = product of FPYs at each station — a unit must pass station 1 AND station 2 AND station 3, so if each is 95%, RTY = 0.95³ = 85.7%. To improve yield: measure it broken down by test station and by failure mode. Do Pareto analysis — identify the top 2–3 failure modes that account for most failures. For each: FA to find root cause, corrective action to eliminate it, verify yield improvement after implementation. Cycle: measure → analyse → act → measure again. The improvement is only confirmed when yield data shows a sustained change, not just a one-build improvement.
ICT vs FCT — explain both and when each is used.
ICT — In-Circuit Test — tests a bare PCBA before it's assembled into a product. A bed-of-nails fixture contacts every test point on the board simultaneously. The tester checks: component values (correct resistors, capacitors, inductors), connectivity (no open traces, no solder bridges), and basic functionality of individual circuits. ICT catches assembly errors — wrong components, missing components, solder defects. Very fast (seconds per board) and catches problems early before expensive assembly steps. Limitation: doesn't catch firmware issues or system-level failures. FCT — Functional Test — tests the fully assembled product in its final configuration, simulating real operating conditions. It exercises all functions: power on, BLE connection, sensor readings, button inputs, display output, camera, audio. FCT catches: firmware bugs, integration issues, marginal components that pass ICT but fail under real load. Limitation: slower, and a failure here is more expensive to analyse because the unit is fully assembled. The two tests are complementary: ICT catches assembly defects early and cheaply; FCT catches functional failures that need the complete system to manifest.
How do you write a failure analysis report?
A complete FA report includes: (1) Unit identification — serial number, build date, batch number, which test it failed and at which station. (2) Failure description — exactly what symptom was observed, under what conditions. (3) Initial inspection findings — visual inspection results with photos. (4) Electrical characterisation — all measurements taken, compared to expected values, with photos of scope traces or measurement setups if relevant. (5) Fault isolation — step-by-step description of how you narrowed down the failure. (6) Root cause statement — precise statement of what failed and why, supported by the evidence from steps 3–5. (7) Root cause classification — design / material / process / workmanship / environment. (8) Corrective action recommendation — what specific change is recommended to prevent recurrence. (9) Evidence — attach all photos, scope captures, X-ray images, EDS spectra. The report must be written so someone who was not in the lab can follow your logic, understand the evidence, and agree (or disagree) with your root cause conclusion. That's the standard.
My notes

Situational & Behavioural Questions DEFINITELY ASKED

Tell me about a time you disagreed with a colleague and how you resolved it.
At Optipace, during a validation cycle we had a board with erratic resets. My colleague believed it was a firmware bug — the MCU was running out of stack. I had measured the 3.3V power rail with an oscilloscope and seen it drooping to 2.8V under load — a power supply issue. Instead of arguing about whose hypothesis was right, I proposed we test both simultaneously: firmware team would check stack usage while I set up current monitoring. I put the scope on the 3.3V rail with a long time capture and triggered on the reset signal going active. The capture showed clearly: the reset occurred exactly 50ms after the 3.3V rail started drooping below 2.5V. The scope evidence settled it definitively — power issue, not firmware. The fix was increasing bulk capacitance on the 3.3V rail. The lesson: disagreements in engineering are resolved by evidence, not by rank or persistence.
How do you prioritise when you have multiple failing units and limited time?
Triage first — categorise all failures by symptom in 15–20 minutes. Group identical symptoms together. Now I know: are these all the same failure mode (most efficient — one root cause fixes all), or multiple different modes (need prioritisation). Priority framework: (1) Highest volume failure mode first — fixing one root cause helps the most units. (2) Within that, start with the unit that shows the symptom most clearly and reproducibly — clearest symptoms are easiest to root-cause. (3) Any safety-relevant failure takes absolute priority regardless of volume. (4) If some failures are likely to be outliers (one-off handling damage), set them aside and revisit if time allows. I communicate the priority order to my lead so everyone knows what's being worked and what's waiting. Transparency about what I'm NOT working on is as important as what I am.
Tell me about a situation where you had to learn something new quickly.
When I needed to write the PZEM library, I had never worked with Modbus RTU before. I had about a week to understand the protocol, implement it correctly, and validate it. I started with the Modbus specification — read the frame structure, function codes, CRC calculation algorithm. Then I read the PZEM-004T V4 datasheet cover to cover — specifically the register map. I implemented the CRC16 first and verified it against known test vectors. Then I built the request frame and sent it, capturing the response on a logic analyser to verify the slave was responding correctly before I tried to parse anything. Building it layer by layer — verify each layer before adding the next — let me find errors at their source. Within 4 days I had a working implementation. The approach: understand the specification thoroughly before writing a line of code, build incrementally, verify each step with instruments. This is the same approach I'd apply to learning a new FA tool or test instrument.
My notes

Questions YOU Should Ask Them ASK AT LEAST 2

Asking good questions shows you've thought seriously about the role and are evaluating them, not just hoping to be selected. It changes the dynamic from "please hire me" to "let's see if this is a good fit." Always ask at least 2.

What does the typical NPI cycle look like for a new product at this facility — from first samples to mass production ramp?
(This shows you understand NPI phases and want to understand the actual workflow. Listen carefully — it tells you what your daily work will be.)
What are the most common failure modes you see during NPI for the product types this team works on?
(Shows you're already thinking analytically about the job. Their answer may reveal what skills they value most.)
Which FA tools — SEM, EDS, X-ray — are available in-house, and which do you use external labs for?
(Shows you know the tools involved and are thinking practically about how to do the job.)
What does the onboarding process look like for a new engineer joining this team?
(Shows you're planning to be productive quickly and integrate well. Also tells you how much support you'll get early on.)
My notes
15 Twisted & Real-World Scenario Questions

Twisted Theory Questions — Explained in Full WATCH OUT

These questions take a concept you know and flip the angle. They catch people who memorised without understanding. Read the explanation, not just the answer.
A capacitor is fully charged in a DC circuit. How much current is flowing through it?
Zero. Here's why: a capacitor charges up to match the supply voltage. Once the voltage across the capacitor equals the supply voltage, there's no potential difference to drive further current flow — so current stops. In DC steady state, a capacitor is an open circuit. This is why capacitors block DC — after the initial transient charging period, no DC current flows through them. Current only flows through a capacitor while the voltage across it is changing. This is also why you must discharge a large capacitor before working on a powered-off circuit — it stores charge at supply voltage and can deliver a dangerous current pulse long after the supply is disconnected.
You measure 3.3V on a GPIO pin with a DMM. Does that confirm the pin is driving correctly?
Not necessarily — and this is a common debugging mistake. A DMM has very high input impedance (typically 10MΩ). It draws almost no current from the circuit. So even a weakly driven pin, a floating pin with a slight bias, or a pin connected through a very high resistance will show a voltage on the DMM. The real test is whether the pin can source or sink the current required by the load. When you connect the actual load (another IC's input, an LED, a transistor base), the voltage might collapse. The right test: measure the pin voltage with the actual load connected, not just with the DMM probe alone. If the voltage holds at 3.3V under real load conditions, then yes, the pin is driving correctly. An oscilloscope also helps here — it shows whether the voltage drops during switching events that the DMM's averaging would miss.
Scope shows a clean 3.3V SPI clock. The sensor still doesn't respond. You've confirmed CS is toggling. What next?
Clock clean + CS correct — those two are confirmed. Work through the remaining possibilities systematically: (1) MOSI data: is the master actually sending the right command bytes? Put the scope or logic analyser on MOSI and verify the bit pattern. (2) SPI mode: many sensors only work in one CPOL/CPHA mode. Mode 0 (clock idles LOW, sample on rising edge) is most common, but some sensors need Mode 1, 2, or 3. Check the sensor datasheet SPI section — it specifies the required mode. Wrong mode means data is sampled at the wrong clock edge — bytes look valid electrically but are interpreted incorrectly. (3) Clock frequency: some sensors have a maximum SPI clock speed. If your master is running at 10MHz but the sensor's max is 4MHz, it will silently drop data. (4) Sensor power — is the sensor's VCC actually at the right voltage? A regulator with an enable pin that isn't asserted could explain this. (5) Is the sensor responding on MISO at all? If it is but the master is ignoring it or not reading it correctly, the problem is on the software side.
Two identical boards from the same batch — one works perfectly, one doesn't. What does this tell you and how does it change your approach?
This is excellent diagnostic information. It tells you the design is almost certainly correct — if there was a fundamental design flaw, both boards would fail the same way. The failure is most likely an assembly defect or component variation on the specific failing board. This changes your approach completely: instead of investigating the design (which wastes time), you use the working board as a golden reference. Place the two boards side by side. Measure the same test points on both simultaneously or sequentially. Every measurement that matches between them = not the root cause of the difference. Every measurement that differs = suspect area. You're doing a differential diagnosis. Start with power rails (usually match), then communication lines, then specific IC pins. The first measurement that shows a significant difference between the two boards tells you exactly where to look next. This approach can find a cold solder joint or a wrong component value in 10 minutes that would take an hour without the reference board.
Board works fine at room temperature but fails after 30 minutes of operation. What are the possible causes and how do you investigate?
This is a thermal failure — something is marginal at room temperature but fails when it heats up. Systematic investigation: (1) Use a thermal camera (FLIR or similar) to image the board during normal operation. Hot spots above ambient appear clearly — identify any component running significantly hotter than its neighbours. Alternatively, carefully touch components with a finger (POWER OFF first — or use a non-contact IR thermometer) looking for unusual heat. (2) Common culprits: electrolytic capacitors — their capacitance and ESR change with temperature, and if they're already at the edge of specification, heating pushes them out of spec. Electrolytic caps also dry out over time (accelerated by heat). A cap failing this way will cause power supply instability or signal filtering failures. (3) Solder joints — thermal cycling causes expansion and contraction. A marginal cold joint may have enough mechanical contact at room temperature but opens when the PCB expands. Detected by cross-section analysis after failure. (4) Power regulator — LDOs go into thermal shutdown when they exceed their junction temperature (typically 125–150°C). Calculate: at your load current, is the power dissipation within the LDO's thermal limit given your PCB's thermal dissipation capability? (5) Crystal oscillator — frequency drifts with temperature. If the MCU or UART baud rate depends on an oscillator with poor temperature stability, communication errors can appear at elevated temperature. (6) Test: put the board in an oven or use a heat gun carefully to heat individual areas — see which area triggers the failure. Or run the board with the fan blowing cold air on the suspect component — if the failure stops, you've confirmed the thermal culprit.
You replaced the capacitor and the board works. Is your FA job done?
Absolutely not — and this is a critical point for an FA engineer. Replacing the component is only the symptom fix. The FA job is to answer: why did this capacitor fail in the first place? Was it the wrong voltage rating for the circuit? Was it placed with reversed polarity during assembly? Was it a counterfeit part with substandard dielectric? Was it thermally overstressed because it was placed too close to a heat source? Was it a batch problem — are all capacitors from that reel potentially affected? The answer to "why" determines: (1) Whether other boards in the batch have the same risk, (2) Whether all boards of this product type are affected, (3) What corrective action is actually needed — a design change, a process change, or a supplier change. If you stop at "replaced the cap, board works, done" — the same failure will appear in 1000 units in the field and you'll be doing the same FA again. Document the root cause. Check the other boards. Initiate the corrective action. That is the complete FA job.
DMM beeps continuity between VCC and GND. Is this always a short circuit problem?
Not always — and reacting immediately to the beep without checking the schematic is a mistake. A continuity beep means resistance between the probes is below about 30Ω. Many legitimate circuits have low-resistance paths between VCC and GND: an LED in series with a 100Ω resistor (total ~100Ω — might not beep, but close), a small value pull-down resistor on a power rail, a forward-biased protection diode, an LED power indicator circuit. Before concluding it's a short: check the schematic for any low-impedance path between VCC and GND. Then switch to resistance measurement mode — read the actual ohm value. A true dead short shows near-zero resistance (0–2Ω) and usually a component getting hot immediately when power is applied. A 50–200Ω reading is likely a legitimate circuit path. A resistive short (few tens of ohms) may indicate a partial failure — like a damaged IC with its ESD structures conducting. The beep is a starting point, not a conclusion.
You increase I2C pull-up resistor from 4.7kΩ to 47kΩ. Explain exactly what happens to communication.
The SDA and SCL lines become slower to rise from LOW to HIGH. Here's the physics: the pull-up resistor and the total bus capacitance (PCB trace capacitance + device pin capacitance, typically 50–200pF) form an RC circuit. The time constant τ = R × C. With 4.7kΩ and 100pF: τ = 4700 × 100×10⁻¹² = 470ns. With 47kΩ: τ = 47000 × 100×10⁻¹² = 4700ns = 4.7µs. At 400kHz fast mode I2C, each bit period is 2.5µs. The line must rise to above the HIGH threshold (0.7 × VCC = 2.31V for 3.3V system) within the allowed rise time. With a 4.7µs time constant, the line won't reach HIGH threshold before the next bit should start — the receiver sees corrupted data or no ACK, and communication fails. Symptoms: sporadic communication errors, devices not responding, NAKs instead of ACKs, complete communication failure. The rule: higher I2C speed requires lower pull-up resistance value. Lower pull-up resistance means more current flows when the line is pulled LOW — you must verify this is within the device's sink current capability (check datasheet — typically 3mA for standard I2C).
A 5V sensor output is connected directly to a 3.3V MCU GPIO input pin. The sensor drives 5V HIGH. What is the exact risk and what are the fix options?
The risk: most 3.3V GPIO input pins have an absolute maximum rating of VDD + 0.3V to 0.5V on the input (so about 3.6V for a 3.3V system). Applying 5V to such a pin exceeds this rating and can: (a) Immediately destroy the ESD protection diode inside the GPIO — the diode clamps the pin to VDD + 0.7V ≈ 4V but dissipates the excess as power — if the current is high enough the diode burns out. (b) Cause latch-up — a parasitic SCR (thyristor) structure inside the CMOS IC turns on, creating a low-resistance path from VCC to GND through the IC, potentially destroying the entire chip. (c) With some MCUs, it works unreliably — the pin reads "high" correctly but slowly degrades over time (latent damage). Check first: some MCUs explicitly mark certain GPIO pins as "5V tolerant" in the datasheet (STM32 marks these as "FT"). If your specific pin is 5V-tolerant, direct connection is safe. Fix options for non-tolerant pins: (1) Voltage divider — 10kΩ from sensor output, 20kΩ to GND — output is 5V × 20/(10+20) = 3.33V — simple but only works for unidirectional signal going INTO the MCU. (2) Dedicated level shifter IC — BSS138 MOSFET circuit or TXS010x — works bidirectionally, preserves signal integrity. (3) Zener diode clamp — 3.3V Zener in reverse from signal line to GND, with series resistor — simple but slower, not suitable for high-speed signals.
My notes

Real-World Scenario Questions — Full Detailed Answers DEFINITELY ASKED

You're given 50 failed units from the production line and 4 hours. Walk me through exactly what you do.
First 30 minutes — triage. I power on each unit briefly and categorise: completely dead (no LED, no response), partially functional (powers on but fails specific test), intermittent (sometimes passes). I record the symptom for each unit and look for groupings. This tells me: is this one failure mode (most efficient — one root cause) or several different modes (need to prioritise)? Next I pick the largest group — most units with the same symptom. I start there because one root cause fix helps the most units. Visual inspection of 5–10 units from the largest group under magnification. Looking for: anything visually abnormal, any pattern (are the same components looking wrong across multiple boards?). Electrical measurements on 5 units from the group: power rails at all key test points, noting any that deviate from spec. Compare against a known-good unit if available — every measurement that matches the known-good is eliminated. The first measurement that shows a consistent difference across the failing group is the fault area. By hour 2 I should have a leading hypothesis. By hour 3 I should have isolation to a specific component or circuit area. By hour 4: a written preliminary root cause statement with supporting measurement data, a containment recommendation (quarantine this batch? 100% inspection at station X?), and a plan for the next steps (additional analysis needed? ECN required?). I may not have a final confirmed root cause in 4 hours — and that's honest. But I should have a clear direction and documented evidence, not just "I'm still looking."
Customer says their phone screen turns off randomly while on a call when they hold it near their ear. Walk through your investigation.
This is classic proximity sensor behaviour — the screen turns off when the sensor detects the phone near the ear, which is the designed function. "Random" turn-off means: the sensor is triggering when it shouldn't (false near detection), or it's not recovering properly once the phone is removed from the ear. Systematic investigation: (1) Reproduce the issue — hold the phone to your ear exactly as described. Does it consistently turn off? What's the detection threshold — how close does your ear need to be? Can you reproduce it by holding any object near the sensor window, or only with the specific orientation described? (2) Read the proximity sensor register values in real time (using ADB on Android, or a debug build) — what raw count value does the sensor report during normal operation, and what does it spike to when the screen turns off? Compare to the near threshold register setting. (3) Test for crosstalk — in a completely dark room with no external objects near the phone at arm's length: what does the sensor read? If it reads above the near threshold in open air with nothing nearby, that's crosstalk from the device housing. (4) Check the sensor window — any adhesive, protective film, cosmetic damage? (5) Test multiple units — is this one unit or all units from the batch? If one unit, likely a physical defect. If all units, likely a calibration or firmware threshold issue. (6) Check the near threshold register value in firmware — compare to the design specification. A firmware update that changed the threshold would cause systematic false triggering. (7) Environmental test — does it happen more in bright sunlight? That would indicate insufficient ambient IR cancellation.
A new PCB revision arrives. The previous revision worked. The new one doesn't power on. First move?
Get the ECN — the Engineering Change Notice that documents exactly what changed between revisions. Read it carefully. This is the most valuable piece of information you have — it tells you precisely where to look first. Focus ALL initial investigation on the changed areas. Changes common in revisions and their failure modes: (1) Component change — new component might have different enable polarity, different pin assignment in same package, different startup timing, or different enable voltage threshold. Check the new component's datasheet against the schematic to verify all connections are correct for the new part. (2) Layout change — trace rerouted near a noise source? Ground pour modified? Pull-up/pull-down resistor value changed? (3) Power section modification — any change to the regulator circuit, enable control, or power sequencing. With the ECN in hand, probe the changed areas with the scope. Power up both old and new revision simultaneously (or sequentially) and measure the same test points. The first test point where they differ is in the changed area or downstream from it. Measure the enable signals for the power regulators — is the enable pin being asserted? Check the power sequence — does the 1.8V rail come up before the 3.3V rail as required? A revision that changes power sequencing can cause the MCU to fail to boot even if all rails look correct statically.
30% of boards are failing ICT resistance check on R15. X-ray shows no solder defects. What do you investigate?
30% failure rate is strongly systematic — not random assembly defects (which would be lower percentage and scattered). And X-ray rules out solder joint issues. Remaining possibilities: (1) Wrong component value on R15. The most common cause of systematic ICT resistance failures. At the production line, when a component reel runs out, a new reel is loaded — sometimes the wrong reel. Measure the actual resistance of R15 on several failing boards with a DMM (with power off, one lead lifted to break parallel paths). If all failing boards show the same wrong value, it's a reel change problem. Check the reel currently in use at the pick-and-place machine. (2) ICT fixture contact problem. The probe pin for R15's test point may be worn, bent, or misaligned — it's making intermittent contact, causing false open or high-resistance readings. Test: manually press the probe pin with a small tool — does the reading change? Replace the probe pin and retest. (3) Parallel path in circuit. The ICT tester measures R15's resistance by driving a known current through it. But if there's another component in parallel with R15 in the circuit (a capacitor in parallel with high leakage, or another resistor), the measured value will be wrong even if R15 itself is correct. Check the schematic — is anything in parallel with R15? The ICT fixture may need its in-circuit compensation adjusted. (4) Component tolerance vs ICT limit. If R15 is 10kΩ ±5% and the ICT limit is 10kΩ ±3%, components at the edge of tolerance will fail the tighter test limit. Widen the ICT limits to match the component's actual tolerance specification.
A product passes all tests in your lab but consistently fails at the customer's installation. What is your investigation process?
The variable is the environment. A product that works in one environment and fails in another tells you the product is sensitive to some environmental condition that differs between your lab and their site. Structured investigation: (1) Characterise both environments. Ask the customer: ambient temperature range, humidity, altitude (affects air pressure and cooling), power supply quality (voltage regulation, noise, frequency stability), presence of other equipment (EMI sources — industrial motors, welders, RF transmitters), grounding quality (is the product properly earthed?), installation orientation (affects cooling). Compare these to your lab conditions. (2) Identify the environmental factors that differ most significantly. Prioritise investigation on the biggest differences. (3) Replicate in your lab. Temperature: run the product in a temperature chamber at the customer's ambient range — particularly the extremes. Power supply: use a variable supply to test at ±10% of nominal voltage; add noise with a signal generator to simulate poor power quality. EMI: bring the product close to known EMI sources, or use a radiated emissions test setup in reverse (inject RF and see if the product is affected). Humidity: if possible, test in a humidity-controlled environment. (4) If you can reproduce the failure in the lab under simulated customer conditions — you've found the sensitivity. Then FA proceeds normally. (5) If you cannot reproduce: visit the customer's site with instruments. Measure power supply voltage and noise at the installation, measure ambient temperature throughout the day, capture any RF environment. One on-site measurement session often reveals the cause immediately.
My notes

Calculation Questions — Worked in Detail PRACTICE THESE OUT LOUD

In a virtual interview, work through calculations out loud — narrate every step. "I = V/R, so 5 divided by 100 equals 0.05 amperes, which is 50 milliamperes." Thinking out loud shows methodology even if you make arithmetic errors.
An LED needs 20mA forward current and has a 2V forward voltage drop. You're powering it from 5V. Calculate the series resistor value and its power rating.
Step 1: Voltage across resistor = supply voltage − LED forward voltage = 5V − 2V = 3V. Step 2: Resistor value = V/I = 3V / 0.02A = 150Ω. 150Ω is a standard E12 value. Step 3: Power dissipated in resistor = V × I = 3V × 0.02A = 0.06W = 60mW. A standard ¼W (250mW) resistor is more than sufficient — gives 4× safety margin. Always choose a resistor with power rating at least 2× the calculated dissipation. Total power from supply = 5V × 20mA = 100mW. Of this, 60mW is wasted in the resistor, 40mW is used by the LED (2V × 20mA).
An LDO regulator: Vin = 5V, Vout = 3.3V, output current = 500mA. Calculate power wasted as heat and efficiency.
Voltage dropped across LDO = Vin − Vout = 5 − 3.3 = 1.7V. Power dissipated as heat = V_drop × I_out = 1.7V × 0.5A = 0.85W. This 0.85W becomes heat in the LDO — you must check whether the LDO's thermal resistance (junction to ambient) allows it to dissipate this without exceeding maximum junction temperature. Efficiency = Pout / Pin = (Vout × Iout) / (Vin × Iin). Since Iin ≈ Iout (LDO quiescent current is small): efficiency = (3.3 × 0.5) / (5 × 0.5) = 1.65W / 2.5W = 66%. So 34% of input power is wasted as heat. At 1A output: waste = 1.7W, efficiency still 66%. This is why switching regulators (buck converters) are preferred for large voltage drops or high currents — they achieve 85–95% efficiency regardless of voltage drop.
An oscilloscope shows a signal with a period of 2ms. What is the frequency? If the duty cycle is 30%, what is the ON time?
Frequency = 1/Period = 1/0.002s = 500Hz. ON time = duty cycle × period = 0.30 × 2ms = 0.6ms. OFF time = 2ms − 0.6ms = 1.4ms. If this is a PWM signal driving an LED at 30% duty cycle with 5V amplitude: average voltage = 0.30 × 5V = 1.5V. The LED would appear at about 30% of maximum brightness. At 500Hz the switching is fast enough to be invisible to the human eye (which starts perceiving flicker below about 50Hz).
A 12-bit ADC has a reference voltage of 3.3V. What is the resolution? If a temperature sensor outputs 10mV/°C, what is the smallest temperature change the ADC can resolve?
ADC levels = 2¹² = 4096. Voltage resolution (1 LSB) = Vref / 2^n = 3.3V / 4096 = 0.000806V ≈ 0.8mV per step. Smallest measurable voltage change = 0.8mV. If the sensor outputs 10mV per degree Celsius: temperature resolution = 0.8mV / 10mV/°C = 0.08°C. So this 12-bit ADC with 3.3V reference can resolve temperature to about 0.08°C with this sensor — better than most people expect. A 10-bit ADC (1024 levels) gives 3.3/1024 = 3.2mV per step, or 0.32°C temperature resolution — noticeably coarser. This is why sensor interfaces often specify minimum ADC resolution requirements.
FMEA calculation: Severity = 9, Occurrence = 3, Detection = 4. What is the RPN? What does each score mean, and what would you do to reduce the RPN?
RPN = 9 × 3 × 4 = 108. Analysis of each score: Severity = 9 is very high — this failure causes significant product malfunction or safety risk, or regulatory non-compliance. This cannot be reduced by better inspection or lower occurrence — the only way to reduce Severity is to change the design so that if this failure occurs, it has a less severe effect (fail-safe design, redundancy, or eliminate the failure mode entirely). Occurrence = 3 is low — this failure mode doesn't happen often. Good. Detection = 4 — current controls catch it reasonably well but not perfectly. Priority for this RPN: since Severity is 9 (the highest concern), even though RPN = 108 is moderate, this item warrants close attention because if it does occur and slip through, the consequences are serious. Recommended actions: (1) Improve Detection — add an additional inspection or test step to catch this before it reaches the customer. Better detection lowers the D score, lowering RPN. (2) Evaluate the design for ways to reduce Severity — can the failure mode be made less catastrophic through circuit protection or graceful degradation? (3) Don't focus on reducing Occurrence if it's already at 3 — diminishing returns.
200 boards tested, 174 passed. What is the yield? How many failures do you need to Pareto-analyse? How many do you need to confirm a corrective action worked?
Yield = 174/200 × 100% = 87%. Failed = 26 boards. With 26 failures, analyse all 26 — categorise each failure mode, count occurrences, rank from most to least frequent. This is your Pareto. With small samples (under 50 failures), 100% analysis is both feasible and necessary to get a reliable distribution. If you only analyse 10 out of 26 you might miss a failure mode that appears 3–4 times. After implementing corrective action, to confirm it worked: you need a new build of sufficient sample size. Rule of thumb — to confirm that a failure mode that appeared in X% of units has been eliminated, you need approximately 3/X units to see zero failures. For a failure mode that was 5% (the most common in this example if one mode dominated), you need 3/0.05 = 60 units with zero occurrences of that mode to be 95% confident the fix worked. So the next build should target at least 60–100 units, not just 20.
My notes

Trap Questions — With Full Strategic Answers READ THESE CAREFULLY

"Your experience is mostly Arduino-level. Foxconn works at production scale with complex ICs. Are you really ready for this?"
I want to address this directly because it's a fair challenge. "Arduino-level" as a label understates the work — I used the Arduino framework as the development environment, but the work itself was on custom nRF52 and ESP32 PCBAs, debugging at the signal level with oscilloscopes and logic analysers, performing root cause analysis on real hardware failures. The framework you write code in doesn't determine the depth of the debugging. I've diagnosed power supply failures, communication protocol errors, and component defects on production-intent hardware. What I haven't done yet is FA at the scale and formality of a Foxconn production line — and I'm being honest about that. What I bring is: systematic debugging discipline, hands-on instrument skills, and the ability to learn new tools and processes quickly. The NPI FA methodology — 8D, FMEA, FA flow — I understand conceptually and am ready to apply. The production scale and specific product knowledge I'll develop on the job.
"You've changed companies after short periods. What's to stop you leaving us after 6 months?"
I understand why the pattern raises that question. The honest explanation: my first role at Optipace was project-based — the projects reached completion and the engagement naturally ended. My second role at Semicon Media was a content production environment, and I realised within a few months that it wasn't the engineering environment I needed to grow in. I made a mistake in not being more selective about that move, and I've learned from it. The Foxconn NPI/FA role is specifically what I've been trying to find — a structured engineering environment with real production problems, proper methodologies, and a clear growth path in hardware engineering. This isn't a stop-gap while I look for something else. I'm applying because this is what I actually want to build my career doing. The best answer I can give to your question is: I know what I want now, and this is it. I'd be happy to discuss what a long-term trajectory here could look like.
"Can you write bare-metal firmware in C for STM32 without HAL? Code up an I2C driver right now."
I should be honest with you: I've studied bare-metal STM32 programming — register-level clock configuration, GPIO setup without HAL, peripheral initialisation — but I haven't written a complete bare-metal I2C driver in a production context. My firmware experience has been primarily with the Arduino framework and the nRF5 SDK. I can read and understand bare-metal C code, understand what each register does, and explain the concepts. Writing it under time pressure from memory isn't something I can do reliably right now. However, I want to be clear about two things: (1) For an NPI FA role, the primary skill requirement is hardware debugging and failure analysis — not firmware authoring. FA engineers typically read and interpret firmware output, not write the firmware. (2) Bare-metal STM32 is something I'm actively working on as a development goal. I have a Nucleo F401RE on my bench with the intent to build this skill. I'd rather be honest about where I am than bluff something that an experienced engineer will immediately see through.
My notes