DFT Interview Questions: The Complete Design-for-Test Guide for India (2026)

TL;DR. DFT interviews in India test six things in order: fault-model and coverage reasoning, scan architecture and insertion, ATPG and compression depth, memory test with JTAG/IJTAG, SoC-scale DFT (hierarchical wrapping, low-power scan, automotive and security), and a real silicon bring-up or diagnosis story. Most 3-5 year candidates can define scan and stuck-at faults but flame out on at-speed timing (LOC vs LOS), why compression hurts diagnosis, shift-power, and "the chip came back at 40% yield — what do you do?" This guide gives you the 38 real questions I've asked and been asked over the last decade, with answers tuned to the 3-5 year level, plus the six-week prep plan I hand every engineer I mentor.

I've led DFT for mobile SoCs and automotive ASICs across Broadcom and Texas Instruments and have sat on both sides of well over 200 DFT loops. DFT is the specialisation nobody teaches properly in college, which is exactly why it pays: supply is thin and silicon experience doesn't transfer easily. That cuts both ways in an interview. The bar isn't "do you know what scan is" — everyone parrots that. What separates a 14 LPA offer from a 32 LPA offer is whether you can reason about test coverage versus fault coverage, explain why an X in your netlist collapses compression, and tell a real story about a pattern that failed on the tester and what it turned out to be.

Let me walk you through exactly what you'll face.

What DFT interviewers actually test

After comparing debrief notes across dozens of product-company loops, the weighting is consistent:

1. Fault models and coverage math (20%). Not definitions — the reasoning: stuck-at vs transition vs path-delay vs bridging, and the difference between test coverage, fault coverage, and ATPG coverage. This is where most candidates are vague and it shows immediately.
2. Scan architecture and insertion (20%). Chain count and balancing, lock-up latches across clock domains, shift power, clock gating in test, handling non-scan flops and X-sources. Have you inserted scan, or only run someone's script?
3. ATPG and compression (20%). LOC vs LOS at-speed, X-bounding, N-detect and cell-aware, reconvergent fanout, and the compression trade-off (pattern count down, diagnosis resolution down). The round that sets your offer level.
4. Memory test and JTAG/IJTAG (15%). MBIST algorithms and controller sharing, repair and fuses, the TAP state machine, boundary scan, IJTAG/1500 for hierarchical access.
5. SoC-scale and specialised DFT (15%). Hierarchical core wrapping, streaming scan, power-aware scan, automotive in-system test (ISO 26262), secure DFT. Increasingly asked even of mid-level candidates.
6. Silicon story (10%). The most predictive question in the loop: "walk me through a real silicon problem you debugged." Specifics or nothing.

The candidates who get product-company offers have owned test for a block or a chip through tape-out and bring-up — closed coverage, cut a pattern set that blew the tester budget, root-caused a scan-chain failure on real silicon. The ones who stall usually only ran ATPG and read the coverage number off the log.

The typical interview structure

Round 1: Technical screen (45-60 min)

Fundamentals, usually with a senior DFT engineer: what scan is and why, stuck-at vs transition faults, what test coverage means, mux-D scan cell, and a quick reasoning task like "how would you decide the number of scan chains for a block with 200k flops and 400 pins."

Round 2: Scan and ATPG deep dive (60-90 min)

You'll defend an architecture: "walk me through scan insertion end to end," "how do you handle three clock domains in one chain," "why does an uninitialized RAM output wreck your ATPG," "your at-speed coverage is 20 points below stuck-at — why, and what do you do."

Round 3: Compression, memory and hierarchy (60-90 min)

The round that sets your offer level: "draw an EDT compression architecture and tell me what it costs you," "insert MBIST for a 2MB SRAM and share the controller across four instances," "how does IJTAG let you reach a deeply embedded instrument," "how would you test a 400mm² networking chip you can't flatten."

Round 4: Silicon bring-up + managerial (60 min)

Pick a chip, pick the hardest test problem, your coverage and DPPM targets, specific numbers. Killer question: "the first samples come back and scan is failing on half the parts — walk me through it." Have a real answer with a real datalog in your head.

Round 5: HR and offer (30 min)

CTC, location, notice period. The technical decision is already made.

38 real DFT interview questions, with answers

Fault models, coverage and fundamentals (1-8)

