Top DFT Interview Questions

Chapter 15 · Section 15.1 · Interview & Signoff Review Preparation — chapter opener

Project thread — the mini-SoC's concepts (Ch1–14), now recast as interview answers. 15.2 adds scenarios; 15.3 debug drills; 15.4 the signoff checklist; 15.5 self-assessment.

1. Why Should I Learn This?

Knowing DFT and explaining it well are different skills — interviews test the second. A curated question bank + an answer pattern turns your knowledge into senior-sounding answers.

• Interviewers probe understanding — the why, the boundary, the tradeoff — not bare definitions.
• A strong answer = define → why it exists → tradeoff/boundary → example (the same shape every time).
• The question bank spans the whole track — fundamentals, fault models, scan, DRC, ATPG, coverage, compression, MBIST, timing, debug.
• Know the traps — 100% isn't the goal, coverage bounds risk, memories need their own test, functional-clean ≠ test-clean, flush first.

2. Real Silicon Story — two candidates, the same knowledge

Two candidates were asked the same question: 'What is scan?' The first answered: 'Scan adds a mux to flip-flops so you can shift values in and out.' Correct — but junior. The interviewer probed: 'Why?' — and the candidate hesitated.

The second gave the same core fact in the senior shape: 'Scan makes flip-flops controllable and observable — a mux-D cell lets you shift a known value in (control) and shift the captured value out (observe), because a plain flop buried in logic is unreachable from the pins. Manufacturing test needs both to detect a stuck-at fault. It costs a scan-mux setup penalty and a shift path, and it's the foundation everything — chains, ATPG, compression — builds on.' Same knowledge, but it included the why (control+observe), the boundary (defects, not bugs), the tradeoff (setup penalty), and an example — so every follow-up was already answered. The second candidate advanced. Lesson: interviews test understanding you can articulate. The fix for the first candidate wasn't more knowledge — it was answering in the define-why-tradeoff-example shape by default, so the same knowledge reads as senior.

3. Factory Perspective — the interview through each lens

