Do I need to grind hundreds of puzzle questions?

A handful of classic ones (clock domain crossing, metastability, low-power tricks, basic STA fixes) is worth knowing. Beyond that, applied reasoning beats volume.

What if I blank on a definition?

Say so, then reason from first principles. Interviewers respond far better to "I do not remember the exact term, but the idea is…" than to a confident wrong answer.

GROUND TRUTH · SEMICONDUCTORS / VLSI

What a VLSI Interview Actually Asks (vs What You Studied)

The questions behind the questions in a real VLSI interview.

VLSI interviews for freshers and early-career engineers test whether you can reason about timing, power, verification, and debug, not whether you memorised setup/hold formulas. Here is what the questions are really probing.

By Prashanth Jakkula · Published 2 September 2026 · Last reviewed 2 October 2026 · Researched from job postings, engineering references, and public practitioner accounts, then written and checked by the author before publication. AI tools may help with research and editing. See our Editorial Policy for how articles are produced and reviewed, or About HireSetu for who operates it.

Candidates prepare for VLSI interviews by revising definitions: setup time, hold time, metastability, the MOSFET regions of operation. Those come up, but they are the warm-up. What the interviewer is checking is whether you can apply that knowledge to a scenario and reason out loud when the answer is not obvious.

The question you hear vs what it is testing

Question asked	What they are really checking
"What is setup and hold time?"	Warm-up. The real follow-up is "this path fails setup: what are three ways to fix it?"
"Draw a 2:1 mux / write it in Verilog"	Can you move between gate, transistor, and RTL views of the same thing without getting stuck.
"How would you verify this block?"	Do you think in terms of a plan, coverage, and corner cases, or just "write some tests".
"This chip is drawing too much power. What do you do?"	Do you have a mental model of dynamic vs leakage power and the levers for each.
"A test is failing intermittently. Walk me through it."	Structured debugging: isolate, reproduce, form a hypothesis, check it, not guessing.

The setup and hold follow-up, worked through

Almost every digital interview reaches timing within the first twenty minutes. The definitions take one sentence each. The interview is in what comes next, so it is worth knowing the two slack equations well enough to reason from them instead of reciting them.

Setup slack = (clock period + capture clock latency) − (launch clock latency + clock-to-Q + slowest combinational delay + setup time). Negative means data arrives too late for the next edge.
Hold slack = (launch clock latency + clock-to-Q + fastest combinational delay) − (capture clock latency + hold time). Negative means new data races through and corrupts the value being captured on the same edge.
The clock period appears only in the setup equation. That is why a hold violation cannot be fixed by slowing the clock, and why interviewers like asking it.

Ways to fix each violation, and what each one costs

Fix	Helps	Cost or catch
Reduce logic depth on the path (restructure, retime)	Setup	Design effort; retiming moves registers and can change behaviour at reset.
Upsize drivers or use faster, low-threshold-voltage cells	Setup	More area and noticeably more leakage power.
Add a pipeline stage	Setup	One extra cycle of latency, which the rest of the design must tolerate.
Delay the capture clock (useful skew)	Setup	Takes margin away from the next stage, which may then fail.
Lower the clock frequency	Setup only	Usually not allowed; the frequency is a product requirement.
Insert delay buffers on the data path	Hold	Area, and it can create a setup problem if the path had little setup margin.

A good answer names two or three fixes, picks one for the stated situation, and says what it would check afterwards (re-run timing across corners, since a fix at the slow corner can break hold at the fast corner).

Clock domain crossing: the question that separates candidates

When a signal moves between two unrelated clocks, the receiving flop can sample it while it is changing and go metastable. Expect to be asked how you would pass a signal across, and expect the follow-up to change the signal from one bit to many.

One control bit: a two-flop synchronizer in the destination domain. It reduces the chance of metastability reaching the logic; it does not remove it, and it adds latency.
A multi-bit bus: never synchronize each bit separately, because the bits can be captured on different cycles and form a value that never existed. Use a handshake, a mux-recirculation scheme, or an asynchronous FIFO.
Asynchronous FIFO pointers are passed across in Gray code, so only one bit changes per increment and a mis-sampled pointer is off by at most one position.
A short pulse from a fast clock can be missed entirely by a slow one; convert it to a level or toggle first.

