Day-Of Tactics

Pre-loop checklist

• Sleep. 7 hours minimum.
• Reread 01-the-role and 02-positioning-from-scratch.
• Skim 14-domain-context — incident catalogue and vocab.
• Have a notebook open. Write each panelist's name and a one-line note as the round starts.
• Coffee, water, snack. Sandwich rounds back-to-back; energy drops mid-loop.
• Set up your dev env beforehand if there's a coding round — Foundry pre-installed, your favorite snippets ready.
• If remote: test the screen-share and pasteable code beforehand. Have a backup mic.

Structural moves for "find the bug" rounds

You'll get 30-45 minutes and a contract of 50-300 lines. Talk through what you're doing.

1. Read the spec first. What's this supposed to do? The bug is usually a violation of the stated intent. Skipping this is the most common rookie mistake.
2. List externally-callable functions. Each is a potential attack entry. Name them out loud.
3. For each external function, ask:
   • Who can call it? (anyone, role-gated, permissioned?)
   • Does it make external calls? When in the function body?
   • Does it modify shared state? In what order vs the external call?
   • Does it transfer tokens? Pull or push?
   • Does it read prices / oracles? Could they be manipulated within the call?
   • Does it round? In whose favor?
   • What's the worst input?
4. Model the state. What states can a position/vault/account be in? Are there transitions that bypass checks?
5. Look for asymmetry. Compare deposit vs withdraw, borrow vs repay, mint vs redeem. Bugs hide where one side has a check the other doesn't.
6. Check what's privileged. Every privileged function should be in a short list. If you find a privileged operation reachable through an unprivileged entry, that's your bug.
7. Empty / depleted / max-state. What happens on first call (empty)? Last call (drained)? Max value?
8. Initialize and one-shot. Is there an init function? Can it be replayed? Front-run?
9. Read every line at least once. Don't skip. The 5 lines you skipped are the bug.

Live code-review moves

Similar but you may get a longer PR (a diff, not a snapshot) and be asked to leave review comments.

• Diff-first. Read what changed before what stayed.
• Why this change? Read the PR description. If unclear, ask.
• For each new external surface: apply the find-the-bug checklist.
• For each modified function: what invariants might have broken? Has the test pack been updated?
• For each new state variable: storage layout collision risk? Initialization?
• Compose: does this interact safely with multicall, with pause, with reentrancy guards?
• Leave structured comments: "blocking" vs "non-blocking question" vs "nit." Reviewers who don't distinguish blocking from non-blocking are slow to work with.

CVL / FV live discussion

You may be asked to whiteboard a CVL rule or invariant. The structural moves:

1. State the property in English first. "I want to prove that no method other than admin can decrease totalSupply."
2. Identify what state is involved. Storage slots, ghost variables, hooks.
3. Write the rule. Parametric over method if it's an access-control-style property.
4. Identify likely solver pain points. Non-linear math, unbounded loops, external calls.
5. Name your assumptions. Every require in a rule is an assumption you're accepting; speak them.
6. Discuss what the counterexample would look like. "If this fails, I'd expect the solver to find a method that decreases totalSupply with non-admin caller. The counterexample is a call trace."

What signals seniority: discussing the tradeoffs in summarization, not just writing the rule. "I'd summarize the interest rate function to avoid solver explosion, but I'd want the summary to be sound — over-approximate the rate's range, not under-approximate."

Behavioral mechanics

Three categories you'll definitely hit; have specific stories ready.

"Tell me about a time you found a critical bug"

STAR-ish: Situation (what the protocol did, what you were doing), Task (what you were looking for), Action (the move that found it — talk methodology, not just the bug), Result (impact + lesson). Bonus: name what the bug taught you about your taxonomy.

"Tell me about a time you disagreed with someone in an incident"

Have a story where you took the disagreement seriously and either changed your mind or convinced them with evidence. Avoid stories where you "were just right and they were wrong." Show calibration.

"How do you communicate severity when likelihood is ambiguous?"

Name the rubric. Walk through how you decompose: what's the impact range, what's the precondition set, which set is plausible. Show that you defer to a published rubric (Immunefi / your own published bounty page) rather than ad-hoc judgment, and that you communicate the rationale not just the verdict.

Recovery from a hard question

If you don't know something: "I haven't worked with that directly. My closest reference point is X — want me to reason about your case from first principles?" Then do it. The willingness to reason in front of them under uncertainty is a stronger signal than recall.

Questions to ask them

Have these ready. Pick 2-3 per round, vary by panelist seniority/role.

1. "What's the current state of the CVL spec — how many invariants are proven, where are the gaps you'd want me to address first?"
2. "How is the bug bounty currently triaged — who's on call, what's the initial response SLA, do you have a war-room SOP that's been drilled?"
3. "When was the last external audit, who did it, what were the unfixed findings, what's your bar for retiring a finding?"
4. "What's the relationship with [Certora / Halmos / Kontrol] like — weekly call, on-call solver wrangling, who owns the spec?"
5. "How does the team decide what goes in the audited core vs in periphery? Is there a written rubric?"
6. "What's the team's posture on retroactive bounty payouts and public postmortems? Do you publish by default?"
7. "What's the biggest unsolved security problem on the team right now? Where would a new engineer have most leverage?"
8. "How is security work measured by leadership? What metrics actually drive promotion / impact reviews here?"
9. "What's the relationship between security and protocol R&D — is review pre-merge or post-merge? Does security block ship?"
10. "For someone joining: what's the failure mode of the first 90 days? Where do new engineers typically get stuck?"

Closing statement

At end of the loop, when they ask "anything else?" or "why this role?", have a short clean version of:

• What you saw in the role that genuinely interests you — be specific.
• What you bring that's unusual — the rare combination, not the generic skill.
• An honest acknowledgment of the gap (one sentence) and one sentence on how you'd close it.
• A specific commitment: "In my first 30 days I'd want to ship one invariant landed in the CVL spec and one PR adversarial review per day."

30-60 seconds total. Don't ramble. End with: "I'd like to keep this conversation going. What are the next steps?"

The night before

• Reread this chapter.
• Reread 14 — incident catalogue and vocab.
• Skim 11 — make sure each pattern is fresh.
• Don't drill anything new. Cramming the night before is counterproductive.
• Put away your laptop by 9pm. Sleep matters more than one more pass.
• Tomorrow morning: coffee, breakfast, a walk if possible, reread this chapter only.