Inspirational journeys

DFT Engineer Interview Guide — Complete Guide for VLSI Engineers | CourseTron 2026

Coursetron Admin

Thu, 03 Sep 2026

What a DFT Engineer Interview Actually Tests

Design-for-Test (DFT) interviews are unusual among VLSI interviews because they sit at the junction of RTL design, timing, and manufacturing. Interviewers rarely want textbook definitions alone; they want proof that you understand why a test structure exists, what it costs in area and timing, and what breaks when it is inserted carelessly. A typical loop covers four pillars: scan architecture, ATPG and fault models, memory BIST, and boundary scan. Senior rounds add compression, hierarchical DFT, and silicon debug scenarios. This guide walks through each pillar with real example questions, the answers interviewers expect, and a preparation checklist you can work through in the weeks before your interview.

The Four Pillars Interviewers Probe

Scan design

Expect questions on how a mux-D scan flop works, what happens in shift versus capture mode, and how scan chains are balanced and stitched. Be ready to explain scan DRC problems: clock-gating cells that block the scan clock, asynchronous set/reset pins that must be held inactive during shift, and lockup latches between chains driven by different clock domains or clock edges.

ATPG and fault models

Know the stuck-at model, the transition-delay model, and path-delay testing, plus newer cell-aware faults that target defects inside standard cells. You should be able to explain how launch-on-capture and launch-on-shift differ for at-speed testing, and why on-chip clock controllers (OCCs) are needed when the tester cannot supply functional-speed clock pulses.

Memory BIST

Embedded memories cannot be scanned, so interviewers ask how MBIST controllers apply March algorithms (for example March C-) to detect stuck-at, coupling, and address-decoder faults, and how repair works with redundant rows and columns through BIRA/BISR logic.

Boundary scan and standards

IEEE 1149.1 (JTAG) questions cover the TAP controller state machine, the instruction register versus data registers, and how EXTEST verifies board-level interconnect. For SoC roles, review IEEE 1500 core wrappers and IEEE 1687 (IJTAG) for accessing embedded instruments.

Sample Questions with Strong Answers

Q1. Why do we need transition-delay ATPG if stuck-at coverage is already 99%?

Answer: Stuck-at patterns are applied at slow speed and only detect defects that behave like a permanent 0 or 1. Resistive opens and weak drivers may pass a slow test yet fail at functional frequency. Transition patterns launch a value change and capture it one functional cycle later, so a slow node fails the test. High stuck-at coverage says nothing about timing-related defects, which dominate at advanced nodes.

Q2. Your scan chain simulation fails in shift mode. How do you debug it?

Answer: First check the flush test: shift a known pattern through with capture disabled. If it fails, suspect scan-enable timing, an uncontrolled reset toggling mid-shift, a clock-gating cell not forced transparent in shift, or a missing lockup latch at a negedge-to-posedge boundary. Trace where the pattern first corrupts — the failing bit position maps directly to a chain location, which localises the offending flop or stitch.

Q3. What does test compression give you, and what is its main hazard?

Answer: Compression (for example EDT-style logic) inserts a decompressor before the chains and a compactor after them, so the tester drives a few pins while the design shifts hundreds of short internal chains in parallel — cutting test time and data volume by 30–100x. The hazard is X-states: unknown values from uninitialised memories or multicycle paths can corrupt the compacted signature, so X-sources must be masked or bounded, which can cost coverage.

Q4. Fault coverage is stuck at 92%. What are your first steps?

Answer: Run the coverage report by fault class. AU (ATPG-untestable) faults often trace to constrained pins or blocked clock paths; UO (unobserved) faults point to logic whose output never reaches a scan flop. Fixes include adding test points (control points for controllability, observe flops for observability), reviewing constant-tied inputs, and checking that all clock domains are actually pulsing during capture.

Q5. Why can't we just test memories with scan patterns?

Answer: A memory array is dense analog-like structure with faults — coupling between adjacent cells, decoder faults, retention failures — that a combinational fault model does not represent. March algorithms walk deterministic read/write sequences across every address to sensitise these defect types, and BIST runs them at speed with a compact on-chip controller instead of shifting millions of cycles through scan.

Preparation Checklist

• Re-derive the mux-D scan flop and TAP controller state machine from memory — both are frequent whiteboard asks.
• Practise reading an ATPG coverage report and explaining each fault class (DT, PT, AU, UD, UO).
• Be fluent in one commercial flow end to end — Tessent, TestMAX, or Modus — from scan insertion through pattern validation.
• Prepare one debug story of your own: a broken chain, a simulation-versus-silicon mismatch, or a coverage recovery, told with specifics.
• Review shift and capture timing closure: scan-enable as a false path or multicycle path, and OCC clock muxing.

If you need structured practice on the fundamentals behind these topics — digital design, STA, and verification basics that DFT builds on — you can browse all courses on CourseTron, which offers online electronics classes across VLSI and adjacent tracks.

Role Scope and Career Progression

Junior DFT engineers typically own scan insertion, DRC clean-up, and ATPG runs for a block. Mid-level engineers architect compression ratios, integrate MBIST and repair, and support silicon bring-up on the tester. Senior and staff engineers define the SoC-level test architecture — hierarchical DFT with wrapped cores, test scheduling, and test-cost trade-offs — and interface with product and yield engineering. Compensation is broadly comparable to design and verification roles at the same level, though actual figures vary widely by company, geography, and node experience, so treat any published number as an indicative range rather than a promise.

FAQ

Is DFT a good specialisation compared to design or verification?

DFT teams are smaller than verification teams, so experienced engineers are consistently in demand, and the work spans RTL, timing, and silicon — good breadth for later architecture roles.

How much coding is expected in a DFT interview?

Usually moderate: Tcl for tool flows, some Python or Perl for pattern and report processing, and enough Verilog to read and patch test logic. Deep algorithmic coding rounds are uncommon but basic scripting questions are routine.

Can a fresher get into DFT directly?

Yes, though openings are fewer than in verification. Strong digital fundamentals, a clear grasp of scan and ATPG concepts, and a small demonstrable project (such as inserting scan into an open-source core) make a fresher profile stand out.