A small calculation you may be handed

FIFO depth questions test whether you can turn a description into arithmetic. Example: a writer sends a burst of 40 words at one word per cycle, and the reader takes one word every two cycles on the same clock. During the 40-cycle burst the reader removes 20 words, so 20 are left waiting at the end of the burst and the FIFO needs at least 20 entries. Interviewers then change one thing (different clocks, idle cycles between bursts) to see whether you rebuild the reasoning or guess.

Power: the levers behind the formula

Dynamic power is roughly activity × switched capacitance × voltage² × frequency. Clock gating attacks activity; lowering voltage has the largest effect because it is squared, which is why designs use voltage and frequency scaling.
Leakage power flows even when nothing switches. It is reduced with high-threshold-voltage cells on paths that have timing margin and with power gating of idle blocks, and it rises with temperature.
The trade-off interviewers want to hear: the cells that leak least are also the slowest, so leakage and timing pull against each other.

The same title, four different interviews

What each VLSI track tends to probe

Track	Typical depth questions
RTL design	Finite state machines, blocking vs non-blocking assignments, FIFO depth, writing synthesizable code, what a given always block synthesizes to.
Design verification	SystemVerilog classes and constrained-random stimulus, functional coverage, assertions, how a UVM testbench is structured and why.
Physical design	The flow from floorplan to routing, clock tree synthesis, static timing analysis, IR drop and congestion, DRC and LVS checks.
Analog / mixed-signal	MOSFET operating regions, small-signal models, current mirrors, op-amp stability, noise and matching.
DFT	Scan chains, stuck-at fault models, ATPG coverage, memory built-in self-test.

Read the posting to see which track the role is in before preparing. A campus "VLSI engineer" opening at a large company may route you to any of these teams, so the first technical round often covers digital fundamentals broadly and later rounds go deep in one track.

How the rounds are usually arranged

An online test: aptitude plus digital electronics, often with a few Verilog or CMOS questions.
One or two technical rounds: fundamentals first, then the scenario questions above.
A round on your project, where you are asked why you made each choice.
A manager or HR round on the team, location and joining timeline.

How your project gets questioned

What the block does and why you chose that architecture over the obvious alternative.
How you verified it, and what you did not verify.
If you ran synthesis: the frequency it met, the critical path, and what limited it.
One thing that went wrong and how you found it. Interviewers trust a project more when you can describe a bug you fixed.

What gets a fresher rejected

Reciting a definition perfectly but freezing when asked to apply it.
Claiming project experience you cannot defend, "I did UVM" with no ability to explain the testbench you built.
Only knowing one view (RTL) and not being able to connect it to timing, power, or physical reality.
Not being able to describe your own final-year project as an engineering problem with trade-offs.

What a strong answer sounds like

Restate the problem in your own words and state your assumptions.
Give the direct answer if you have one.
Then reason: "there are a few ways to approach this, A, B, C, and I would pick B here because…".
Name what you would check or measure to confirm.
Say what you do not know, honestly, and how you would find out.

Prep that maps to the interview

For every concept you revise, prepare one applied scenario ("a path fails hold, now what").
Be able to explain your project as: problem, approach, trade-offs, what you would do differently.
Practise thinking aloud: interviewers score reasoning, not just the final number.
Know the flow end to end so you can place any question in context.

Do I need to grind hundreds of puzzle questions?: A handful of classic ones (clock domain crossing, metastability, low-power tricks, basic STA fixes) is worth knowing. Beyond that, applied reasoning beats volume.
What if I blank on a definition?: Say so, then reason from first principles. Interviewers respond far better to "I do not remember the exact term, but the idea is…" than to a confident wrong answer.

References and further reading

Background reading on the topic of this article. HireSetu is not affiliated with these organisations.