Role: Blockchain Developer, EVM smart contractsFull interview loop

For a team whose contracts already hold user funds on Ethereum or an EVM rollup, hiring a developer who will write those contracts, change them after launch, and be among the people woken when they are attacked. It assumes Solidity and Foundry-style tests, and that the hire also works on the services that read the chain and send transactions to it — though that is where it asks least.

Each round takes one kind of work from an ordinary year in the job and hands over what that work looks like on the day. The coding test is a vault with four planted flaws and a test suite that passes. The code review is an upgrade that would be correct as a new contract and is wrong as a change to a deployed one. The system design interview is a working deposit and payout pipeline that credits blocks it should not yet trust and keeps its signing key in an environment variable. The scenario is an incident pack at 03:11, with a lending market being drained through its price oracle and two signers awake.

Contract security is read three times because it comes in three forms a candidate can be good at separately: flaws in fresh code, flaws that exist only in the move from one version to the next, and an economic flaw worked out from transaction traces. The other must-haves are read twice, from different sides. Testing is first a fuzzing handler that has to include a hostile contract, then an upgrade replayed against the state already on chain. Upgrades and key custody is first the key that can change a contract, then the key that can empty a treasury. Incident response is first a flaw nobody has used yet, where the danger is what the team's own fix reveals, then a flaw someone is using right now.

Four must-haves is a lot for four rounds, and it is deliberate. A developer who writes careful code but has never asked who holds the upgrade key, or who tests thoroughly but freezes while funds are leaving, is a risk a team holding user funds cannot absorb the way a web team absorbs a bad deploy. The price is paid in off-chain integration, the one nice-to-have, read once: this loop will prefer a strong contract developer who has never run an indexer over a strong indexer engineer who cannot find a reentrancy. If your blockchain developer will mostly build wallet infrastructure, indexers or exchange integrations, that is the wrong trade — make off-chain integration a must and give it a second read, such as a coding round on the deposit watcher's handling of reorganisations.

If your contracts are deliberately immutable, keep the second round and change its pull request to a migration onto a new contract. The storage-layout question goes away; testing a change against deployed state, and deciding who holds the keys for the move, do not.