1. Why do we need DFT — can't functional tests catch defects?
Functional vectors exercise behavior but observe almost nothing inside a billion-flop design, and writing them to target manufacturing defects is intractable. DFT adds structure — scan, BIST, JTAG — so a tester can control and observe internal nodes directly and measure defect coverage as a number. The framing interviewers want: functional test verifies the design is correct; DFT (structural test) screens each manufactured die for defects. Different goals, different vectors.

2. Define controllability and observability — why are they the whole game?
Controllability is your ability to set a node to a known value; observability is your ability to propagate that node's value to an output you can measure. A fault is only testable if you can both control the site to the opposite of the fault value and observe the effect at a scan cell or pin. Every DFT technique — scan, test points, boundary scan — exists to raise one or both. When a fault is untestable, it's almost always a controllability or observability deficit, often from reconvergent logic or an uncontrollable X-source.

3. Compare stuck-at, transition, path-delay and bridging faults — when does each matter?
Stuck-at models a node held at 0 or 1 — the baseline for structural defects. Transition (slow-to-rise/slow-to-fall) models a node that switches but too slowly — catches resistive defects and needs at-speed test. Path-delay targets specific critical paths against a timing spec — used sparingly on the paths that matter. Bridging models shorts between two nodes. At advanced nodes you can't ship on stuck-at alone: transition and cell-aware patterns catch the timing and intra-cell defects that dominate DPPM. Naming why you'd add each earns the credit.

4. Test coverage vs fault coverage vs ATPG coverage — they're not the same number.
Fault coverage = detected faults / total faults. Test coverage = detected / (total − undetectable), i.e. it credits you only against testable faults and is the number you actually sign off on. ATPG coverage / pattern coverage is what the tool reports for the patterns generated. The gap between fault and test coverage is the untestable population — tied-off logic, redundant faults, unused RAM ports. A candidate who quotes "99% coverage" without saying which metric and how untestables were classified is waving hands; interviewers push here on purpose.

5. Draw a mux-D scan cell and explain the two modes.
A scan flop is a normal flop with a 2:1 mux on its data input selected by a scan-enable: in functional mode (SE=0) it takes the functional D; in shift mode (SE=1) it takes scan-in from the previous cell in the chain. Chained together, the flops form a shift register you load and unload serially. The two operations per pattern are shift (load stimulus, unload the previous response) and capture (one functional clock pulse with SE=0 that captures the circuit's response). Getting the SE polarity and capture-vs-shift distinction crisp is table stakes.

6. Why does full scan turn sequential ATPG into a combinational problem?
Because every flop is now directly loadable and observable through the chain, ATPG no longer has to justify and propagate values across many clock cycles of sequential state — it treats each flop output as a pseudo-primary input and each flop input as a pseudo-primary output, leaving a purely combinational cone to solve per pattern. That's why full scan gives near-complete coverage and tractable ATPG runtime, and why partial scan (leftover sequential depth) tanks both. This is the single reason full scan is the default.

7. What is at-speed test and why isn't stuck-at enough?
At-speed test applies the capture edges at functional frequency so transition and delay defects — nodes that toggle but too slowly — actually fail. Stuck-at runs the capture slow, so a part with a resistive via that still switches (just late) passes stuck-at and escapes to the field, then fails at speed in the customer's board. At advanced nodes delay defects are a large share of DPPM, so transition/at-speed patterns are mandatory. The two ways to launch the transition are LOC and LOS (next question set).

8. What is scan compression and what does it cost you?
Compression (e.g. EDT) puts a decompressor between a few scan-in pins and many short internal chains, and a compactor (often a MISR/XOR network) folding many chains back to a few scan-out pins. It cuts test data volume and test time 10-100x, which is the difference between an affordable and an unaffordable tester bill on a big chip. The costs: it needs low-X designs (an unbounded X poisons the compactor), and it degrades diagnostic resolution because many chains share an output — you lose the direct chain-to-failure mapping. The honest answer names both the win and the diagnosis penalty.

Scan architecture and insertion (9-16)

9. How do you decide the number of scan chains and their length?
It's a balance of test time, pins, and power. Test time scales with the longest chain (shift cycles = max chain length × patterns), so more chains means shorter chains means faster test — bounded by available scan pins (or compression channels) and routing/congestion. You balance chains to near-equal length so no single long chain dominates, and cap length to keep shift power and shift time in budget. With compression you have many short internal chains fed by few pins, decoupling chain count from pin count. Interviewers want the three constraints named: pins, test time, power.

10. Why does scan stitching need to be physically aware?
A naive logical stitch can route a chain all over the floorplan, creating huge scan-wire length, congestion, and hold problems on the shift path. Physically-aware (or reordering) scan stitching orders flops along the chain by placement so scan connections stay local, cutting wirelength and hold-buffer count. It's done during or after placement, and getting it wrong shows up as scan-shift hold violations and routing congestion late in the flow. The point to make: DFT isn't done at RTL — the chain quality is a physical-design concern too.

11. What is shift power and why is it dangerous?
During shift, up to half the flops in the design can toggle every shift cycle — far more switching than functional mode ever sees — drawing peak and average current well above the design's power spec. That can cause IR-drop-induced yield loss (good dies fail test) or even damage. You control it with low-power ATPG (fill don't-cares to minimize transitions), shift-clock frequency limits, chain segmentation/clock-staggering, and sometimes reduced scan-enable activity. Ignoring shift power is a classic way to lose yield on an otherwise-healthy design.

