A whiteboard question is deliberately under-specified: no frequencies, no sizes, no traffic. Candidates who dive into a solution guess those silently, and the interviewer spends the rest of the session excavating the guesses. Candidates who state them up front turn the same unknowns into a scored strength. The four-part shape exists because the rubric has four dimensions, and each part feeds exactly one: Assumption feeds the assumption score, Mechanism feeds mechanism, Trade-off feeds trade-off, Evidence feeds evidence.
Assumption states every number the question omitted and how you would check it: frequencies, sizes, traffic, protocol, power state. Name each one aloud and give it a value, even a labelled illustrative one, because a stated assumption can be corrected while a silent one cannot. Mechanism explains how it works at signal and cycle level: which handshake, which synchroniser, which arbitration decision, in which order. Trade-off compares at least two options with costs in the same units: area, cycles, power, complexity. Evidence quantifies or names how you would verify: a formula with numbers, a test, a checker class. The order matters: assumptions first so the mechanism has numbers to stand on, evidence last so it verifies the mechanism you actually described.
Take the warm-up question: how long does a CPU single-word read from on-chip SRAM take on NanoSoC. The assumption part fixes the path (CPU through the asynchronous bridge, fabric, SRAM0, back), one access in flight, caches cold for the data. The mechanism part walks the seven system clocks plus four CPU clocks: issue, request crossing, fabric address, two-cycle memory latency, fabric data, response crossing. The trade-off part compares the blocking single-word path against a 4-beat line fill: 93.75 ns for one word versus 125 ns for four, which is 42.67 MB/s against 128 MB/s. The evidence part recomputes the total from the periods and asserts it. The script below is that evidence part, and it is also the habit: never quote a derived number without the three-line check behind it.
t_cpu = 1 / 192e6
t_sys = 1 / 96e6
# Assumption: blocking read, one access in flight: 7 slow clocks + 4 fast clocks.
total = 7 * t_sys + 4 * t_cpu
assert abs(total * 1e9 - 93.75) < 0.01, total
# Trade-off: a 4-beat line fill adds 3 more beats, one system clock each, for 3 more words.
fill = total + 3 * t_sys
assert abs(fill * 1e9 - 125.0) < 0.01, fill
bw_word = 4 / total / 1e6
bw_fill = 16 / fill / 1e6
assert abs(bw_word - 42.67) < 0.05, bw_word
assert abs(bw_fill - 128.0) < 0.1, bw_fill
print(f"word {total * 1e9:.2f} ns ({bw_word:.2f} MB/s)")
print(f"fill {fill * 1e9:.1f} ns ({bw_fill:.1f} MB/s)")
print("PASS: 93.75 ns word, 125 ns fill, trade-off priced")Assumptions are stated before the mechanism uses them, each with a value and a source (the NanoSoC tables, or labelled illustrative).
The mechanism names signals and cycles, not boxes: handshakes, crossings, arbitration decisions in order.
The trade-off compares two named options with numbers in the same units, and names what would flip the choice.
Evidence is a recomputation, a named test or a checker class, not a promise that it would be verified.
Practise by recording yourself answering one rapid-fire question and ticking which of the four parts you actually said: most candidates discover they gave mechanism only. A second habit catches silent assumptions: after every number you write, ask aloud what would change it, and write that beside it. If the answer has no numbers at all, it has no assumptions part yet, which means it is scoring at most half marks before the first probe lands.
Because evidence verifies a specific mechanism: the recomputation must use the same path the mechanism walked, and the test must target the failure the trade-off accepted. Evidence stated before the mechanism is a generic promise worth 1 mark.