Blockchain Developer interview loops
How to interview a blockchain developer whose contracts hold funds: the competencies to hire on, and a loop built on vulnerable code and a live exploit.
A blockchain developer is a software engineer who writes or reviews smart contracts, the programs that run on a blockchain such as Ethereum, or builds the software that reads from the chain and sends transactions to it. The introduction to smart contracts on ethereum.org (updated February 2026) describes a contract as code and data kept at an address of its own, which accounts use by sending it transactions, and notes that by default a contract cannot be deleted and a transaction with it cannot be reversed. Employers' own postings read in October 2026 advertise the contract work as smart contract engineer (Uniswap Labs), blockchain engineer (Ondo) or protocol engineer (LayerZero Labs).
As of October 2026 the work comes in three kinds, each advertised under its own title. At a company that builds a protocol it is the contracts themselves: a Uniswap Labs posting has its senior smart contract engineer building the protocol's next version, and wants four years or more of production Solidity from someone who has already put contracts live on Ethereum mainnet (Uniswap Labs). At an exchange it can be the wallet systems that move customers' assets: a Coinbase posting has its senior software engineer on the wallets, liquidity and bridging team writing the Go services that take a transaction on Ethereum, Bitcoin, Solana or another chain from signing through to checking that the chain recorded it (Coinbase). At an audit firm it is reading other teams' contracts before they go live: an OpenZeppelin posting has its blockchain security researcher auditing clients' code and reporting what they find, wants someone who has built contracts as well as audited them, and expects AI tools in every audit. The same posting lists its usual interview stages: a recruiter call, manager and technical interviews, a paid code review as a work trial, and references (OpenZeppelin). The loop below is written for the first kind: contracts that already hold users' funds, on Ethereum or another chain that runs the Ethereum Virtual Machine (EVM), with one round on the services that read the chain and pay out from it.
The contracts in this loop are written in Solidity, and their tests are the only rehearsal they get. The language is not what sets the job apart from other backend work. The code holds other people's money where anyone can call it, and a deployed contract cannot be patched quietly — a bug is fixed by moving the funds, by an upgrade its users have to trust, or not at all.
That changes what an interview has to find out. Vulnerability classes have well-known names, and a candidate can talk fluently about reentrancy, oracle manipulation and signature replay without ever having found one in code they had not seen before, so questions about the names mostly measure preparation. The habits that matter show only when there is something to apply them to: asking who is on the other side of an external call, testing a change against the state that is already deployed, deciding what a key should be unable to do, keeping a flaw quiet until the funds are safe. Each round below therefore hands the candidate something an interviewer prepared with known defects — a vulnerable contract, an upgrade pull request, an architecture sketch, an incident pack. Teams on a chain that does not run the EVM can keep each round's shape and rebuild its artifact. The defects planted here are specific to Solidity and the EVM; the questions underneath them — who controls what, which state already exists, what must still be true after every call — are not.
Employers draw the line on AI in the interview in different places. Anthropic asks candidates to do take-home assessments and live interviews without it unless told otherwise (Anthropic, updated July 2025), while Canva wrote in June 2025 that it expects backend, frontend and machine learning candidates to use AI coding tools in its technical interviews, and that it assesses whether they can find and fix what those tools get wrong (Canva). None of the plans below says either way, and none sends anything ahead: each hands its material over at the start of the hour. Every round opens on what the candidate finds in that material before anyone points to it — the vault's planted flaws, the new variable that pushes every later one down a slot, the deposit watcher's cursor that skips a failed read, the markets still open to borrowing against the manipulated token — and an assistant given the same material could point to it for them. Two sections are mostly code the candidate writes, which would become code they direct and check: the coding test's failing test, fix and invariant test, and the code review's test that replays the upgrade against the deployed proxy. The coding test's tell, a handler with a contract that calls back into the vault, would then say less about whether the candidate thought of it. In the exploit scenario, an assistant given the traces could rebuild the attack and put a number on the bad debt. What is left is argued aloud under follow-up questions: what to do first about a live vault nobody else knows is broken, who may ship an upgrade and how fast, how large the hot wallet should be, who carries the bad debt. Decide before the first round, and tell the candidate which rounds, and which parts of each, an assistant may be used in.
A loop is a set of round plans in order. Each round scores one to three competencies, every must-have is scored in at least two rounds by different interviewers, and the debrief goes competency by competency, so no single conversation decides the hire. How these plans work covers the rest of the method.
Further reading, as of October 2026. The Solidity documentation's Security Considerations shows a withdraw function that pays out before it zeroes the caller's balance, the order the vault in the smart contract coding test gets wrong, and fixes it by writing every change to the contract's own state before calling anything else. OpenZeppelin's page on the proxy upgrade pattern explains that nothing in a proxy stops a new version from putting a variable in a slot the old version used for something else, so a new version should only add variables after the old ones; the pull request in the code review inserts one in the middle. The OP Stack's documentation on transaction finality, written for one family of optimistic rollups, separates a block the sequencer has produced from one whose data is on Ethereum and one Ethereum has finalized, advises any service acting on a transaction to wait at least for the second, and says the seven-day delay applies to withdrawals through the rollup's standard bridge to Ethereum rather than to finality: the distinctions the system design interview asks for before a deposit is credited. Once the markets are paused, a candidate in the exploit scenario is credited for privately calling a security incident response group; the Security Alliance's SEAL 911 is one, and says it is free, answers at any hour and puts callers in touch with security researchers it has vetted.
Interview loops
| Interview loop | Rounds | Time | Must-haves |
|---|---|---|---|
| Blockchain Developer, EVM smart contracts | 4 | 4 h | Contract security, Testing and verification, Upgrades and key custody, Incident response |
What each loop scores
How many rounds of each loop score a competency, and whether the loop treats it as a must-have or a nice-to-have.
| Competency | Blockchain Developer, EVM smart contracts |
|---|---|
| Contract security | Must-have · 3 rounds |
| Testing and verification | Must-have · 2 rounds |
| Upgrades and key custody | Must-have · 2 rounds |
| Incident response | Must-have · 2 rounds |
| Off-chain integration | Nice-to-have · 1 round |