Positioning From Scratch
How to interview honestly for a Senior DeFi Protocol Engineer role when one side of your background is thinner than the JD suggests it should be.
Two shapes of candidate
The role is fundamentally bimodal. The JD wants a senior engineer who is fluent in both mechanism-design research and production Solidity. Almost no candidate is equally strong on both. Most fall into one of two shapes:
| Shape | Strength | Gap |
|---|---|---|
| Solidity-heavy | Years of mainnet contracts, EVM intuition, gas optimization, security review fluency. | Light on mechanism-design papers, IRM derivations, formal verification rigor. |
| Research-heavy | Quant / math / CS background, comfortable with proofs, simulation, mechanism design. | Light on production Solidity hours, Foundry workflow, real audit-cycle scars. |
Senior teams know this. They explicitly hire across both shapes. What gets you rejected is not the gap. It is bluffing about the gap.
If you have Solidity but light research background
You have shipped contracts. You can write a non-trivial protocol in Foundry. You have read enough audit reports to recognize patterns. You have not derived an interest-rate-model curve from utility-maximization principles, and the words "Lyapunov function" make you nervous.
What to do:
- Lean into the production rigor. Talk about times you found a bug pre-audit. Talk about gas optimizations that mattered. Talk about deployment hygiene.
- Read three papers cold before the loop. The Aave whitepaper. The Morpho Blue paper. One of the Uniswap v3 oracle papers. You only need to be able to discuss them coherently, not derive them.
- Pre-bake a few "first-principles" derivations. Two utilization-based IRM curves with different kink positions. The math of a constant-product AMM. The math of a Dutch auction. You will be asked to derive one of these; practice the muscle.
- Acknowledge once, redirect cleanly. "I have not derived this kind of IRM from scratch in a research context. My closest reference point is having implemented and reviewed several variants in production. Want me to reason about it from first principles right now?"
Senior protocol teams already have researchers who can derive things. What they often need is the senior who has shipped enough mainnet code to know which clever design will explode in production. Lean into that.
If you have math/CS theory but light mainnet shipping
You have a quantitative degree. You have done formal verification or proof-assistant work. You have read papers. You have not shipped contracts that hold $100M.
What to do:
- Prove you can ship. A small, polished Foundry project — a vault, an AMM, a liquidator — that you can show on GitHub. Even 800 lines of careful code with invariant tests and a Halmos run earns enormous credibility.
- Internalize Solidity at the storage layout / opcode level. Read the Solidity docs. Write five contracts. Run
forge inspect <Contract> storageand read the output. Runcast callagainst a mainnet contract and parse the calldata yourself. - Don't dismiss "production stuff" as engineering chore work. Reentrancy, gas griefing, ERC-20 ambiguity (USDT not returning bool, fee-on-transfer tokens, rebasing tokens) — these are the things that bring down protocols. Treating them as beneath you is fatal.
- Acknowledge once, redirect cleanly. "I have not personally shipped a protocol holding nine-figure TVL. My closest reference point is having built and verified [project], and having reviewed [protocol] in depth. I think about correctness primarily through formal-methods lenses, and I am actively building the production muscle."
Senior teams need people who can derive an invariant and read 600 lines of Solidity carefully. If you can speak credibly in Foundry / Solidity, your research background becomes a force multiplier, not a substitute.
Believe the invite
Senior protocol teams interview a small number of candidates. If you are in the loop, somebody decided your conversation was worth an hour of an expensive engineer's time. They are not testing whether you have years you don't have. They are testing whether you have the reasoning and reflexes to grow into the job. Walk in as if they already know your résumé. Because they do.
Two failure modes to avoid:
- Apology mode. Spending half the interview hedging about your limited X years. They asked. They know. Move on.
- Bluff mode. Claiming experience you do not have. A senior protocol engineer will catch this in two follow-up questions, and you will be done.
Specific language to use
Practiced sentences that handle the awkward moments:
| Moment | Sentence |
|---|---|
| Asked about an unfamiliar primitive | "I haven't worked with X directly. My closest reference point is Y. Want me to reason about X from first principles, or would you rather move on?" |
| Asked about your gap | "You're right, I haven't shipped at that scale. What I have done is [tight specific example]. Here's how I'd close the rest of the gap on the job." |
| Stumped mid-coding round | "Let me step back. The constraint that's biting me is X. Let me reason about the simpler version first and add complexity back in." |
| Interviewer corrects you | "That's right, I was thinking about it wrong. So if I update on that, the design becomes [new design]. Let me walk through whether the original concern still applies." |
| Asked something you guess at | "I think it's X but I'm not certain. The reason I'd guess X is [reasoning]. I would verify before shipping." |
Practice these out loud. They feel different in your mouth than on the page. The goal is for them to sound natural under pressure.
A 7-day prep program for the underprepared side
If you're Solidity-heavy and need to shore up research
- Day 1: Read the Aave whitepaper (v2 or v3). Note every formula.
- Day 2: Read the Morpho Blue paper or equivalent isolated-markets architecture writeup.
- Day 3: Read the Uniswap v3 oracle paper. Derive geometric-mean TWAP from sqrtPriceX96 ticks.
- Day 4: Derive a utilization-kink IRM yourself. Plot it in Python. Compute the bad-debt threshold.
- Day 5: Read two Spearbit / Cantina audit reports cover to cover. Note severity rationale.
- Day 6: Walk through a Certora CVL spec for a vault — even just to read it.
- Day 7: Re-derive everything from memory on a whiteboard.
If you're research-heavy and need to shore up production
- Day 1: Set up Foundry. Write a minimal ERC-20. Run
forge testandforge inspect storage. - Day 2: Implement an ERC-4626 vault. Read the EIP and a reference implementation (Solmate / Solady).
- Day 3: Build a minimal lending market: deposit collateral, borrow, accrue interest, liquidate.
- Day 4: Add a Foundry invariant test suite. Find a bug. Fix it.
- Day 5: Deploy to a local anvil and Sepolia. Verify on Etherscan. Use a Foundry script with
--broadcast. - Day 6: Read two recent post-mortems (Rekt.news has them). Trace what went wrong.
- Day 7: Run
cast callagainst a mainnet lending protocol. Parse the storage layout.
Anti-patterns to avoid
- Name-dropping protocols you have read about but not used. Senior interviewers will ask a follow-up question. If you cannot answer it, you are net worse than if you had not mentioned the protocol at all.
- Claiming "I would just use Certora for that." Unless you have written CVL, do not claim Certora as a tool. "I have read Certora specs and would learn to write them" is fine.
- Hand-waving on rounding. If your answer to "which way should this divide round?" is "doesn't really matter," you have failed the round. The answer is always "in protocol favor" with reasoning. See chapter 08.
- Skipping the adversarial framing. If you finish a design and the interviewer has to ask "and what could go wrong?", you have failed to lead. Always include the adversarial section yourself.
- Reciting a protocol's architecture verbatim. They want to know what you would do, not what Aave did. Reference Aave for grounding, then state your own choice.
Worst case: the gap is real and it shows
Sometimes the gap is too large for this particular role at this particular team. That is fine. A few things to remember:
- You learned a lot in the prep. Even if this loop doesn't land, the next one is closer.
- The protocol community is small. A bad-bluff interview will follow you. An honest interview where you reasoned crisply about your gaps will earn you a recommendation to a team better matched.
- If you reach the end and are not offered, ask for honest feedback. Most senior interviewers will give it.
Senior DeFi protocol roles are scarce. The reputation you build across interviews — even ones you don't win — compounds. Show up as someone whose questions and answers were memorable, and the next loop will be different.