Verification Interview Questions: The Complete DV Guide for India (2026)

TL;DR. Verification interviews in India test six things in order: SystemVerilog fluency, constrained-random and constraints depth, UVM architecture, assertions and coverage reasoning, debug instinct on a real failing test, and a bug story with specifics. Most 3-5 year candidates can draw a UVM environment but flame out on constraint solving, RAL, and "walk me through how you debugged this regression." This guide gives you the 38 real questions I've both asked and been asked over the last three years, with answers tuned to the 3-5 year level, plus the six-week prep plan I hand every engineer I mentor.

I led UVM verification teams for mobile SoCs at Qualcomm and have sat on both sides of well over 200 DV interviews. Verification is the single highest-demand VLSI specialisation in India right now — consistently the largest bucket of open roles on our verification job board. That's the good news. The bad news is the bar has moved: five years ago, knowing the UVM component names got you an offer. In 2026 everyone knows the names. What separates a 12 LPA offer from a 32 LPA offer is whether you can reason about constraint distributions, explain factory overrides without hand-waving, and tell a real debugging story with a waveform in your head.

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

What verification interviewers actually test

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

1. SystemVerilog depth (20%). Not syntax trivia — the semantics that cause real bugs: clocking-block sampling, 2-state vs 4-state, variable lifetime, deep vs shallow copy.
2. Constrained-random and constraints (20%). The top differentiator at 3-5 years. rand vs randc, solve-before, distribution reasoning, debugging a constraint that won't converge.
3. UVM architecture (20%). Phasing, config_db, sequences, factory, TLM, RAL. Interviewers probe whether you've built an environment or just inherited one.
4. Assertions and coverage (15%). SVA implication and sampling, functional vs code coverage, and what "closure" actually means.
5. Debug and methodology (15%). Given a failing regression, a coverage hole, or an X in the scoreboard — where do you look first?
6. Bug story (10%). The most predictive question in the loop: "tell me about a real bug you found." Specifics or nothing.

The candidates who get product-company offers have owned a component end to end — written a sequence library, closed a coverage model, root-caused a corner-case bug. The ones who stall at service companies usually only ran tests someone else wrote.

The typical interview structure

Round 1: Technical screen (45-60 min)

Fundamentals, usually with a senior DV engineer: SystemVerilog basics, directed vs constrained-random, what a scoreboard does, and a quick coding task like "write a constraint so this array is sorted" or "write an assertion for this handshake."

Round 2: UVM deep dive (60-90 min)

You'll draw an environment and defend every arrow: "draw a UVM env for a bus protocol," "how does a sequence item reach the DUT," "how do you set the number of agents at runtime without editing the agent," "the monitor sees a transaction but the scoreboard never gets it — where do you look?"

Round 3: Constraints, coverage and debug (60-90 min)

The round that sets your offer level: "write a constraint where length depends on type and burst addresses don't cross a 4KB boundary," "randomize() fails 1 seed in 1000, debug it," "100% code coverage but 78% functional — what does that mean," "a nightly regression has 4 failing tests, walk me through triage."

Round 4: Project deep dive + managerial (60 min)

Pick a block, pick the hardest bug, your coverage model, your closure strategy, specific numbers. Killer question: "tell me about a bug that took you more than a week to find." Have a real answer with a real waveform.

Round 5: HR and offer (30 min)

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

38 real verification interview questions, with answers

SystemVerilog fundamentals (1-8)

1. Why use an interface instead of individual module ports?
An interface bundles related signals into one named construct, supports modports to enforce direction, and holds clocking blocks for synchronization. Critically for UVM, the virtual interface is the bridge between the static hardware side (DUT + physical interface) and the dynamic class-based testbench — drivers and monitors reach the DUT through a virtual interface handle passed in via config_db.

