Blockchain Developer interview loops

This page takes a blockchain developer to be a Solidity engineer on Ethereum or on a chain that runs the same virtual machine: someone who writes the contracts, writes the tests that are the only rehearsal those contracts get, and keeps the services that read from the chain and send to it honest. 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.

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.