12. How do clock gates behave in test, and how do you handle them?
Functional clock gates would block the shift and capture clocks, so DFT makes them transparent during scan — the scan-enable (or a test signal) forces the gate open in shift mode so every flop clocks. During capture you may want gates controllable so at-speed patterns can exercise the real gating logic. The DFT rule check flags any clock gate not made test-controllable, because an ungated-in-test flop silently drops out of the chain and its faults go untested.

13. How do you handle multiple clock domains in scan?
You generally build separate chains per clock domain (or carefully ordered mixed chains) and during shift use a single slow scan clock, but the real issues are at the domain boundaries. Between two domains in the same chain you insert a lock-up latch to avoid shift-path hold races, and for capture you either pulse domains one at a time (safe, more patterns) or handle cross-domain paths as false/multicycle so ATPG doesn't generate unrealistic transitions. Naming the lock-up latch and the one-domain-at-a-time capture strategy shows you've actually built chains.

14. What exactly does a lock-up latch do?
It's a level-sensitive latch inserted between two flops in a chain that are clocked by skewed or different clocks, retiming the scan data by half a cycle so the receiving flop samples stable data during shift. Without it, clock skew on the shift path causes the downstream flop to capture the same edge's new value — a shift-time hold failure that corrupts the whole downstream chain and looks like a mysterious miscompare. It only matters during shift; in capture the functional timing rules.

