Senior interviews test whether you can make decisions, not just define terms, and they probe with follow-ups until you reach the edge of what you know. For each question, answer out loud, then answer the follow-up before opening it. If the follow-up stops you, the linked lesson is where to go.
Strong answer: Turn what exists into numbered rules, list every question as a specification issue with an owner, write checks only for decided rules, and track open questions as risks in the plan.
Likely follow-up: What do you do if the designer and you read a rule differently?
Strong answer: Deep enough to predict what the checks compare: transaction level for data and order, cycle level only where timing is specified; deeper models cost more and copy more implementation detail.
Likely follow-up: When would you need a cycle-accurate model?
Strong answer: Implementation choices the specification leaves open, such as exact latency when only a bound is specified, or arbitration order when any fair order is legal; checking them makes tests brittle.
Likely follow-up: How do you check a latency bound without fixing the latency?
Strong answer: Each requirement maps to features, each feature to checks, stimulus and coverage, and results update the status automatically, so sign-off reads evidence, not claims.
Likely follow-up: What does an auditor look for?
Strong answer: Weight distributions towards corners (maximum lengths, full buffers, simultaneous events) while keeping enough uniform traffic to find the unexpected; check the distribution with coverage.
Likely follow-up: What happens if you over-bias?
Strong answer: Find why the remaining bins are rare, then change the bias, write a scenario or a directed test for them, or prove them unreachable; more seeds alone rarely closes it.
Likely follow-up: When do you stop adding seeds?
Strong answer: Sequences built from transactions and scenarios built from sequences, so tests describe intent (a hot spot, a burst of errors) instead of individual signals.
Likely follow-up: How does that help reuse?
Strong answer: A fixed set for reproducibility plus fresh random seeds each night for exploration; record every failing seed and add it to the fixed set once fixed.
Likely follow-up: How do you reproduce a failure from last night?
Strong answer: The trigger may be a precise sequence or a register setting that random traffic reaches with tiny probability, such as clearing every counter and re-reading all of them.
Likely follow-up: How would coverage show you that?
Strong answer: At every interface and every rule: protocol assertions at ports, a scoreboard end to end, internal assertions where propagation is unlikely, and end-of-test checks for leftovers.
Likely follow-up: Why not just one end-to-end scoreboard?
Strong answer: Check order only where the specification requires it, per flow or per ID, and match out-of-order transactions by key elsewhere.
Likely follow-up: How do you handle legal drops?
Strong answer: Run it on the clean design across many seeds to rule out false failures, then against planted bugs to show it can fail; a checker never seen failing is not yet evidence.
Likely follow-up: What if it fails on the clean design?
Strong answer: State the requirement (throughput, latency bound), measure it in long runs with realistic traffic, and compare with an architecture model; treat misses as decisions, not just bugs.
Likely follow-up: Where do performance checks live in the regression?
Strong answer: An implication whose condition never occurs passes trivially; cover the antecedent and fail if it is never hit.
Likely follow-up: Give an example of a vacuous assertion.
Strong answer: From the plan: one item per feature and rule, with bins for boundaries and modes, crosses only where values interact, and illegal bins for impossible combinations.
Likely follow-up: How many bins is too many?
Strong answer: A steep rise then a bend; the flat part is where new bins become rare, and is the cue to change stimulus rather than run more of it.
Likely follow-up: What does a curve that never flattens tell you?
Strong answer: Prove or argue they are unreachable, exclude them with a reason and a reviewer, and revisit exclusions after design changes.
Likely follow-up: Who should approve exclusions?
Strong answer: Holes point to missing scenarios; writing tests from the holes, then rechecking, closes the loop and often finds bugs in the newly reached logic.
Likely follow-up: Can coverage-driven stimulus be automated?
Strong answer: Whether a change in the logic is detected; code that is fully covered can still be unchecked, and mutants surviving show exactly where.
Likely follow-up: How do you handle equivalent mutants?
Strong answer: Control logic with clear properties and modest state, such as arbiters, FIFOs, credit counters and FSMs, where rare corners matter and every input sequence can be explored.
Likely follow-up: When does simulation win?
Strong answer: A bounded proof finds no counterexample within N cycles; a full proof by induction covers every depth, often after adding helper invariants.
Likely follow-up: What is an induction counterexample?
Strong answer: Keep assumptions to the interface rules, cover expected behaviours to show they are still reachable, and plant a bug to show the property can fail.
Likely follow-up: How did you find an over-constraint?
Strong answer: Formal proves control properties completely; simulation covers data paths, long sequences and system behaviour; the plan states which features rest on which.
Likely follow-up: Can formal results count towards coverage?
Strong answer: Block level: everything about the block, where controllability is high. SoC level: integration, connectivity, system flows and software, not re-verifying block internals.
Likely follow-up: What bugs only appear at SoC level?
Strong answer: Keep passive monitors, assertions and scoreboards that do not drive, and turn them on at higher levels; drivers are replaced by real neighbours.
Likely follow-up: What breaks when checks move up?
Strong answer: When the workload needs billions of cycles: OS boot, software, long traffic; it is fast but has less debug visibility and is expensive to compile and run.
Likely follow-up: How do you debug on an emulator?
Strong answer: Run the real driver on a virtual platform early, then on RTL in emulation; check register contracts and flows the software actually uses.
Likely follow-up: What does a virtual platform give up?
Strong answer: Walk every rule and interface for functions, modes, boundaries, interactions and error cases; ask designers about risks; include reset and power transitions.
Likely follow-up: Which features are most often missed?
Strong answer: By risk: likelihood times consequence, giving the most effort to features whose bugs are likely and severe.
Likely follow-up: How do you estimate likelihood?
Strong answer: Per feature from past projects, adjusted for novelty and complexity, plus infrastructure and debug time; state the uncertainty.
Likely follow-up: What usually overruns?
Strong answer: Test counts, pass rates, raw coverage percentages and raw bug counts without effort beside them.
Likely follow-up: What would you report instead?
Strong answer: Tiers: quick smoke on every commit, broader nightly runs, full regression weekly, with failing seeds kept and runs sized by risk.
Likely follow-up: How do you keep regression time under control?
Strong answer: Assess impact on features, checks and coverage; update the plan; rerun affected evidence; record it as a risk until re-verified.
Likely follow-up: What if it arrives a week before tape-out?
Strong answer: Reproduce it cheaply, find the first wrong value, follow it back to the cause, decide whether design or testbench is wrong, fix, and add a check that would catch it earlier.
Likely follow-up: How do you decide it is a testbench bug?
Strong answer: Bucket by signature with run-dependent details abstracted, debug one representative per bucket, largest or earliest first, and rerun after each fix.
Likely follow-up: How do you choose the signature?
Strong answer: Find the last passing and first failing commits and test halfway between until one change is left; also bisect the stimulus to the shortest failing case.
Likely follow-up: What if the failure is intermittent?
Strong answer: Find the root cause, not the symptom; check the fix against the rule, not just the test; sweep for the same class elsewhere; add the missing check.
Likely follow-up: What is a symptom fix?
Strong answer: From discovery curves normalised by effort, from capture-recapture between independent methods, or from planted-bug detection rates, each with a range.
Likely follow-up: How reliable are these estimates?
Strong answer: A falling count can come from falling effort; only bugs per unit of effort, with effort stable, suggests the design is getting cleaner.
Likely follow-up: What else would you look at?
Strong answer: Agreed at planning: evidence per feature, coverage decided, key properties proved, planted bugs caught, bug trend with effort, open bugs decided, reviews done, residual risk written.
Likely follow-up: Which criterion is most often fudged?
Strong answer: When the gap is understood, its consequence assessed, the cost of closing it outweighs the risk, and an owner and approvers sign it, with a follow-up.
Likely follow-up: What does a bad waiver look like?
See lesson 14.3, Waivers.
Strong answer: Safety mechanisms become features, fault injection measures diagnostic coverage against ISO 26262 targets, and traceability and process evidence are audited.
Likely follow-up: What is diagnostic coverage?
Strong answer: Not bit-exact against a loop model: use a tolerance derived from the format and scaled to the terms, or a bit-accurate model of the hardware's order, and validate the tolerance with planted bugs.
Likely follow-up: Why must the tolerance scale?
Strong answer: Legal ranges checked in RTL, extremes and customer configurations regressed, pairwise covering arrays, random configurations nightly, and a parameterised testbench.
Likely follow-up: How many configurations cover all pairs?
Senior answers make a decision and give the reason and the trade-off.
Prepare for the follow-up: it is where interviews are decided.
Ground answers in a concrete example, ideally one you have built or run.