Positioning From Scratch
How to interview honestly when your background only covers half of what the role wants. Both starting shapes are real archetypes — each needs different translation work.
Two starting shapes
Almost everyone arriving at a Smart Contract Security Engineer interview comes from one of two backgrounds. You probably already know which one you are:
- Ex-auditor moving in-house. You've audited at a firm (Trail of Bits, OpenZeppelin, Spearbit, Cantina, Zellic, Sigma Prime, ChainSecurity, Halborn) or as an independent. You're great at finding bugs in code you didn't write. You may have done some bounty work. You write reports for a living.
- Ex-protocol engineer moving into security. You've shipped Solidity at a DeFi protocol. You know the codebase from the inside. You may have done internal review or written some Foundry invariants. Formal verification is something you've used, not authored.
Both shapes get hired. Both shapes have an honest gap. The mistake is pretending the gap isn't there.
If you're moving from auditing into in-house
Your strengths:
- Adversarial reflexes are already wired. You read PRs for what could go wrong, not what should.
- You've seen many codebases, so you know the failure-mode taxonomy across protocol types — lending, AMMs, perps, oracles, bridges.
- You can write a vulnerability report that gets fixed.
Your gaps:
- Codebase ownership. An auditor visits a codebase for 2-6 weeks then leaves. An in-house engineer lives in it. The first three months feel uncomfortably slow — you'll think "I should already see this." That's normal.
- Designing attack surface out. Reports flag attack surface; the new muscle is removing it. That means committing periphery contracts, refactoring core, sometimes saying "we shouldn't ship this feature in this shape."
- Living with your decisions. A bad finding in a report gets revised in the next draft. A bad in-house call gets exploited.
- The non-bug-finding work. Bounty triage SOPs, war-room comms, deployment review, periphery contract design — none of these are "find the bug."
You're not transitioning out of finding bugs. You're adding "designing them out" and "operating during them" to the same skill stack. Frame it that way.
If you're moving from protocol engineering into security
Your strengths:
- You know one codebase deeply — far deeper than most auditors ever do.
- You've seen the production failure modes that don't make it into audit reports (deployment slips, oracle outages, governance friction).
- You can ship code, not just review it.
Your gaps:
- Adversarial framing. Builders think "make it work." Security thinks "make it not break." Switching defaults takes practice — you'll catch yourself rationalizing instead of attacking.
- Formal verification fluency. Reading a CVL rule and writing one are different skills. The first ten rules you write will be either trivially true or impossible-to-discharge. You have to live with the SMT solver for a few weeks before fluency clicks.
- Cross-protocol pattern recognition. You may not have seen how the same class of bug appears in three different protocols. Read postmortems aggressively (see 14-domain-context for a starter incident catalogue).
- The audit-firm relationship. You've been the auditee. You haven't been the manager of an audit engagement — scoping, timeline, response handling, fix verification.
You're not transitioning out of building. You're adding the formal and adversarial layers on top of a builder's instinct, which is genuinely rare.
The translation work, made concrete
For each gap, there's a specific piece of evidence you can build in the weeks before the loop. Pick one per gap, do it well, point at it in the loop.
| Gap | Translation artifact |
|---|---|
| Never written a CVL rule | Fork a public DeFi protocol's Certora repo; add one invariant; show the verification report |
| Never run a war room | Write a war-room SOP for an imaginary protocol incident; share it publicly |
| Never managed an audit engagement | Take a friend's small open-source contract and run a self-audit: scope doc, threat model, findings, fix verification |
| Never written a periphery contract | Build a Permit2-style entry point with circuit breaker for a public AMM |
| Never triaged a bounty | Read 20 public Immunefi/Hats reports; write your own severity rationale for each before reading the disclosed verdict |
| Never written security research | Pick a recent postmortem; write a 1500-word breakdown with a runnable PoC repo |
What to actually say in the loop
When the gap question comes — and it will — say something honest and specific. Some patterns that work:
"My audit experience is N years across M engagements. What I haven't done is live with a single codebase as a maintainer. The closest reference point is [X] — I returned to that engagement three times across a year, so I've seen what 'phase 2 of in-house work' looks like from the outside. In my first 90 days here I'd plan to spend the first month mostly reading, not writing — including the prior audit reports, the bounty inbox, and the CVL repo if one exists."
"I've shipped Solidity at [X] for Y years and done some Foundry invariant work. What I haven't done is author Certora specs at depth — I've reviewed them but not maintained the relationship with the Certora team or driven a spec from one invariant to twenty. I've done [the prep artifact] to get hands-on, and I'd expect to lean on the Certora call and the existing spec maintainers for the first weeks while I get fluent."
Notice what's happening in each:
- Acknowledged the gap cleanly, once.
- Anchored to a concrete reference point (real or self-built).
- Showed you've thought about how the first 90 days actually play out.
What not to say
- Don't pretend. "Oh yeah I've used Certora" when you've read a blog post is a one-question disaster. The follow-up is "great, walk me through how you'd express bad-debt freedom as a parametric rule" and you're cooked.
- Don't apologize. Once is acknowledgment; twice is signaling you don't believe you should be there.
- Don't downplay what you do have. "I'm only an auditor" makes everyone uncomfortable. You're a senior auditor; you've found critical bugs; that's load-bearing experience.
- Don't promise things you can't deliver fast. "I'll have the CVL spec to 50 invariants by month 3" is a number you don't have data to support. "I'd aim to get one new invariant landed per week through month 1-2, then push for breadth in month 3" is calibrated.
Building evidence you can point at
If you have 2-4 weeks before the loop, the highest-ROI things are:
- One small CVL spec, written end-to-end. Even if it's on a toy ERC-4626 vault. The act of fighting the solver teaches you what the loop will test.
- One public security research writeup. Pick a recent exploit, build a Foundry PoC that reproduces it, and explain it clearly. Link it from your CV.
- One refined audit report. If you have a private one, ask the client if you can share an excerpt; if not, write a self-audit of a small public contract and publish it.
- One periphery contract. Something small and well-tested — say, a hardened Chainlink oracle wrapper with staleness, deviation, and circuit-breaker checks. Ship it with Foundry tests and CVL invariants.
In the loop, when they say "tell me about a time you...", you have a concrete artifact to point to. That's a 10x stronger answer than narrative recall.
Closing the gap honestly
The candidates who get hired despite gaps tend to share three traits:
- They name the gap before the interviewer has to. It's a posture of ownership; they've already done the hard reflection.
- They have a one-line plan for closing it. Not "I'll learn fast" — a specific reading list, a specific artifact, a specific reference person they'd lean on.
- They show live learning in the loop. When the interviewer corrects them, they visibly absorb and use the correction in the next question. This is the single highest signal a senior engineer can send.
If you can do those three things, the gap question becomes a strength signal rather than a weakness signal — because the rare thing isn't a perfect background; it's a candid one.