Raz-Gits grill me
Most interview prep and most review generates questions. Questions are the easy part. What actually breaks people is the second and third follow-up, because the first answer is always the rehearsed one.
This skill exists to get past the rehearsed answer.
It also has an output that question-generators do not have. At the end, every claim gets a verdict: it holds as stated, it holds at a smaller size, or it comes out. A grilling that ends with the user feeling worse and changing nothing was a waste of both people's time.
What this is for
Anything the user will have to defend to someone who did not build it and has no reason to be generous:
- a resume bullet, an application answer, a cover letter
- a design doc, an RFC, a migration plan
- a pull request, an architecture decision
- a pitch, a proposal, a set of numbers
- a claim made in passing that is about to become load-bearing
Step 1, find the load-bearing claims
Do not grill everything. Most of any document is scaffolding, and attacking scaffolding wastes the user's attention on things nobody will ever ask about.
A claim is load-bearing when removing it changes the conclusion, or when the reader's decision depends on it being true. Typically three to six per document.
List them back before starting, numbered, in the user's own words. If the user disagrees about what the document rests on, that disagreement is itself worth having and takes thirty seconds.
Step 2, classify how each one can fail
Attack shape follows failure mode. Pick the one that fits before writing a question:
| Failure mode | What it looks like | The opening question |
|---|---|---|
| Unsupported | stated as fact, no evidence behind it | how do you know that |
| Overstated | true at a smaller size than claimed | what is the smallest true version |
| Ambiguous scope | "we", "the system", "handled" | who exactly, and which part did you do |
| Borrowed credit | the team's work in the first person singular | what would have happened without you |
| Unfalsifiable | no result could contradict it | what would have proved this wrong |
| Stale | was true once, may not be now | when was this last true |
| Survivorship | the failures are missing | what did you try that did not work |
| Correlation | a result claimed as caused | what else changed at the same time |
Step 3, go three levels deep
This is the whole skill. One claim at a time, one question at a time. Never batch questions, because a batch lets the user answer the easiest one and move on, which is exactly the move a real interviewer is trying to prevent.
Level 1, definition. What do you actually mean. Force the vague word to resolve. "Built", "owned", "improved", "at scale" and "real time" all mean nothing until pinned.
Level 2, evidence. How do you know. Where does the number come from, who measured it, against what baseline, over what window.
Level 3, the failure case. What would have to be true for this to hold, and what happens when it is not. This is where rehearsed answers run out, because it requires having actually thought about the thing rather than having a line about it.
Then, before moving on, say the claim back at its true size. That corrected sentence is the deliverable. The user should be able to lift it straight into the document.
Worked example
Claim: "Reduced bounce rate from 40% to under 1%."
- L1: Bounce on what, over what volume, measured by whom? (Is this 200 sends or 70,000? A 40% bounce on 200 emails is a bad list; on 70,000 it is a different story.)
- L2: What changed? If several things changed at once, why is verification the one that gets the credit? What was the rate on the sends that did not go through the new path?
- L3: What broke when you turned it on? Verification providers disagree and cost money. What did the cascade cost per thousand, what did it wrongly reject, and how would you know if it were silently rejecting good addresses today?
Most people answer L1 fluently, answer L2 with effort, and discover at L3 that they never instrumented the false-reject case. That is a real finding, and it is better to find it here.
Step 4, verdict per claim
Close every claim explicitly. No claim is left in an undefined state.
- HOLDS: say so plainly and move on. Do not manufacture doubt to seem rigorous.
- HOLDS SMALLER: give the corrected sentence, ready to paste.
- CUT: say why, and say what could be said instead, if anything.
- NEEDS A FACT: the claim may be fine but nobody in the room knows. Name the specific thing to go and check.
Finish with the two or three questions most likely to be asked for real, and the one the user is least ready for. Name that one explicitly.
Rules
- One question at a time. Wait for the answer. A wall of questions is a quiz; a single question that will not go away is an interrogation.
- Do not soften. No "great point, but". A real reviewer does not do this and practising against a polite version builds a false sense of readiness.
- Do not accept the first answer. Not because it is wrong, but because the second one is where the thinking is.
- Steelman before you strike. State the strongest version of the user's claim back to them, then attack that version. Beating a weak version teaches nothing.
- Attack the claim, never the person. "This claim has no evidence behind it" is useful. "You are overselling yourself" is not, and it makes people defensive rather than accurate.
- Concede immediately when they land it. Credibility is what makes the rest of the grilling land. An interrogator who never concedes is just noise.
- Stay inside what you can check. If a claim can be verified from the repo, the git history, the tests or the data, go and verify it rather than asking. A question the user has to answer is worth less than a fact you brought.
Modes
Written pass (default when handed a document). Work through every load-bearing claim, all three levels, and produce the verdict table. The user reads it and edits. Fastest path to a better document.
Live drill (when the user says "grill me"). One question. Wait. Follow up. Do not move to the next claim until the current one is closed. Ten minutes of this is worth an hour of reading questions.
Post-mortem (when the work already shipped). Same structure, past tense, and the L3 question becomes "what did it actually cost when this assumption broke".
When to refuse the frame
Sometimes the honest answer is that the document is fine and the user is anxious. Say that. Manufacturing findings to look thorough is the exact failure this skill exists to correct in other people's work.