Silence is the worst thing you can give an interviewer: they cannot score reasoning they cannot hear. Use the same order every time, so you never have to decide how to start.
Restate the question in one sentence, so you both agree on what is being asked.
Ask one or two clarifying questions (see the table below).
Classify the puzzle: language semantics, scheduling and timing, randomization, assertion, coverage, UVM, clock/reset/CDC, or logic.
State assumptions about types, widths, signedness, clocking and sampling.
Trace value by value, or region by region for timing puzzles, speaking as you write.
Name the rule that decides the outcome.
Give the answer, then the trap, then what a mutation would change.
A good question shows that you know what the answer depends on. A bad question asks for the answer. Ask only what changes the result.
Puzzle type | What to ask |
|---|---|
Language and data types | Are these 2-state or 4-state types? What are the widths and signedness? Is the question about what the standard says or what a particular tool prints? |
Forks, processes, queues | Do you want the order the standard guarantees, or the order one tool produces? Is the loop variable declared inside the loop (an automatic copy) or outside? |
Scheduler and races | Which module or program is this, and where is the sample point? Is the clock driven in the same time step as the data? Which tool and version? |
Randomization | Are the constraints hard or soft? Is the question about the set of legal solutions or about the probability of one value? Is there an inline with, or a mode that disables a constraint? |
Assertions | Which clock and which sampling? Is reset in disable iff? Is the property weak or strong, and does the question count a vacuous pass as a pass? |
Coverage | What is the sample event? Which bins are declared (default, ignore, illegal), and which options (at_least, weight, merge_instances) are set? Instance coverage or type coverage? |
UVM testbench | Which UVM version? Which phase is this code in, and at what hierarchy path is it running? Is the object created through the factory? |
Clock, reset, CDC | Is reset asynchronous or synchronous, and how is it released? What is the ratio between the clocks? Is this RTL or gate-level with delays? |
Logic and brain teasers | Is the question about the worst case or the average? Can I use any strategy, or must it be fixed in advance? Are the objects distinguishable? |
Debug scenarios | Is it reproducible with the same seed? Does simulation time still advance? What changed since the last passing run? |
Say so early and in one sentence: 'I have not used that construct directly. Let me reason from what I know.'
Reduce the problem to a rule you know. Most hard puzzles are two easy rules together; say which rule you are confident about.
Offer a way to find out: 'I would run it in the tool and check the print' or 'I would check the language reference for that region.' That is a real engineering answer.
Give a bounded guess, labelled as a guess, with the reason: 'My guess is two, because the second thread never gets the token.'
Never invent a rule. A confident wrong rule costs more than an honest gap.
Some puzzles have no single answer because the language does not define the order, and two correct tools can differ. Saying so is a strong answer if you say it in the right shape: what is defined, what is not, and how you would write code that does not depend on it.
"The standard fixes X, but it does not define the order of Y, so a tool may print either. I would not rely on it."
"Both outputs are legal. What is guaranteed is A before B; the order of the two threads is not."
"This is a race. The language does not say who wins, so I would remove it, for example with a clocking block or a nonblocking assignment, instead of predicting it."
"If I had to bet on one tool I would say Z, but that is tool behaviour, not the rule."
Write the code's names, not your own. Copy the key lines; do not paraphrase them.
Use one column per variable and one row per step for traces, with time on the vertical axis when time matters.
For scheduler puzzles, draw the regions in order (Preponed, Active, Inactive, NBA, Observed, Reactive, Postponed) and put each statement in its region.
Mark known and unknown values clearly (x, z, 0, 1) and keep widths next to every signed or unsigned value.
Circle the final answer and write the one-line rule beside it.
Leave space. You will want to correct the trace and a cramped board turns a correction into a mess.
Match the time to the level: about 3 minutes for an easy puzzle, 6 to 8 for medium and 10 to 15 for hard. If an easy puzzle takes 10 minutes, say so and ask whether to move on.
Give a first answer by the halfway point, even a partial one. Refine it afterwards.
Do not spend the whole time on the trace and leave none for the trap and the fix; those earn most of the credit on a hard puzzle.
When the interviewer interrupts with a hint, take it. It is not a penalty, it is the interview working.
In the last minute, state the answer again in one sentence.
Say it at once: 'I need to correct that.' Do not wait for the interviewer to find it.
Say what you got wrong and which rule corrects it: 'I treated the part-select as signed; it is unsigned, so the comparison is unsigned.'
Redo only the steps that depend on the error and give the new answer.
Keep your tone level. A calm correction is a positive signal; it shows how you behave when a design review finds your bug.
If you cannot find the error, say where you suspect it and offer to check it a different way.
Guessing an output without tracing it.
Trusting intuition over semantics.
Forgetting that simulators differ from the language reference only where the reference leaves things undefined.
Arguing with a hint instead of using it.