Interview Checklist — What You Must Derive, Not Recall

This is a revision gate, not a summary. Module 27 already contains the questions; re-reading them the night before is the least efficient possible use of the time.

What is worth reviewing is the short list of things you must be able to produce under pressure — a derivation you can do on a whiteboard, a distinction you can state in one sentence, and the small number of answers that end an interview badly.

1. What This Gate Owns — and What It Must Not Steal

It owns the last mile. The questions themselves are owned elsewhere.

What it must not steal. It must not re-ask Module 27's questions or re-explain Module 22's mechanisms. A revision list that re-teaches has become a course, and there is no time for a course the night before.

And what it must not become. A list of facts to memorise. 27.4 §21 established the standard: an engineer who knows the shape of an answer without the number is more useful than one who knows the number and not the shape — and interviews at every level above beginner are calibrated to detect the difference.

2. The Four Levels, in One Table

Know which room you are in, because the same question is scored differently at each level.

The escalation is in how much ambiguity the question carries, not in vocabulary difficulty. A beginner question has one answer; a senior question has several plausible ones and is scored on the observable that eliminates them (27.4 §2).

The most common calibration error is answering a senior question at advanced level — explaining the mechanism correctly and never saying how you would tell which mechanism was involved. It reads as knowledgeable and non-operational, which is precisely the distinction being tested.

3. The Distinctions That Get Tested Most

Each of these can be stated in one sentence, and each has a chapter behind it if the follow-up goes deeper.

The last row is the one worth over-preparing. A very large fraction of hard PCIe faults return Successful Completions carrying wrong data — no error bit, no log entry, a byte-identical trace. An engineer whose mental model is "faults produce errors" cannot reason about them at all.

4. The Six Derivations

1 — Outstanding requirement. tags = rate × RTT ÷ payload

2 — Credit floor. credits ≥ rate × RTT ÷ 16 B (the data credit unit, 16.1 §1)

3 — Protocol efficiency. payload ÷ (payload + header), for the 3 DW and 4 DW header forms (11.3)

4 — Fixed-cost amortisation. (payload + fixed) ÷ payload, with 16 B descriptor and 16 B status (ILLUSTRATIVE, from 26.4 §14)

5 — Transactions per operation. ⌈bytes ÷ MPS⌉ + fixed

6 — Little's Law. L = λ × W

And the observation that makes this list short. Derivations 1, 2 and 6 are the same equation: a rate multiplied by a time gives an amount that must be in flight, and the only difference is the unit you divide by — a payload, a credit unit, or nothing at all. Learn the shape once.

5. The Derivation Under Pressure

Interviewers ask for a number and score the derivation. Two habits make that go well.

Say the equation before the arithmetic. "Outstanding bytes is rate times round trip, so 16 gigabytes per second times a microsecond is 16 kilobytes, divided by a 256-byte payload is 62.5, so 64 tags." The equation is checkable; the number alone is not, and an interviewer who disagrees with your round-trip assumption can now say so.

And state the assumption you are least sure of. "I'm assuming a 1 µs round trip — if this is behind two switches I'd expect closer to 2 µs, which doubles the requirement." That single sentence converts a guess into an engineering estimate, and it is the behaviour 30.5 §4 measured as the difference between a number that can be re-checked and one that cannot.

What to do when you cannot recall a specification value. 27.4 §21 has the full form; the short version is three parts:

1. name the value you would look up, and where
2. derive what you can without it
3. say what changes if it turns out to be at either extreme

An answer with no value that contains all three demonstrates more than one with the value and none of them.

6. The Whiteboard RTL You Should Be Able to Write

Two blocks recur, and both are small enough to write correctly under observation.

The four-way counter. Asked in almost every RTL-adjacent PCIe interview, and the trap is that two of the four cases look mutually exclusive.

// The question is always some form of: "a request is accepted in the same
// cycle a completion retires — what is occupancy after the edge?"
// The answer is unchanged, and the implementation must say so explicitly.
always_ff @(posedge clk or negedge rst_n) begin
  if (!rst_n) occupancy <= '0;
  else begin
    unique case ({alloc_gnt, free_valid})
      2'b10: occupancy <= occupancy + 1'b1;
      2'b01: occupancy <= occupancy - 1'b1;
      2'b11: occupancy <= occupancy;        // net zero — NOT "no update"
      2'b00: occupancy <= occupancy;
    endcase
  end
end

27.4 §17 measured the wrong forms. An exclusive if (alloc) ... else if (free) ... drops the free whenever it coincides with an allocate, drifting occupancy upward without bound — 46,601 against a true value of 13 — until the pool reports itself full while every tag is free. And the two events coincided in 23.3% of cycles at load and essentially never at low rate, which is why it survives directed testing.