• What the interviewer sees: whether you understand the why/boundary/tradeoff — do you know coverage isn't proof, memories need their own test, functional-clean isn't test-clean?
• What a senior DFT engineer sees: the vocabulary of the discipline — you should speak it the way the team does (the whole track's language).
• What the hiring manager sees: whether you can communicate to RTL/DV, STA, and test — DFT is a cross-team role, so articulation matters as much as knowledge.
• What you (the candidate) should see: that answering in a consistent shape (define → why → tradeoff → example) makes your real understanding land — don't let a weak format hide strong knowledge.

4. Concept — the answer pattern and the question bank

The answer pattern (use it every time):

1. DEFINE — one crisp sentence (what it is).
2. WHY it exists — the problem it solves (the why).
3. TRADEOFF / BOUNDARY — what it costs / what it doesn't do.
4. EXAMPLE — a concrete instance (an artifact, a number, a case).

• Weak answer = step 1 only. Senior answer = all four — so the interviewer's 'why?' / 'what does it cost?' probes are already answered.

The question bank (by topic — the whole track):

• Fundamentals: verification vs manufacturing test (bugs vs defects); controllability + observability; why DFT.
• Fault models: stuck-at vs transition vs bridging; why a model (not real defects); untestable/redundant.
• Scan: the mux-D cell; shift vs capture; why scan (control+observe); chain balancing.
• DRC: what scan DRC checks; uncontrolled clocks/resets; lock-up latches; why before ATPG.
• ATPG: how it works (justify/propagate); combinational vs sequential; DT/AU/redundant.
• Coverage: test vs fault coverage; why not 100%; coverage ≠ quality proof.
• Compression: why (test data/time); decompressor/compactor; X-masking; compression vs diagnosability.
• MBIST: why memories need their own test; March; BISR.
• LBIST / JTAG: PRPG/MISR; TAP states; boundary scan.
• Timing: shift=hold, capture=setup; scan-enable timing; at-speed LOC/LOS; OCC; multi-mode / test-clean.
• Debug: a failure is data (the fork); structure-before-function; diagnosis; silicon bring-up.

The traps (specific correct answers):

• 'Is 100% coverage the goal?' → No — test vs fault coverage; redundant/untestable faults exist; don't chase blindly.
• 'Does coverage prove no defects?' → No — it bounds escape risk, never proves zero.
• 'Why not just scan the memory?' → Memories are dense arrays with own fault models — use MBIST.
• 'Why does a functional-clean chip fail scan?' → Multi-mode timing — functional-clean ≠ test-clean (shift/capture modes).
• 'The chain fails — what first?' → Flush it — structure before function; a dead chain fails every pattern.

5. Mental Model — answering like a tour guide, not a dictionary

A strong interview answer is a tour guide, not a dictionary entry.

• A dictionary gives the bare definition — 'scan: a mux added to a flip-flop.' Accurate, lifeless, and it stops the moment someone asks 'why does that matter?'
• A tour guide gives the definition and why you're standing here (the problem it solves), what it cost to build (the tradeoff), and points at a concrete thing (the example) — so the visitor understands, not just hears a word.
• When a visitor asks a follow-up ('but why?'), the dictionary is stuck — it only had the one line. The tour guide has already told the story, so the follow-up is already answered — and the guide sounds like they actually know the place.
• The facts are identical; the framing is what separates 'read a definition' from 'understands the discipline.' Interviews hire tour guides.

Answer like a tour guide (define → why you're here → what it cost → point at an example), not a dictionary (definition only) — the follow-up is already answered, and the same facts read as senior.

6. Working Example — the annotated Q-bank in the answer shape

A few top questions answered in the define → why → tradeoff → example shape:

# Top DFT questions in the DEFINE -> WHY -> TRADEOFF -> EXAMPLE shape - REPRESENTATIVE:
 
Q: "What is scan, and why do we use it?"
  DEFINE : a mux-D flip-flop - a mux on D selects functional data or scan-in, Q threads to the next cell.
  WHY    : a plain flop buried in logic isn't controllable/observable; test needs to set a value in and read it out.
  TRADEOFF: costs a scan-mux setup penalty on the functional path + a shift path (hold).
  EXAMPLE: shift-0/observe detects stuck-at-1; shift-1/observe detects stuck-at-0 (2 patterns test one bit).
 
Q: "Is 100% fault coverage the goal?"  (TRAP)
  DEFINE : no - fault coverage is over ALL faults, including untestable/redundant ones.
  WHY    : redundant logic (e.g. an FSM default/illegal-state branch) can't be sensitized -> AU.
  TRADEOFF: chasing 100% blindly wastes effort; test coverage (of testable faults) can be near-100% while fault coverage trails.
  EXAMPLE: report BOTH; classify redundant faults so the number reflects reality.
 
Q: "Why can't we just scan a memory?"  (TRAP)
  DEFINE : a memory is a dense array of bit cells, not flops - you can't scan-stitch bit cells.
  WHY    : it has memory-specific fault models (coupling, decoder, retention) scan/stuck-at ATPG doesn't target.
  TRADEOFF: needs a dedicated on-chip at-speed test (MBIST/March) + repair (BISR) - separate from logic scan.
  EXAMPLE: MBIST GO/NOGO + a failure bitmap; a clustered column = a repairable structural defect.
 
Q: "A functional-clean chip fails scan in silicon - why?"  (TRAP)
  DEFINE : because functional-clean is NOT test-clean - shift and capture are separate timing modes.
  WHY    : STA only checks the modes you constrain; an unconstrained shift mode hides shift-hold violations.
  TRADEOFF: you must run multi-mode STA (functional + shift + capture/at-speed) = test-clean.
  EXAMPLE: a chain miscompare from an un-constrained shift-hold; add the shift-run SDC + lock-ups.
 
Q: "The scan chain fails - what do you check first?"  (TRAP)
  DEFINE : FLUSH it - shift a known pattern in and observe it out (structure before function).
  WHY    : a broken chain makes EVERY pattern miscompare; debugging logic on a dead chain wastes days.
  TRADEOFF: none - flush is cheap; a constant output = stuck, downstream-dead = open, fails-fast = timing.
  EXAMPLE: flush shows a constant -> stuck chain; count to the stuck cell; check clocks/resets in shift.

A weak answer is a definition; a strong answer adds why, boundary, tradeoff, and an example:

7. Industry Flow — prep the bank, drill the pattern, know the traps

Interview prep flows from the question bank through the answer pattern and the trap list to fluent, senior answers:

8. Debugging Session — the candidate who knew everything but sounded junior

9. Common Mistakes

• Answering with definitions only. Add the why, boundary, tradeoff, example — the interviewer is probing for exactly those.
• Chasing the '100% coverage' trap. No — test vs fault coverage, redundant faults; coverage is risk, not proof.
• Saying coverage proves quality. It bounds escape risk — it never proves zero defects.
• Proposing to scan a memory. Memories are arrays with own fault models — use MBIST.
• Missing 'functional-clean ≠ test-clean.' Shift/capture are separate timing modes — multi-mode STA (12.5).

10. Industry Best Practices

• Answer in the define → why → tradeoff → example shape — every time, by default.
• Volunteer the why and the tradeoff — don't wait to be probed.
• Know the trap answers cold — 100% / coverage-proof / memory / test-clean / flush-first.
• Speak the discipline's vocabulary — the whole track's terms (fault models, DRC, ATPG, MBIST, multi-mode timing).
• Practice out loud — until the four-part shape is automatic; it's a skill, not just knowledge.

11. Senior Engineer Thinking

• Beginner: "I know all the DFT concepts — I'll just define each one when asked."
• Senior: "Knowing isn't enough — I have to articulate. So I answer in the define → why → tradeoff → example shape: the interviewer's 'why?' and 'what does it cost?' are already in my answer. I volunteer the boundary — coverage bounds risk, it doesn't prove quality; memories need their own test; functional-clean isn't test-clean. The traps are layups because I know their specific answers. Same knowledge, senior framing — that's what lands the answer."

The senior answers in a consistent four-part shape, volunteers the why/tradeoff, and treats the traps as layups.

12. Silicon Impact

The interview-questions lesson reframes the whole track from knowledge into communicable understanding — because a DFT role is cross-functional, and the interview measures whether you can explain DFT to RTL/DV, STA, and test, not just recall it. The governing insight is that interviewers probe understanding, not memorization: they push past the definition with 'why does it exist?' and 'what does it cost?', because that's where real understanding — the why, the boundaries, the tradeoffs — becomes visible. The remedy is a consistent answer shape: DEFINE → WHY it exists → TRADEOFF/BOUNDARY → EXAMPLE, which volunteers exactly what the interviewer is looking for, so every follow-up is already answered and the same knowledge that sounds junior as a bare definition reads as senior. The question bank is the whole track, distilled — fundamentals (bugs vs defects, control+observe), fault models (why a model), scan (mux-D, shift/capture), DRC (structure gate), ATPG (justify/propagate, DT/AU), coverage (test vs fault, not proof), compression (data/time vs diagnosability), MBIST (why not scan a memory), LBIST/JTAG, timing (shift=hold/capture=setup, at-speed, multi-mode), and debug (a failure is data, structure-first) — and the trap questions encode the track's core boundaries with specific correct answers: 100% isn't the goal (test vs fault, redundant), coverage bounds escape risk (never proves zero), memories need their own test (arrays, own fault models), functional-clean ≠ test-clean (multi-mode timing), and flush the chain first (structure before function). For the candidate, this lesson is a performance tool — the rubric that makes strong knowledge land; for the interviewer, it's a map of what a good answer contains; and for the team, it reflects that DFT is a communication-heavy, cross-team discipline where articulating tradeoffs is a daily job (a signoff review is exactly this, 15.4). This opens the final chapter: the next lessons take the same understanding into scenarios (15.2, open-ended "what would you do"), debug drills (15.3, applied Ch13), the signoff-review checklist (15.4, the team-facing consolidation of 13.6/14.6), and a self-assessment (15.5, are you ready?). The throughline: you already learned DFT across fourteen chapters — this chapter makes sure you can say it, in the shape that turns understanding into a hire.

13. Engineering Checklist

• Built a question bank by topic covering the whole track (fundamentals → debug).
• Drilled the define → why → tradeoff → example shape until automatic.
• Rehearsed the traps with their specific answers (100% / coverage-proof / memory / test-clean / flush).
• Practiced out loud — volunteering the why and the tradeoff, not waiting to be probed.
• Can speak the discipline's vocabulary to RTL/DV, STA, and test (cross-team articulation).

14. Try Yourself

1. Answer 'What is scan and why do we use it?' in the define → why → tradeoff → example shape.
2. Answer the trap 'Is 100% fault coverage the goal?' — with the specific correct answer (test vs fault, redundant).
3. Answer 'Why can't we just scan a memory?' — arrays, own fault models, MBIST.
4. Answer 'A functional-clean chip fails scan — why?' — multi-mode timing / functional-clean ≠ test-clean.
5. Take five more topics and answer each in the four-part shape, volunteering why and tradeoff.

The Q-bank and answer pattern are tool-neutral; the content is the whole track. No paid tool required to prepare.

15. Interview Perspective

• Weak: "I'll memorize definitions of all the DFT terms."
• Good: "I'll learn the concepts and be ready to explain why each exists."
• Senior: "Interviews test understanding I can articulate, so I answer in the define → why → tradeoff → example shape by default — the interviewer's 'why?' and 'what does it cost?' are already in my answer. I volunteer the boundaries: coverage bounds escape risk, it doesn't prove quality; memories need their own test (arrays, own fault models); functional-clean isn't test-clean (multi-mode timing); flush the chain first (structure before function). The trap questions are layups because I know their specific answers. It's the same knowledge as everyone else — the framing is what makes it read as senior, because a DFT role is cross-team, and explaining tradeoffs is the daily job."

16. Interview / Review Questions

17. Key Takeaways

• Interviews test understanding you can articulate, not memorization — interviewers probe past the definition with 'why?' and 'what does it cost?', because that's where real understanding shows.
• Answer in the shape: DEFINE → WHY it exists → TRADEOFF/BOUNDARY → EXAMPLE — it volunteers the why and tradeoff, so every follow-up is already answered; the same knowledge reads as senior.
• The question bank spans the whole track — fundamentals, fault models, scan, DRC, ATPG, coverage, compression, MBIST, LBIST/JTAG, timing, debug — speak the discipline's vocabulary.
• Know the traps with specific answers: 100% isn't the goal (test vs fault, redundant); coverage bounds escape risk (not proof); memories need their own test (MBIST); functional-clean ≠ test-clean (multi-mode timing); flush the chain first (structure-first).
• Sounding junior is almost never a knowledge problem — it's an answer-shape problem — drill the four-part shape out loud until it's automatic. Next: 15.2 — scenario-based DFT questions.

18. Quick Revision

Top DFT interview questions (Ch15 opener). Interviews test understanding you can ARTICULATE, not memorization → they probe past the definition with 'why?' / 'what does it cost?'. ANSWER SHAPE: DEFINE → WHY it exists → TRADEOFF/BOUNDARY → EXAMPLE (volunteers what they probe for → follow-ups already answered → same knowledge reads SENIOR). Q-BANK by topic (whole track): fundamentals (bugs vs defects, control+observe) · fault models (why a model) · scan (mux-D, shift/capture) · DRC (structure gate) · ATPG (justify/propagate, DT/AU) · coverage (test vs fault, NOT proof) · compression (data/time vs diagnosability) · MBIST (why not scan a memory) · LBIST/JTAG · timing (shift=hold/capture=setup, at-speed, multi-mode) · debug (failure is data, structure-first). TRAPS (specific answers): 100% isn't the goal · coverage bounds risk (not proof) · memories need own test · functional-clean ≠ test-clean · flush the chain first. Sounding junior = an answer-SHAPE problem, not knowledge → drill the 4-part shape out loud. Next: 15.2 — scenario-based DFT questions.