2. What does a clocking block do, and why does it eliminate races?
It groups signals sampled or driven relative to a clock, with an input skew (how long before the edge inputs are sampled) and output skew (how long after they're driven). Because the testbench samples just before the active edge and drives just after, you avoid the race where TB and DUT update the same signal in the same time step and get simulator-dependent results. Driver and monitor should talk to the DUT through a clocking block, not raw signals.

3. What's the difference between 2-state and 4-state types, and when does it matter?
logic/reg/wire are 4-state (0,1,X,Z); bit/int are 2-state. Use 4-state logic for anything facing the DUT so you can see X and Z and catch uninitialized-register and bus-contention bugs; use 2-state inside the TB for performance and randomization. The trap: sampling a DUT output into a 2-state variable silently converts X to 0 and masks a real bug — a classic "passes in sim, fails in silicon."

4. What's the difference between == and === ?
== returns X if either operand has any X/Z bit; === is a case-equality that compares all four states and returns a definite 0/1, treating X and Z as matchable. In a scoreboard you want === so an unexpected X is flagged as a mismatch rather than producing an X that your if treats as false — using == in checkers is a subtle way to let X-bugs slip through.

5. Static vs automatic lifetime — why does it bite testbench writers?
A static variable is shared across all calls; an automatic one gets a fresh instance per call. Module tasks default to static, so two concurrent threads calling the same static task clobber each other's variables — a reentrancy bug. Class methods are automatic (safe). The rule: any task/function that can run concurrently must be automatic, and loop variables forked into threads must be captured per-iteration.

6. Explain deep copy vs shallow copy for class objects.
A shallow copy duplicates scalar fields but copies object handles as handles, so both objects share the same sub-object; a deep copy allocates new sub-objects recursively. This bites when a transaction contains a payload object — shallow-copying a clone means mutating the clone also mutates the original, producing baffling scoreboard mismatches. UVM's do_copy and field macros give you control.

7. What are virtual methods and why does UVM depend on them?
A virtual method is dispatched by the actual object type at runtime, not the handle type. UVM's factory relies on this: you write against a base handle, the factory constructs a derived type, and because body(), do_copy, write() etc. are virtual, the derived behavior runs. Forget virtual and a factory override compiles but silently calls the base method — hours wasted because everything looks correctly wired.

8. Tasks vs functions — when must you use a task?
A function runs in zero time and cannot contain timing controls (@, #, wait); a task can consume time. So anything that waits for a clock edge, drives a pin over multiple cycles, or blocks on an event must be a task — drivers and a monitor's sampling routine are tasks; a pure data transform or scoreboard predictor can be a function.

Constrained-random and constraints (9-13)

9. What's the difference between rand and randc?
rand picks uniformly (subject to constraints) each call with repeats allowed; randc is cyclic — it walks every legal value in a random permutation before any repeats, useful for iterating a small enum like opcodes so none is starved. Because randc keeps per-object cycle state and suits small domains, you don't use it for wide fields like 32-bit addresses; there rand plus a distribution constraint is right.

10. What does solve...before do, and does it change legal values?
It tells the solver to pick a first, then b. It does not change the legal solution set — it changes the probability distribution. Classic example: a is 1-bit and a -> b < 10; without ordering, solutions weight toward whichever a pairs with more b values, so a==1 becomes rare. solve a before b makes a equally likely. Use it to fix biased distributions, not to make illegal cases legal.

11. Write a constraint: a burst of addresses that must not cross a 4KB boundary.
The start offset within the page plus the burst byte count minus one must stay in the same 4KB page: constraint no_4k_cross { (addr % 4096) + (len * bytes_per_beat) <= 4096; }. Interviewers want (a) a modulo for the page offset, (b) accounting for transfer size, and (c) recognition that this is the AXI 4KB rule — naming the protocol earns credit. The usual follow-up, "now make length depend on burst type," tests implication constraints.

12. Your randomize() fails on ~1 seed in 1000. How do you debug it?
First, always check the return value — a silent failure reuses stale values. Then bisect: disable constraints with constraint_mode(0) and variables with rand_mode(0) to find the contradictory pair, which is usually a hidden interaction like a solve...before plus an inside range that only conflicts for certain values. Turn on the solver's verbose failure reporting. The lesson interviewers listen for: over-constraining is a bug, and an unchecked randomize() return is worse.

13. What's the difference between hard and soft constraints, and where are soft useful?
A hard constraint must always hold or randomization fails; a soft constraint is a default the solver honors unless a stronger constraint contradicts it, in which case it's silently dropped. Soft constraints make reusable items: a base item sets soft len == 8 and a specific test overrides it with a hard constraint without an over-constraint failure. The pitfall is relying on soft constraints for legality — anything that must hold has to be hard.

UVM architecture (14-23)

14. Draw the UVM component hierarchy and explain each piece.
Top to bottom: test (selects config and sequences) builds the env, which holds one or more agents plus a scoreboard and coverage collector. Each agent bundles a sequencer (arbitrates and feeds items), a driver (drives items onto the interface), and a monitor (samples the interface and broadcasts observed transactions via an analysis port). An agent is active (driver+sequencer) or passive (monitor only). The point interviewers probe: driver and monitor never talk to each other — the monitor is independent so it catches what actually happened on the bus, not what the driver intended.

15. uvm_component vs uvm_object — what's the difference?
uvm_component instances form the static, persistent hierarchy: they live for the whole sim, have a parent and a full hierarchical name, and participate in phasing. uvm_object instances are transient data — sequences and sequence items — created and destroyed dynamically with no fixed place in the tree. Test/env/agent/driver are components; the transactions flowing through them are objects.

16. Explain UVM phasing. Why is build_phase top-down but connect_phase bottom-up?
build_phase runs top-down because a parent must construct and configure its children before they build their own — the env sets an agent's config before the agent builds its driver. connect_phase runs bottom-up because you can only wire ports once both ends exist, so leaves connect first. The time-consuming work happens in run_phase (with sub-phases reset/configure/main/shutdown), the only phase that consumes simulation time and is gated by objections.

17. How do objections control the run phase?
The run phase ends when no component holds an objection. A sequence raises an objection when it starts meaningful work and drops it when done; the phase stays alive while any objection is outstanding. Common bugs: forgetting to drop (test hangs to timeout) or dropping too early (test ends before the DUT drains). At scale, teams often raise objections only in the top sequence to avoid objection-thrashing overhead.

18. Walk the driver-sequencer handshake for one transaction.
The sequence calls start_item(req) then finish_item(req); the driver calls get_next_item(req), which blocks until the sequencer hands it an item, drives it over however many clocks it needs, then calls item_done() to signal completion and unblock the sequencer. Responses come back via item_done(rsp) or a separate response path. Key insight: the sequencer is an arbiter — with multiple sequences on one sequencer it grants by priority, and the driver is oblivious to which sequence produced the item.

19. What is config_db and how does set/get match?
uvm_config_db#(T)::set(context, path, key, value) stores a typed value keyed by a hierarchical path (which can contain wildcards); get retrieves it. Typical uses: passing the virtual interface from top into drivers/monitors, and config objects from env to agents. Two frequent bugs: a type mismatch between set and get parameterization (silent miss, handle stays null), and setting after the target's build_phase has run so the get never sees it.

20. Explain the factory and type vs instance overrides.
The factory constructs objects by type lookup so you can substitute a derived class without editing the creating code — you call type::create() instead of new(). A type override replaces every construction of a base type everywhere; an instance override replaces it only at a specific path. You use it constantly — swap in an error-injecting sequence item for one test. Two gotchas: you must call create() (not new()), and overridden methods must be virtual.

21. What are TLM analysis ports and why does the monitor use one?
TLM ports pass whole transactions between components by method call instead of pin wiggling. A monitor publishes on an uvm_analysis_port, a broadcast (one-to-many) connection that can fan out to the scoreboard, coverage collector, and a protocol checker at once, each implementing write(). This decouples the monitor from its consumers — you add a coverage subscriber later without touching it. Unlike blocking put/get, analysis writes are non-blocking and never back-pressure the monitor.

22. What is RAL and what problem does it solve?
RAL models the DUT's register map as SystemVerilog objects so tests read/write registers by name (reg_model.CTRL.write(status, value)) instead of hardcoding addresses and bus sequences. It keeps two values per field — the mirror (what RAL believes hardware holds) and the desired value; a predictor updates the mirror from bus activity and an adapter converts abstract register ops into your bus's sequence items. This gives portable register tests that auto-check reads against expected values.

23. Explain front-door vs back-door register access.
A front-door access drives a real bus transaction through the sequencer and driver, exercising the actual decode logic and consuming cycles — the realistic path. A back-door access pokes/peeks the register directly via its HDL path in zero time, bypassing the bus. Back-door is great for setup (preload a config register instantly) but can't catch decode or access-policy bugs, so you verify each register front-door at least once.

Assertions and SVA (24-28)

24. Immediate vs concurrent assertions?
An immediate assertion is procedural and evaluates instantly when execution reaches it — a combinational sanity check inside always blocks or tasks. A concurrent assertion (assert property) is clocked, sampling signals in the preponed region and evaluating a temporal sequence over cycles. Concurrent assertions cover multi-cycle protocol properties; the preponed sampling is exactly why they don't race with RTL updating on the same edge.

25. Explain overlapping (|->) vs non-overlapping (|=>) implication.
Both mean "if the antecedent matches, the consequent must hold." Overlapping |-> checks the consequent starting the same cycle the antecedent completes; non-overlapping |=> starts the next cycle. So req |-> gnt needs grant the same cycle; req |=> gnt needs it the next. Picking the wrong one is the single most common SVA bug — the assertion is off by a cycle and either never fires or fires spuriously.

26. What do $rose, $fell, $stable and $past do?
$rose(sig) is true when the sampled value went 0-to-1 since the previous clock, $fell is 1-to-0, $stable is true when it didn't change, and $past(sig, n) returns the value n cycles ago. They let you write edge-sensitive properties without manual flops, e.g. "once valid rises, data stays stable until ready." All operate on sampled values, so they compose cleanly with implication.

27. What's the most common SVA pitfall?
Beyond the |->/|=> off-by-one, it's the vacuously passing assertion: if the antecedent never becomes true, the property "passes" every cycle without checking anything, so a broken assertion looks green. Guard against it with cover property(req) on the antecedent to confirm the precondition actually fired. Related traps: wrong clock (or no clock), and glitchy combinational signals sampled misleadingly.

28. When would you bind assertions instead of writing them in RTL?
bind attaches an assertion/checker module to a DUT instance from outside without editing the RTL — useful when designers own the RTL and don't want checker clutter, or when verifying encrypted/third-party IP you can't modify. You write the properties in a separate module referencing the DUT's signals and bind it to the instance. It's also how reusable protocol assertion IP (like standard AXI checkers) gets attached.

Coverage (29-32)

29. Code coverage vs functional coverage?
Code coverage is automatic and structural — line, toggle, branch, condition, FSM-state — measuring which RTL the sim exercised. Functional coverage is manual and intent-driven — covergroups measuring whether the scenarios you care about (every packet type, FIFO full/empty, every legal transition) actually occurred. Code coverage tells you what RTL you touched; functional coverage tells you what intent you hit. Neither alone is sufficient.

30. 100% code coverage but 78% functional coverage — what does that mean?
Every line ran, but ~22% of the scenarios your model says matter never happened — legal behaviors your stimulus never generated. Usually your constraints are too narrow (a packet type or corner is effectively unreachable) or the model has bins you can't currently create. The action: inspect the uncovered bins, then add directed/targeted sequences or loosen constraints. The inverse — high functional, low code — points to dead or unreachable RTL, a design question.

31. Explain coverpoints, bins, and cross coverage.
A coverpoint samples a variable (say pkt.len); bins partition its values into buckets you care about, with explicit, ignore, and illegal bins. Cross coverage measures combinations of two or more coverpoints — crossing packet type with length tells you whether you've seen every type at every length, not just each alone. Cross coverage is where real corner cases hide, e.g. a jumbo frame on the error-injection path.

32. What does "closing coverage" mean, and how do you do it?
Closure means driving functional coverage to the agreed target (usually 100% of reachable bins, with documented waivers) and hitting code-coverage goals. The loop: run regressions, merge coverage across seeds, find holes, close them by adjusting constraints, adding targeted sequences, or waiving genuinely unreachable bins with justification. The honest part interviewers want: 100% coverage isn't bug-free — it means you exercised what your model described, and the model itself can have blind spots.

Methodology, architecture and debug (33-38)

33. Constrained-random vs directed testing — when do you use each?
Directed tests hand-craft stimulus for a known scenario — fast for one case but they only find bugs you anticipated and don't scale. Constrained-random generates legal-but-varied stimulus across seeds, finding corner cases you didn't foresee, and pairs with functional coverage to measure progress. The real answer is both: constrained-random for bulk coverage and discovery, directed (or heavily constrained) tests to close specific holes and pin down tricky reset/error scenarios.

34. What's a scoreboard and how does the reference model fit in?
A scoreboard checks DUT outputs against expected behavior. Typically an input-side monitor feeds observed inputs into a reference model (a golden predictor — C model, behavioral SV, or an algorithmic function) that computes the expected output, an output-side monitor feeds actual outputs in, and the scoreboard compares, accounting for ordering and latency. Out-of-order or pipelined designs need queues or ID-keyed associative arrays rather than an in-order compare. A testbench with great stimulus and a weak checker finds nothing.

35. How do you verify clock-domain crossings?
Two-pronged. Structural CDC is a static tool that finds every crossing and confirms each has a proper synchronizer (two-flop for control, handshake or gray-code for buses) and flags reconvergence — you cannot find missing synchronizers reliably by simulation. Metastability verification then injects random delay on synchronizer outputs in sim to prove the design tolerates the non-determinism. The point to make: RTL sim doesn't model metastability, so you need the static tool plus injection.

36. What does low-power (UPF) verification add?
UPF describes power intent — domains, isolation cells, level shifters, retention registers, power switches — separately from the RTL. Power-aware sim models domains powering down: signals from an off domain corrupt to X unless isolated, retention registers must restore on power-up, and you verify the power sequencing and isolation/retention control. So you need sequences that exercise power-state transitions and checks that isolation clamps and retained state survive. Missing isolation is a classic bug only power-aware sim catches.

37. What's gate-level simulation for, and what is X-propagation?
GLS runs the synthesized/post-layout netlist, often with SDF timing, to catch what RTL sim misses: real reset behavior, X-propagation, scan connectivity, timing issues. X-propagation is that RTL sim is often optimistic about X — an if(x) or case can pick a branch and mask an uninitialized value, whereas hardware resolves to a random 0/1 that may be wrong. GLS (or RTL X-prop mode) makes X pessimistically propagate, exposing registers you forgot to reset — which is why a design clean in RTL sim can still fail in GLS.

38. Walk me through debugging a failing nightly regression.
Reproduce deterministically with the exact seed and testcase, and check whether it's one failure or a cluster (same signature often means one root cause or a bad merge). Read the failure type — scoreboard mismatch (reference model vs DUT disagree, or a config mismatch), assertion fire (localizes the cycle and signal), timeout (usually a dropped objection or hung handshake), or X (often reset/uninitialized state). Then open the waveform at the failing time, walk backward to the first divergence, and test one hypothesis at a time. The discipline interviewers listen for: reproduce, localize, hypothesize, confirm — not randomly poking constraints.

Tools they'll ask about

• Synopsys VCS + Verdi — the dominant simulator/debug pair at most product companies; Verdi waveform and signal-tracing fluency is expected.
• Cadence Xcelium + SimVision / Indago — common at Cadence, NVIDIA and others; same expectations, different UI.
• Siemens Questa — widely used, strong on coverage and CDC/formal add-ons.
• Formal tools (Cadence Jasper, Synopsys VC Formal) — increasingly asked about even for simulation roles; know when formal beats simulation.

When to reach for formal verification

Formal (property checking) exhaustively proves or disproves a property over all reachable states with no stimulus, so it shines on control logic: arbiters, FIFO overflow/underflow, state machines, register access policies, and deadlock, plus CDC and connectivity checks. It struggles on data-path-heavy or deeply sequential designs where the state space explodes. The mature answer: formal and constrained-random are complementary — formal-verify the tricky control corners, use UVM constrained-random for full-chip and data-path coverage. If a company's stack leans formal, expect questions on writing a property and on assumption modeling.

Company-specific interview patterns (2026)

• Qualcomm — Deep UVM and RAL plus low-power (UPF) verification for mobile SoCs. Expect config_db, factory, register-model, and a power-state-transition scenario. Prep: know RAL front/back-door cold.
• NVIDIA — Scale and methodology. Huge testbenches; they want reusable, performant SystemVerilog and coverage-closure reasoning at scale. Prep: constraints, coverage modeling, 2-state performance tradeoffs.
• Intel — Rigorous on fundamentals and signoff: coverage-closure discipline, GLS/X-prop, assertions. Prep: SVA depth and coverage methodology.
• Broadcom — Networking ASICs: protocol verification and scoreboard/reference-model design for high-throughput out-of-order traffic. Prep: checker architecture for pipelined/OOO designs.
• NXP and MediaTek — Broad SoC verification mixing UVM and directed testing; NXP (automotive) adds ISO 26262 fault-injection flavor. Prep: solid UVM plus a clear bug story.
• Cadence and Synopsys — Methodology and tool internals: how does the constraint solver work, how would you build a checker library. Less block-craft, more methodology depth.

The 6-week prep plan

Weeks 1-2: SystemVerilog and constraints fluency

Write code, don't just read. Each day implement one thing from memory: a constraint for a layered packet, a self-sorting array, a randc opcode iterator, a clocking-block driver. Re-derive why solve...before shifts a distribution until you can explain it cold. If you can't write a 4KB-boundary constraint without notes, you're not ready for Round 3.

Weeks 3-4: UVM architecture, top to bottom

Build (or rebuild) a small UVM environment for a toy protocol end to end — agent, sequencer, driver, monitor, scoreboard, coverage, and a small RAL model — so "how does the item reach the driver" and "how does the monitor reach the scoreboard" become muscle memory. Read the UVM class reference for phasing, config_db, and factory, not a blog summary.

Weeks 5-6: Coverage, assertions, mocks and your bug story

Design two coverage models and two non-trivial SVA properties from written specs. Do three mock interviews and record them — your whiteboard is worse than you think. Then polish the single most important answer in the loop: a three-minute bug story with the block, the symptom, the waveform, 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 verification engineers (2026)

• Service companies (Wipro VLSI, HCL, LTTS, Tata Elxsi): 9-15 LPA
• Mid-tier product (Cadence, Synopsys, NXP, MediaTek): 18-28 LPA
• Top-tier product (Qualcomm, Intel, Broadcom, Texas Instruments): 26-40 LPA
• Hyper-growth (NVIDIA, AMD): 32-55 LPA

Verification is the highest-volume specialisation, which cuts both ways: more openings, but more candidates, so depth at product companies is what separates offers. If you're stuck in the service-company band with 3-5 years of real UVM and coverage-closure experience, focused interview prep genuinely 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 testbench they ran, not the verification they did. "I ran UVM tests and checked the log" is the flow talking. "I built the coverage model for the DMA descriptor engine, found jumbo transfers on the error path were never randomized, added a targeted sequence, and caught a scoreboard mismatch that turned out to be a real RTL bug in the last-beat handling" — that's an engineer talking. The bug story is the highest-signal answer in the entire loop, and most candidates walk in without one.

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

Related reading

• VLSI Verification Engineer Interview Guide 2026 (round-by-round)
• UVM: The Complete Guide for VLSI Engineers in India (2026)
• Verilog vs SystemVerilog vs UVM: when to use what
• VLSI engineer salary in India 2026: the complete guide