The ready/valid transfer. Three rules, and interviewers probe all three.

// 1. valid does not wait for ready
// 2. payload is stable while valid is high and ready is low
// 3. the transfer — and every counter — advances on (valid && ready)
assign out_valid = have_work;              // NOT (have_work && out_ready)
always_ff @(posedge clk or negedge rst_n)
  if (!rst_n)                    rd_ptr <= '0;
  else if (out_valid && out_ready) rd_ptr <= rd_ptr + 1'b1;

The third rule is the one that produces wrong performance numbers. A counter incremented on valid alone overstates throughput exactly when the sink is stalling — which is the condition being investigated (30.5 §11 P1).

7. The Debugging Answer

Senior interviews ask a debugging question, and it is scored on method rather than on the right guess.

The structure that works (25.1 §2, 30.6 §3):

symptom → last known good → expected next event → the observable that
distinguishes two hypotheses → what the answer licenses you to stop considering

The single most useful thing to say first is which observable you would read and why it splits the space. For a throughput question that is outstanding occupancy — 27.4 §14 measured two causes producing identical throughput, separated by occupancy readings of 31.9 and 4.0.

And the most useful thing to know about instruments is what they cannot see. 25.9 §13 measured three of five injected faults producing byte-identical analyzer traces. Volunteering that limitation reads as experience, because it is the kind of thing only people who have run out of ideas with a capture open tend to know.

8. The Four Sentences That End It Badly

None is about a missing fact.

"It's standard PCIe behaviour." Names no layer, no mechanism and no decision. The follow-up is always which mechanism, and what did you choose where the mechanism permits a choice — and there is no recovery if the answer is that you did not know there was a choice.

"It should be fine." A performance or correctness claim with no derivation and no measurement. Replace it with the derivation, even a rough one (§5).

"We didn't see any errors." Eliminates nothing (30.6 §2). A very large fraction of PCIe faults produce no error, and saying this reveals a mental model in which they must.

"I'd put an analyzer on it." As a first answer it is expensive and often useless — 30.6 §11 measured analyzer-first costing 2.8× the cheapest-first order and analyzer-only resolving 3 of 7 fault classes. As a later answer, with a stated question the trace would settle, it is correct.

9. The Twenty-Minute Review

10. The Interview Checklist — 20 Questions to Ask Yourself

Derivations (§4, §5)

1. Can I write the outstanding-requirement equation and work an example without notes?
2. Can I explain why the credit floor and the tag requirement are the same arithmetic?
3. Can I compute protocol efficiency for a small payload and say why it is worse than for a large one?
4. Can I state a derivation's assumptions before its result?
5. Do I say the equation before the number?

Distinctions (§3)

6. Posted versus Non-Posted, and what each receives back?
7. A PCIe Completion versus a device's status structure?
8. An ACK versus delivery?
9. Capability versus negotiated?
10. A credit stall versus a credit bottleneck?
11. Zero credits versus deadlock?
12. An error versus a wrong value?

RTL (§6)

13. Can I write the four-way occupancy counter and explain the 2'b11 case?
14. Can I state the three ready/valid rules and what each prevents?
15. Do I know why a counter incremented on valid produces wrong performance numbers?

Debugging (§7)

16. Can I give a debugging answer as a method rather than a guess?
17. Do I name the observable that splits the space, and what it eliminates?
18. Can I name three things an analyzer cannot see?

Calibration (§2, §8)

19. Do I know which level the question is being asked at?
20. Have I removed the four sentences in §8 from my vocabulary?

11. Misconceptions

"Revision means re-reading the material." Why it sounds plausible: it is what worked for exams, and the material is right there. What really happens: re-reading produces recognition, and interviews test production. Recognition and production are different skills, and only the second is being scored. What it causes: an engineer who felt prepared and could not write rate × RTT ÷ payload on a whiteboard.

"Memorise the specification values." Why it sounds plausible: interviewers do ask for values, and knowing one feels decisive. What really happens: above beginner level, the value is a prompt for the reasoning (27.4 §21). A candidate who supplies a number and no derivation has answered the smaller question. What it causes: a confident wrong value stated without qualification — which is worse than not knowing, because it cannot be corrected in the room.

"Senior interviews are advanced interviews with harder questions." Why it sounds plausible: the topics overlap almost entirely. What really happens: the difference is ambiguity, not difficulty (§2). Senior questions have several plausible causes and are scored on the observable that eliminates them. What it causes: answering a senior question at advanced level — correct, complete, and non-operational.