15. How do you deal with non-scan flops, latches, and asynchronous set/reset?
Any flop not in the chain is an uncontrollable/unobservable node whose faults you lose and whose output can inject an X. You either make it scannable, or bound it: tie async set/reset off during scan (control them so they don't fire mid-pattern), make latches transparent in test, and treat black-box/analog outputs as X-sources to be masked or bounded with test points. The DFT DRC exists to find every such flop; the interview answer is "identify each X-source and either scan it, control it, or bound it."

16. What are test points and when do you insert them?
Test points are added control or observe nodes that raise testability where ATPG struggles: a control point forces a hard-to-control node, an observe point taps a hard-to-observe node into a scan cell. Modern flows insert them automatically to hit a coverage target with fewer patterns, or to break up deep reconvergent logic. The trade-off is area and a small timing/functional intrusion, so you cap them and place them where the coverage-per-point payoff is highest — often around embedded memories, wide muxes, and reconvergent cones.

ATPG and compression (17-24)

17. LOC vs LOS at-speed — explain both and their trade-offs.
Launch-on-capture (LOC) launches the transition from the last functional capture edge, then captures at speed — scan-enable can switch slowly because it's low during both at-speed edges, so it's easy on SE timing but gives lower coverage (the launch values are constrained by the circuit's own logic). Launch-on-shift (LOS) launches from the final shift edge, so scan-enable must switch at speed between launch and capture — harder timing on the SE tree but higher coverage and easier pattern generation. Most flows use LOC by default and reserve LOS (with a pipelined/at-speed SE) when they need the extra coverage. Knowing why LOS stresses SE is the discriminating detail.

18. What is X-bounding / X-masking and why do Xs matter so much?
An X (unknown) at a scan-cell input corrupts the captured response, and under compression a single X can mask an entire compactor output, blinding many chains. X-sources are uninitialized RAM outputs, non-scan flops, black boxes, bus contention, and clock-domain crossings. You X-bound them — force known values (initialize RAMs, hold controls), gate the X at source, or use X-masking logic in the compactor to block the offending cycle. On compressed designs, X-management is often the difference between hitting coverage and not; low-X design is a first-class DFT goal.

19. What are N-detect and cell-aware ATPG, and who needs them?
N-detect requires each fault be detected N times (through different paths), catching defects that a single detection misses — it raises real defect coverage (DPPM) at the cost of more patterns. Cell-aware ATPG models defects inside the standard cell (transistor shorts/opens from the library's analog characterization), not just at pins, catching intra-cell defects invisible to gate-level fault models. Both are quality plays driven by automotive and high-reliability parts — if you interview at TI or an automotive-heavy group, expect this, framed as "how do you get to single-digit DPPM."

20. Why does reconvergent fanout lower coverage and slow ATPG?
When a signal fans out and the branches reconverge at a gate, the values on the branches are correlated, so ATPG can't treat them independently — it may have to search hard to find an assignment that both sensitizes the fault and propagates it without the paths cancelling (self-masking). Some faults become redundant/untestable purely from reconvergence. It's the structural reason a design with lots of shared control logic needs test points or more ATPG effort, and it's a favorite "why is this fault untestable" probe.

21. Draw an EDT-style compression architecture and name each block.
From scan-in pins: a decompressor (a ring generator / LFSR + phase shifter) expands a few input channels into many short internal scan chains; the chains capture the response; a compactor (XOR spatial compactor, sometimes with a MISR for time compaction) folds the many chains back to a few scan-out pins, with X-masking logic to block unknown-carrying chains. The controller sequences it. The two things interviewers listen for: the decompressor limits how many care-bits a pattern can specify (over-specified patterns fail to compress), and the shared compactor is exactly why diagnosis resolution drops.

22. Your pattern set is too big for the tester budget. What do you do?
Attack volume and time separately. Volume: raise compression ratio, use low-care-bit-friendly ATPG, merge/compact patterns, drop redundant patterns via reverse-order fault simulation, and reuse patterns across fault models (dynamic compaction). Time: shorten chains (more chains/higher compression), reduce shift cycles, and move suitable tests to on-chip BIST (LBIST/MBIST) so the tester does less. You also negotiate coverage-vs-cost: the last 0.2% of coverage can cost a huge pattern tail — quantify it and decide with the test-cost owner.

23. Is IDDQ / bridging test still relevant at advanced nodes?
Classic threshold IDDQ has faded because leakage at small nodes swamps the defect signal, but the intent survives as delta-IDDQ and current-signature methods on selected parts, and bridging/cell-aware patterns cover the shorts IDDQ used to catch. So the honest 2026 answer is: pure static IDDQ is mostly legacy, but current-based screening persists in reliability/automotive flows, and bridge defects are now covered structurally. Saying "IDDQ is dead" flat-out is a small red flag; the nuance is the point.

24. How do you sign off ATPG coverage — what's the target and what about untestables?
You target a test-coverage number per fault model (commonly ~99% stuck-at, high-90s transition, with cell-aware/N-detect on quality parts), and every undetected fault must be classified: untestable (tied logic, redundant), untestable-by-design (unused ports), or ATPG-abandoned (needs effort/test points). You don't ship a bucket of unexplained undetected faults — you justify each class and add test points or patterns where the miss is real. Coverage sign-off is a defensible classification of every fault, not a single percentage.

Memory test, JTAG and IJTAG (25-30)

25. Walk through MBIST insertion for a 2MB SRAM shared across instances.
ATPG can't efficiently test dense RAM arrays, so you wrap each memory with a BIST controller that runs march algorithms (e.g. March C-, and at-speed patterns) generating addresses/data and comparing reads on-chip, reporting pass/fail. For many memories you share one controller across instances via a serial/parallel interface to save area, sequencing them and time-multiplexing, trading test time for area. You pick algorithms by defect target (March for stuck-at/coupling, checkerboard/retention for data retention) and add at-speed for access-time faults. Sharing strategy and algorithm choice are what distinguish a real answer.

26. What is memory repair and how do fuses fit in?
Big memories ship with spare rows/columns; BIST finds failing addresses and a BISR (built-in self-repair) computes a repair signature mapping spares over the failures, which is then made permanent by blowing fuses. Hard fuses (laser/eFuse) are one-time and survive power cycles — the production repair; soft fuses (register-loaded) apply repair at each boot, useful for bring-up and field-reconfigurable repair. Repair is why a memory-dominated die still yields: without it, one bad cell kills the part. Interviewers probe the fuse distinction and where repair happens (test time vs boot).

27. Explain the JTAG TAP state machine and boundary scan.
IEEE 1149.1 defines a 16-state TAP FSM driven by TMS/TCK, with two paths — DR (data register) and IR (instruction register) — each with capture/shift/update phases, navigated purely by TMS values. Boundary scan puts a cell at each I/O so you can, via JTAG, shift values out to drive pins and capture pin states without physical probes — the standard way to test board-level interconnect (opens/shorts between chips) and to access internal test features. You should be able to trace TMS to get from Test-Logic-Reset to Shift-DR; that's a common whiteboard ask.

28. What is BSDL and who consumes it?
BSDL (Boundary Scan Description Language, a VHDL subset) describes a chip's JTAG capability — pin map, boundary register order and cell types, TAP instructions, IDCODE. It's consumed by board-test tooling (ATE and in-circuit testers) and by JTAG debuggers to know how to drive the chip's boundary scan for interconnect test. It's the contract that lets a board house test your device without your netlist. Mentioning that the board/ATE side consumes it, not the chip, shows system awareness.

29. What are IJTAG (1687) and IEEE 1500, and what problem do they solve?
Modern SoCs have hundreds of embedded instruments — MBIST controllers, PLL/PVT sensors, repair registers, LBIST. IEEE 1500 defines a standard core wrapper (a scan-based test collar) so a core can be tested in isolation and integrated hierarchically. IJTAG (1687) defines a reconfigurable network (SIB/segment-insertion-bit based) plus description languages (ICL/PDL) to reach any instrument through JTAG without hand-wiring each one. Together they make hierarchical, plug-and-play test access scalable. The keyword interviewers want is retargeting: PDL written at the instrument is auto-retargeted to chip-level vectors.

30. Why do you need an on-chip clock controller (OCC) for at-speed?
At-speed capture needs two (or more) precisely-spaced functional-frequency edges that the low-speed tester can't deliver, so an OCC sits on the PLL output and, in test, gates out a controlled burst of fast clock pulses for the capture window while the tester supplies only the slow shift clock and a trigger. It aligns launch/capture edges per clock domain for LOC/LOS. Without an OCC you can't apply transition patterns at real frequency. Being able to say "the tester shifts slow, the OCC pulses fast for capture" is the crisp version.

SoC-scale, low-power, automotive and secure DFT (31-35)

31. How do you do DFT on a chip too big to flatten — hierarchical DFT?
You test bottom-up: wrap each core/tile (IEEE 1500 style) with its own scan and compression, generate and verify patterns at the core level once, then retarget those patterns to the top level through the wrapper without re-running ATPG on the full flat netlist — which wouldn't fit in tool memory or runtime anyway. Identical tiles reuse one pattern set. A streaming scan network (packetized scan over a fixed bus, e.g. Tessent SSN) decouples core chain counts from top-level pins so you can test many cores concurrently over a few wires. This is the defining skill for GPU/networking-scale parts; naming core-level pattern retargeting and concurrent test is what senior interviewers look for.

32. What does power-aware DFT have to worry about?
Scan crosses power domains, so UPF intent must hold in test: isolation cells clamp signals from a powered-down domain, level shifters cross voltage boundaries, and retention flops must retain across a power cycle — and your scan patterns have to exercise and respect all of it. You test domains that are on, keep the chain intact across off domains (or partition chains per domain), and add patterns that verify isolation/retention control itself. Plus shift power (Q11) is a power-integrity problem. The trap: a chain that shifts through a domain the pattern powered down captures Xs — DFT and low-power intent have to be co-designed.

33. What's different about DFT for automotive (ISO 26262)?
Automotive demands single-digit DPPM and in-field safety, so DFT extends past manufacturing test into the mission profile: in-system test — LBIST and software/logic self-test (STL) — runs at key-on and periodically during operation to catch latent faults, and results feed the safety mechanism/FMEDA to hit the required diagnostic coverage (single-point fault metric). Manufacturing test adds cell-aware and N-detect for the DPPM target. So you're designing test that runs not just at the ATE but in the car for 15 years. If you interview at TI, NXP or an automotive group, this is central, not trivia.

34. What is secure DFT and why is scan a security risk?
Scan gives full controllability/observability of internal state — wonderful for test, dangerous if an attacker uses it to read keys or bypass security by scanning out a secure block's registers. Secure DFT locks the test infrastructure: authenticate before enabling scan/JTAG (challenge-response or lifecycle-state gating), reset/clear secure registers on entering test mode, obfuscate or blow the scan path to crypto blocks after provisioning, and gate the TAP by device lifecycle. The tension to articulate: you must preserve enough test/diagnosis access for failure analysis while denying it to attackers.

35. What makes RTL "test-ready," and why run DFT DRC early?
Test-ready RTL avoids the constructs that break scan: no gated/derived/internally-generated clocks without OCC-friendly structure, no combinational feedback, controllable async resets, no latches (or clean transparent ones), and clean clock-domain structure. Running DFT rule checks (scan DRC) at RTL or early netlist catches uncontrollable clocks/resets and X-sources when they're cheap to fix — discovering them after place-and-route is a schedule hit. The message: DFT starts at RTL sign-off, not at the gate netlist, and a DFT engineer who reviews RTL early saves the project weeks.

Silicon bring-up and diagnosis (36-38)

36. First silicon arrives. Walk me through bring-up.
Start at the most basic and work up: power/cl/reset and continuity, then JTAG IDCODE and TAP integrity (if JTAG is dead, nothing else is reachable), then scan-chain integrity (flush/chain test — shift a pattern through and confirm length and connectivity before trusting any ATPG result), then MBIST on memories, then the ATPG stuck-at set at slow speed, then at-speed. You characterize shmoo (voltage/frequency) to see margins. The discipline interviewers want: verify the test access path itself works before you trust a single coverage number, and go simple-to-complex so a failure localizes.

37. Yield is low. How do you use scan diagnosis to find the cause?
Collect failing datalogs from many dies and run scan diagnosis (the ATPG tool back-maps failing patterns/cells to candidate defect locations/nets). One die tells you little; volume diagnosis across hundreds of failures reveals systematic signatures — a repeatedly implicated layer, via, cell type, or region — which points to a process or design-rule issue versus random particle defects. You correlate with layout and hand it to the fab/failure-analysis team with statistical evidence, not one anecdote. Compression complicates this (shared outputs blur the map), which is a trade-off you flag. The signal: you turn test failures into a statistical root-cause argument.

38. Tell me about a real silicon problem you debugged.
This is the highest-signal question in the loop. A strong answer is specific: the symptom (e.g. scan chains failing on ~half the parts only above a voltage, or an at-speed pattern failing at one corner), how you localized it (chain test isolated it to one domain; diagnosis implicated a specific lock-up latch / a hold violation on the shift path / a missed OCC edge), the root cause (a clock-skew hold on a cross-domain shift path that only opened up at high voltage), and the fix (added a lock-up latch / ECO on the shift clock / pattern regen) plus what you changed in the flow so it never recurs. Three minutes, real waveform or datalog, real number. Most candidates walk in without one — prepare yours before anything else.

Tools they'll ask about

• Siemens Tessent — the DFT market leader; expect fluency across Tessent Scan, MBIST/LogicBIST, TestKompress, SSN (streaming scan) and Diagnosis. If a shop is Tessent-based, hierarchical DFT questions map straight onto it.
• Synopsys TestMAX (ATPG/DFT, formerly TetraMAX/DFTMAX) — dominant at many product companies for scan insertion, ATPG and compression.
• Cadence Modus (formerly Encounter Test) — scan, ATPG, and compression in Cadence-centric flows.
• ATE / pattern formats — Advantest and Teradyne testers; know STIL/WGL pattern formats and that patterns must be translated and validated for the tester, plus basic shmoo/datalog reading.

When to reach for BIST instead of ATPG

ATPG + tester is the workhorse for random logic, but BIST wins where you need on-chip, self-contained test: MBIST for memories (ATPG can't efficiently cover dense arrays), and LBIST for logic when you need in-field/in-system test (automotive key-on and periodic self-test) or want to reduce tester time and data volume. The trade-off: LBIST uses pseudo-random patterns, so it needs the design to be BIST-ready (no X-sources, test points to hit coverage) and typically reaches lower coverage than targeted ATPG unless supplemented. The mature answer: MBIST always for memories, LBIST for in-system safety and tester-cost reduction, ATPG for the coverage backbone — most real chips use all three.

Company-specific interview patterns (2026)

• Texas Instruments — Automotive and analog-mixed SoCs: deep on quality (cell-aware, N-detect, DPPM), MBIST/repair, and ISO 26262 in-system test. Prep: memory test, fault-quality reasoning, and a safety-mechanism answer.
• Broadcom — Large networking ASICs: hierarchical DFT, high compression ratios, core wrapping and pattern retargeting at scale, high pin-count boundary scan. Prep: hierarchical test and compression trade-offs.
• Qualcomm — Mobile SoCs: low-power/power-aware scan, OCC and at-speed, IJTAG for embedded instruments, shift-power management. Prep: LOC/LOS, power-domain-aware DFT, OCC.
• NVIDIA and AMD — Massive GPUs: streaming scan, concurrent hierarchical test, pattern-volume and test-cost optimization, at-speed at scale. Prep: SSN/hierarchy, pattern-count reduction, test economics.
• Intel — Signoff rigor: fault-model depth, at-speed/GLS discipline, coverage classification, DFx methodology. Prep: coverage-metric precision and untestable-fault handling.
• Synopsys and Cadence — Tool and methodology depth: how compression/ATPG works internally, how you'd architect a DFT flow. Less block-craft, more methodology.

The 6-week prep plan

Weeks 1-2: fault models, scan and coverage fluency

Get the fundamentals to muscle memory: draw a mux-D cell and the shift/capture cycle, explain stuck-at vs transition vs path-delay and why each exists, and be able to define test vs fault vs ATPG coverage without hesitating. If you can't explain LOC vs LOS and why LOS stresses scan-enable, you're not ready for Round 3.

Weeks 3-4: compression, memory, JTAG and hierarchy

Build the mental model of a full SoC DFT architecture end to end: EDT compression (decompressor/compactor/X-masking and what it costs), MBIST + repair + fuses, the TAP FSM and boundary scan, and IJTAG/1500 for hierarchical access with pattern retargeting. Read the tool user guide for whichever of Tessent/TestMAX/Modus the target company uses, not a blog summary.

Weeks 5-6: silicon story, specialised depth, and mocks

Add depth on power-aware, automotive (ISO 26262 in-system test) and secure DFT so you can go one level past the textbook. Do three mock interviews and record them. Then polish the single most important answer: a three-minute silicon-debug story with the symptom, how you localized it (chain test / diagnosis), the root cause, and the fix. Practicing against an adaptive question set, like our interview prep tool generates, is a cheap way to find where your answers wobble under follow-ups.

Salary expectations for 3-5 year DFT engineers (2026)

• Service companies (Wipro VLSI, HCL, LTTS, Tata Elxsi): 8-14 LPA
• Mid-tier product (Synopsys, Cadence, Marvell, NXP): 16-26 LPA
• Top-tier product (Qualcomm, Intel, Broadcom, Texas Instruments): 24-40 LPA
• Hyper-growth (NVIDIA, AMD, Apple India): 30-52 LPA

DFT sits slightly below RTL design at the fresher level but catches up fast, because supply is thin — the discipline is rarely taught well at undergrad, and silicon experience doesn't transfer easily, so companies retain DFT engineers aggressively. A DFT lead with three successful tape-outs is genuinely hard to replace. If you're stuck in the service-company band with real scan-insertion, ATPG-closure and bring-up experience, focused interview prep unlocks a 2x jump. For the full cross-specialisation breakdown, see our VLSI engineer salary guide 2026.

The mistake I see most often

Candidates describe the flow they ran, not the test quality they reasoned about. "I ran TestMAX and got 99% coverage" is the tool talking. "Our transition coverage was stuck 18 points below stuck-at; I traced it to a clock domain the OCC wasn't pulsing at speed, fixed the OCC control so both capture edges landed, and recovered coverage to 96% — and we later caught a slow-to-rise defect on the tester that stuck-at would have shipped" — that's a DFT engineer talking. The silicon story is the highest-signal answer in the entire loop, and most candidates walk in without one.

Start drafting your specific silicon story this week. Browse current DFT openings to see what companies are hiring for, and match your resume language to the actual job descriptions.

Related reading

• DFT Engineer Career & Interview Guide: the specialisation no one explains in college
• Physical Design interview questions (India 2026)
• Low Power Design interview questions (UPF, India 2026)
• VLSI engineer salary in India 2026: the complete guide