Day-Of Tactics

Pre-loop checklist (week of)

• Re-skim Solidity fundamentals. Storage layout, calldata vs memory, custom errors, immutable vs constant, transient storage. See chapter 03.
• Refresh Foundry. Make sure you can write a test, run a fuzz, snapshot gas, and inspect storage without thinking. See chapter 10.
• Mentally walk a liquidation. Out loud, end to end: oracle update → bot detects → flash-loan-funded liquidator → repay + seize → swap collateral back → keep spread. See chapter 04.
• Review notes on the protocol you're interviewing at. Read their docs and one or two of their core contracts. Form an opinion about a design choice. Don't memorize their code — read carefully, take notes on what surprised you, prepare a thoughtful question.
• Re-read your own résumé. Be ready to talk concretely about any project you list. If you mention something, you own the follow-ups.
• Drill chapter 15. With drill mode on. Aim for 60-second answers in your own words.

Night before

• Don't cram new material. Re-skim what you already know.
• Re-read chapter 02 if the loop is going to test a side of you that's thin. The "specific language" table is what you actually need.
• Re-read this chapter — yes, in advance.
• Set up your physical space: water, second monitor if doing live coding, IDE ready with Foundry, charged headset.
• Eat something. Sleep is more valuable than the last hour of prep.

Morning of

• Re-read this chapter cover to cover.
• Re-skim chapter 15 for the question shapes.
• Open one tab to your résumé, one to the company's docs.
• Test your IDE: open forge init, run forge test on a hello-world, confirm everything works.
• Five minutes before the loop: stand up, walk around, breathe. Sit down. Camera, mic, light. Smile.

Structural moves: design rounds

The most important rounds at this level. Lead them rather than waiting to be led.

1. Clarify the problem. 90 seconds. "Let me make sure I understand: we want X, with constraints Y, optimizing for Z. Is that right? Anything I'm missing?" Get explicit agreement. Surfaces hidden constraints early.
2. State invariants. Before any code or state. "The invariants this system must satisfy are: [list]." This is the senior reflex that distinguishes "can design protocols" from "can write contracts."
3. State storage / state. "Given those invariants, the state I need is: [structs, mappings, accumulators]." Write it on the whiteboard or in the doc.
4. Enumerate transitions. "The transitions are: [list of external functions]. For each, the invariants check looks like…"
5. Adversarial. "Now — what can go wrong? An attacker controls X, Y, Z. The vectors I'd worry about are: [list]. For each, the defense is: [list]."
6. Trade-offs. "There are two designs in this region. I picked [X] because [dominant constraint]. The case for [Y] would be [counter-constraint]." Show that you have a position and a reason.
7. Open questions. "Things I'd want to validate further: [list]." Shows humility and rigor.

Structural moves: coding rounds

If they ask you to write Solidity live, the structure that works:

1. Sketch first. "Before I type, let me sketch the interface and storage on the whiteboard / Excalidraw / a comment block." 2-3 minutes outside the IDE.
2. Talk through the happy path. "User calls X with args Y. The function does A, B, C. Returns Z."
3. Then the edge cases. "What if X is zero? What if Y is greater than balance? What if the external call reverts?" List them before coding.
4. Then code. Type slowly. Talk while you type. Use named imports, custom errors, events, SafeERC20 — show the modern style.
5. Test. If you have time, write a quick Foundry test. Even one test demonstrates the muscle.
6. Iterate visibly. When the interviewer points something out, restate what you understood, then change. Don't just silently fix.

Behavioral

The questions cluster:

• "Tell me about a bug you shipped." Have one ready. Walk through: what was the code, what was the bug, how was it found, what was the fix, what changed in process. Emphasize the systemic improvement, not the heroics.
• "Tell me about a disagreement." Show you can hold a position and update. The signal: "I argued for X. The team picked Y. I committed to Y and helped ship it." Not: "I was right and they were wrong."
• "Why this company / protocol?" Have a real answer rooted in their work. "I read your [thing], I noticed [thing], I have an opinion about [thing]."
• "Why are you leaving / why now?" Honest, brief, future-focused. Don't trash your last team.
• "Tell me about a time you did not know something." Strong answers show: how you noticed the gap, how you closed it, what you do now to keep noticing.

Questions to ask them

You will be asked: "What questions do you have for us?" Have five ready, scaled by who you're talking to.

Talking to an engineer

• "Walk me through the last protocol initiative you shipped. Where did the time actually go — research, implementation, audit?"
• "What's the team's longest-standing invariant you still can't prove?"
• "When an external audit lands a 'high' you disagree with, how does that resolve?"
• "What's the team's current biggest unsolved architectural question?"
• "What does the on-call look like? When was your last incident?"

Talking to a hiring manager

• "What would make a hire successful in the first 4 months?"
• "How does the team decide what to ship next?"
• "How does compensation evolve as TVL grows?"
• "What's the team's relationship with the auditor partners look like?"

Talking to a founder

• "What does the protocol look like in two years if everything goes right?"
• "What's the part of the roadmap you're least confident about?"
• "What's a bet on protocol design you've made that's contrarian today?"

You do not need to ask all of these. Two or three thoughtful ones per round is enough. The signal is that you've been thinking about the role as a peer, not as a candidate.

Closing the loop

End each round well:

• Thank them by name. "Thanks, [name] — that was a good conversation."
• Express genuine interest. "Based on this conversation, I'm more excited about the role than before." Only if true.
• Note one specific thing. "Your question about [X] made me realize I want to think more about [Y]." Shows live learning.

After the full loop:

• Send a brief thank-you to the recruiter / coordinator within 24 hours.
• If you noted any open questions during the loop ("I'd want to look up Z"), send a brief follow-up with what you learned. Demonstrates the live-learning posture in writing.
• If you don't hear back in the promised timeframe, follow up cleanly once. Then move on.

When something goes wrong mid-loop

• You don't know the answer. Say so. "I don't know that off the top of my head. My reasoning would be: [reasoning]. I'd verify before shipping." This is a strength, not a weakness — at this seniority.
• You give a wrong answer and realize mid-sentence. Catch yourself. "Actually wait — that's not right. Let me restate. [Correct version]." Visibly self-correcting reads as senior.
• The interviewer corrects you. Absorb it. "Right — so if I update on that, my answer becomes: [new]. Does the original concern still apply, or does it dissolve?"
• You're stumped on a coding problem. Step back, reframe. "The constraint that's biting me is X. Let me solve a simpler version first and add complexity back in." Worst case: ask explicitly for a hint after a real attempt. "I've spent five minutes on this and I'm stuck on the part where [precise blocker]. Is there a direction I'm missing?"
• You blank on a name (a library, an EIP, a protocol). Just describe what it does. "The OZ library that does — I'm blanking on the name — the one that wraps approvals to handle USDT's missing return." The interviewer will fill it in or move on.
• The round was a disaster. It happens. Compose yourself between rounds. The next interviewer doesn't know. Move forward; salvage what you can in the rounds that remain.