"If I don't know it, I should say something plausible." Why it sounds plausible: silence feels worse than a guess. What really happens: an unqualified guess is indistinguishable from a belief, and interviewers probe it. A named uncertainty is a strength (§5) and a disguised one is a liability. What it causes: a follow-up that exposes the guess, and a conversation that is now about your judgement rather than your knowledge.

"The RTL question is about syntax." Why it sounds plausible: you are being asked to write code. What really happens: it is about the same-cycle case (§6). 27.4 §17 measured the wrong forms drifting occupancy in 199,998 of 200,000 cycles — and the interviewer is watching for whether you enumerate all four combinations unprompted. What it causes: idiomatic code that is wrong in exactly the case being tested.

12. Understanding Check

Q1. You are asked how many outstanding requests a 16 GB/s target needs. What do you say first, and what do you say last?

First the equation, last the assumption you are least sure of (§5). "Outstanding bytes is rate times round trip, so 16 GB/s × 1 µs is 16 kB; divided by a 256-byte payload that is 62.5, so 64 tags." Then: "I'm assuming a 1 µs round trip and a 256-byte negotiated payload — behind two switches I'd expect nearer 2 µs, which doubles it to 125." The equation makes the answer checkable and the assumption makes it an estimate rather than a guess — and 30.5 §12 measured that both terms move without any design change, which is exactly why the assumption is worth naming.

Q2. Why are the tag requirement, the credit floor and Little's Law the same thing?

Because all three multiply a rate by a time to get an amount that must be in flight (§4). tags = rate × RTT ÷ payload, credits = rate × RTT ÷ 16 B, and L = λ × W differ only in what you divide by — a payload, a credit unit, or nothing. Recognising this reduces six formulas to one shape, which matters under pressure because you can re-derive any of them from the others rather than recalling three independently.

Q3. An interviewer asks you to write occupancy tracking for a tag pool. What must your answer contain, and what is being tested?

All four combinations of allocate and free, with the 2'b11 case written explicitly (§6). What is being tested is whether you notice that allocate and free are not mutually exclusive — 27.4 §17 measured an exclusive if/else drifting occupancy to 46,601 against a true value of 13, and the two events coinciding in 23.3% of cycles at load. Saying "these can happen together, so the net change is zero" before writing the code is the signal being looked for, because it demonstrates you reason in cycles rather than in statements.

Q4. "We didn't see any errors" eliminates nothing. Give the measured reason.

Because a large fraction of PCIe faults produce no error at all (§3, §8, 30.6 §2). 25.5 §12 measured a decoder fault returning Successful Completions with the wrong register's data — 87,414 accesses, no error at any layer. 25.9 §13 measured three of five injected faults producing byte-identical analyzer traces. 26.4 §5 measured 23,495 dropped frames with every PCIe counter clean. A hypothesis is eliminated by a positive observation, and the absence of an error is not one.

Q5. You are asked a throughput question and you do not know the specification's timeout range. Structure an answer that is stronger than one containing the value.

Three parts (§5, 27.4 §21). Name what you would look up: the range is configurable and device-dependent, so I would read the specification and the device's capability register. Derive what you can without it: the timeout must exceed the worst-case legitimate round trip through the deepest path, or requests that would have completed are abandoned — and every abandonment creates a reclaim-and-reissue window that needs a generation check. Say what changes at either extreme: a very long value means tag starvation under fault conditions; a very short one means misdeliveries from late Completions. That answer contains no number and demonstrates the mechanism, the failure modes and the design consequence.

13. Module 30 Complete

Seven gates, each answering a question the previous one could not.

The progression is a narrowing of who is being reviewed. The first four gates review an artefact — an architecture, an implementation, a test plan, a system. The fifth reviews a claim. The sixth reviews a process. And the last reviews the engineer, which is the only one of the seven whose evidence you cannot ask somebody else to produce.

One discipline runs through all seven, and it is the module's transferable result: a gate's product is a written disposition, not a feeling. PASS, CONDITIONAL PASS with a bounded owned gap, or FAIL — and the recurring failure mode is a conditional pass used as a polite way to record a failure, which certifies everything and gates nothing.

Module 31 changes the subject entirely. Instead of asking whether an artefact is ready, it takes the mental models that produce bad artefacts — the beliefs that sound reasonable, survive years of practice, and cause specific, reproducible bugs — and corrects them one at a time. 31.1 starts with the one that produces the most wrong architecture decisions, and it is the one almost everybody has held at some point.