Blockchain Developer Interview Questions 2026

Last updated: September 24, 2026

By Tom Kenaley, President and Senior Partner, KORE1

The best blockchain developer interview questions put real contract code in front of the candidate and ask who can change it, where money could leave, and which textbook answers stopped being true after Ethereum’s 2025 Pectra upgrade. Save definitions of consensus and hashing for a recruiter call. The hour you actually get with a finalist should go to code that holds funds.

Here is a line I still find in take-home submissions.

require(tx.origin == msg.sender, "no contracts");

Ask a candidate what it does and nearly every one of them will tell you it keeps other contracts from calling the function. For most of Ethereum’s history that was roughly right, if crude. Pectra changed it. That network upgrade went live on Ethereum mainnet on May 7, 2025, and brought EIP-7702 with it. That proposal lets an ordinary wallet account point at contract code and run it. The EIP’s own security section warns that it can “break reentrancy guards of the style require(tx.origin == msg.sender).” So the line still tells you a person’s wallet started the transaction. It no longer tells you that nothing else is running.

This question sorts a room fast. A few candidates know about 7702 cold and explain the change in two sentences. More of them don’t know, but get there once you mention it, which is a fine result and tells you they can reason. The group that worries me defends the line. They learned Solidity from a tutorial in 2021 and haven’t needed to look since, and in a field where a missed protocol change can empty a treasury, that habit is the actual thing you’re screening for.

KORE1 bills only when one of our candidates signs an offer. That’s the whole conflict of interest, and it doesn’t touch a single question below. Most of them work fine on candidates you sourced yourself. Many clients do exactly that. When a client does want help, the search runs through the blockchain developer staffing team, one of the specialty desks in our IT staffing group.

Two things are left out on purpose. Checking a candidate’s on-chain history before the first call, the mainnet addresses and audit reports and contest results, is laid out step by step in the verification section of our 2026 how-to-hire guide for blockchain engineers. The classic reentrancy spot check and gas-optimization round are in our Solidity and Web3 hiring guide. What follows picks up after those, once the candidate is actually sitting across from you.

The Answer Key Changed in May 2025

Search this topic and you get lists. Thirty questions, forty, a practice test on Udemy with more than 1,400 of them. What is a Merkle tree. Proof of work versus proof of stake. Name the types of blockchain.

The questions aren’t wrong. The trouble is that the answers printed under them age, and in this field they age quickly. The platforms kept shipping upgrades while the prep sites kept reprinting. Nobody went back. I keep a short list of the ones I check most often.

I’d frame the bottom row and hang it in every interview room. Most interview loops we see spend their only code round on reentrancy. It’s the famous bug. The DAO, 2016, with a clean textbook fix every candidate has rehearsed. The OWASP Smart Contract Top 10 for 2026, built from 122 incidents and roughly $905 million in losses during 2025, puts it eighth. Access control is first. Business logic is second. Oracle manipulation and flash-loan attacks follow, and proxy and upgradeability flaws round out the list at tenth, which is worth pausing on, since an upgrade path is exactly where a small access-control mistake becomes a total loss.

I’m not telling you to skip reentrancy. A candidate who spots it in ninety seconds has shown you they read the same material as everyone else. They did their homework. Now spend the rest of the hour where the money is actually going.

Put a Contract on the Table, Not a Definition

Every question in this section works best with 40 to 80 lines of real Solidity in front of the candidate, sent over a day early. I’ll get to format later. For each one I’ve written down why I ask it and what I’ve learned to listen for, which is rarely what the candidate assumes.

Who can upgrade this contract today, and how long would it take them?

I ask this one first. Every level, juniors included.

A strong answer is boring and specific. The proxy admin is a 3-of-5 Safe. Two of the signers keep hardware keys in different cities. Upgrades wait behind a 48-hour timelock, and the one function that skips the timelock is pause(), which can stop deposits but can’t move anything. Good candidates also know whether initialize() can still be called on the implementation contract, and why people started asking. Parity’s shared multisig library sat uninitialized in 2017 until a user claimed ownership of it and triggered its self-destruct, which froze the funds in every wallet built on that library. That ETH is still stuck.

Last spring we had a finalist for a stablecoin payments company in Austin who was genuinely good. Tidy Foundry tests, sensible gas choices, easy to talk to. When the hiring manager asked who could upgrade the settlement contract he’d built at his previous job, he said, “Me, from my laptop.” He offered it as a credential. The panel heard it differently. They were right.

You’re adding one field to version two of this vault. Where does it go?

Storage layout separates people who have shipped an upgrade from people who have read about one. Behind a proxy, the implementation’s variables map to fixed slots in the proxy’s storage. Insert a variable in the middle, swap two, or change the inheritance order, and version two reads version one’s data from the wrong slots. Nothing reverts. Fresh-deploy tests still pass. Balances just quietly turn into somebody else’s balances.

Listen first for the append-only rule, then for what they say about inheritance, because that’s where most of the collisions I’ve heard about actually came from. Anyone on current tooling should bring up that OpenZeppelin Contracts 5.0 replaced the old __gap arrays with ERC-7201 namespaced storage, where each contract keeps its state in its own struct at a computed location. The sharp ones add, unprompted, that a live 4.x deployment can’t just be pointed at 5.x code, since its state sits in different slots. If they mention running a layout check in CI, with the OpenZeppelin Upgrades plugin or by diffing forge inspect output across versions, you are probably talking to someone who has been burned, or who sat next to someone who was. I’ve hired both kinds.

The first deposit into this vault is one wei. What happens to the second depositor?

It’s the ERC-4626 inflation attack, sometimes called the donation attack, and I like it because no single line is wrong. An attacker makes the first deposit. One wei, one share. Then comes the donation, a big transfer of the underlying token straight to the vault’s address with no deposit call at all, and that lonely share is suddenly worth whatever they sent. Somebody deposits $10,000 next. The math divides it by that absurd share price and rounds down to zero shares. Their money is in the vault. None of it is theirs anymore. Someone who has built vaults will walk through that and then start arguing about fixes, whether to seed the vault with a dead deposit or rely on the virtual shares and decimal offset OpenZeppelin added in version 4.9, and which direction each conversion should round. Rounding has its own spot on the OWASP list now, seventh, under arithmetic errors. Good candidates round against the user, always, and can tell you why in a sentence. Weak ones shrug.

Your reentrancy lock uses transient storage now. What did you trade for the cheaper gas?

Some background first. EIP-1153 gave the EVM transient storage in the Dencun upgrade in March 2024, and Solidity 0.8.28 added full support for transient state variables of value types that October. Locks got far cheaper. The EIP-7702 authors even point to transient storage as the better replacement for tx.origin guards.

The catch is lifetime. A transient value lasts for the whole transaction, not the single call, so a lock that isn’t cleared on the way out stays set for everything else in that transaction, and a router or batched call that touches your contract twice starts failing in ways that look random. The opposite mistake is quieter. Reuse a transient slot for anything besides the lock, and state can leak from one call into the next inside the same transaction. I want to hear where the lock gets cleared, and what they think happens to it inside a multicall.

Which compiler version is this pinned to, and why that one?

People smile at this one until I bring up July 30, 2023. That day attackers drained several Curve pools written in Vyper, and the Vyper team traced it to the compiler. What went wrong was mundane. In versions 0.2.15, 0.2.16, and 0.3.0 the compiler handed each function its own reentrancy lock slot, so a lock on remove_liquidity() never stopped anybody from calling back into add_liquidity() halfway through. The source code was correct. Auditors had read correct source code. The bytecode was the problem.

Pinning is the minimum. A good answer names an exact version rather than a floating ^0.8 pragma and gives a reason for it, usually a feature or a bug fix. Better candidates know the Solidity team publishes a list of known compiler bugs by version, and they’ve looked at it. “Whatever Foundry defaulted to” is a fine answer at a hackathon. For a vault, no.

Questions for Anyone Who Will Hold a Signing Key

Not every blockchain developer writes the treasury contracts. Most senior ones end up holding a key to them, though, and on February 21, 2025, that responsibility got a lot heavier.

That’s the day Bybit lost about $1.5 billion, a theft the FBI attributed to North Korean operators it tracks as TraderTraitor. The total isn’t the lesson. The mechanics are. According to Sygnia’s investigation, a developer’s workstation at Safe{Wallet} was compromised in early February, and the attackers used that access to plant malicious JavaScript in the web interface Bybit’s signers relied on. The screen showed a routine transaction. What the signers actually approved had its operation field set to delegatecall, aimed at a contract the attacker had deployed in advance. A delegatecall runs another contract’s code against your wallet’s own storage. That code swapped out the wallet’s implementation, and from then on the wallet answered to someone else.

Hardware wallets didn’t stop it. Neither did the signing threshold. Enough people signed.

Before you sign a Safe transaction, what do you check that the screen can’t fake?

I want the candidate talking about raw fields. To, value, data, operation, nonce. Do they decode the calldata somewhere other than the interface that proposed it? Do they compute the transaction hash independently and compare it with what the hardware device shows, and will they refuse to sign when the device can’t show them anything readable? Operation should come up by name. If it’s 1 instead of 0, that’s a delegatecall, and the next thing out of their mouth should be “into what?”

A custody team at a fintech in Charlotte rebuilt its loop around this after Bybit. Their panel now puts the fields of a real queued transaction in front of finalists, with the addresses swapped, and asks which field decides whether the wallet survives. Solidity veterans have missed it. A backend engineer who came from a card-payments processor caught it in about a minute, mostly because he had spent a decade not believing what dashboards told him. He got the offer.

Money is leaving a contract you wrote. What happens in the first ten minutes?

The answer I’m hoping for sounds like a phone tree. I want names. Who holds the pause role, and is it a multisig whose signers are asleep in three time zones? Can the contract be paused at all, or did somebody decide in a design review that pausing was too centralized? Where do the alerts come from, and who gets paged first? People who have lived through an incident also bring up the mistakes that happen under pressure, like shipping a rushed fix with its own bug, or broadcasting a rescue transaction to the public mempool where a bot copies it and gets there first.

“We’d put out a statement” is not an answer. It’s a press release.

Solana Candidates Fail Different Questions

Everything above assumes the EVM. Solana shifts the failure modes enough that I’d run a separate set of questions, and I say that having watched excellent Solidity engineers stumble on it.

The core difference is where trust sits. An Ethereum contract owns its storage. Solana flips that. A Solana program gets handed a list of accounts by whoever calls it, and confirming that each one is what it claims to be is the program’s job, which means checking that it’s owned by the right program, signed where a signature is required, and derived from the right seeds. Skip one check and the caller gets to supply an account of their own design.

This instruction takes six accounts. Which ones did you verify, and how?

This is the Wormhole exploit turned into a question. In February 2022 the bridge’s signature check on Solana leaned on a deprecated helper, load_instruction_at, that never confirmed the account passed in was the real Instructions sysvar. The attacker forged one. The program treated signature verification as done when it hadn’t happened, and 120,000 wrapped ETH was minted from nothing, worth more than $320 million at the time. The fix was the checked version of the same function.

Strong candidates walk the account list line by line. Owner, signer, PDA seeds and the canonical bump, and the discriminator that Anchor verifies for you when an account is typed as Account but not when it’s an UncheckedAccount. They can say why every UncheckedAccount in their code carries a CHECK comment explaining itself. Ask to see one. After that I ask whether overflow-checks is turned on in their release profile. Rust wraps integers silently in release builds unless it is, which surprises a lot of people who assume Rust always catches overflow.

We had a senior EVM engineer in a Denver final round last year who cruised through the Solidity half and then missed an owner check in the Solana exercise. Twice. The client hired him anyway, for the EVM seat, and filled the Solana role separately about six weeks later. Good call. Our Rust developer interview questions cover the language itself, ownership, lifetimes, and unsafe code, which a Solana loop needs underneath all of this, and the Rust developer staffing desk runs those searches.

The Application Seat Gets Its Own Loop

Our hiring guide makes a point I’ll repeat because it changes the interview. Plenty of reqs titled “blockchain developer” describe someone who reads from a chain and never writes a contract. Wallet integrations, payment flows, the indexer that feeds your ledger, the reconciliation job that runs at midnight. It’s backend work. The failure modes are just stranger. Hand this person a storage-layout question and you’ve wasted two afternoons, theirs and yours.

What I’d ask instead:

• A deposit shows up in the latest block. When do you credit the customer? It depends on the chain, and a candidate who gives one number for every chain has told you something. On Ethereum they should know the difference between the latest, safe, and finalized block tags in the JSON-RPC API, and that finality takes about two epochs, a little under 13 minutes. On an optimistic rollup, they should separate the sequencer’s quick confirmation from settlement and know why withdrawals back to mainnet take about a week.
• Two transactions from your hot wallet are stuck behind a third that won’t confirm. Nonces, basically. Replace that third transaction at the same nonce with a higher fee, or send a zero-value transaction to yourself to clear it. Engineers from payments companies get this faster than you’d expect.
• What breaks at 2 a.m. when your only RPC provider starts rate-limiting you? Good candidates keep a second provider.
• Anyone building an indexer should talk about reorgs without being asked. An event they stored can vanish when a block gets replaced, and the indexer has to notice and roll back instead of keeping a deposit that never happened.

This seat pays closer to a strong backend engineer than to a smart-contract specialist, and the blockchain developer salary guide shows how far apart those two bands sit.

Auditors and Protocol Engineers, Briefly

Two seats, much smaller pools, and I’ll keep this short because each interview is mostly a conversation about the candidate’s published work.

For a security or audit hire, I hand over three findings from a real public report with the severities removed and ask for a ranking, with reasons. Then I ask about a finding they submitted that the judges downgraded, and whether the judges got it right. People who can say “they were right, I overstated the impact” are rarer than you’d think and worth a great deal. That bench overlaps with our cybersecurity staffing work more than most clients expect.

Protocol engineers get an incident too. A few hours after Ethereum’s Fusaka upgrade activated in early December 2025, a bug in the Prysm consensus client, set off by attestations from out-of-sync nodes, sent Prysm nodes into expensive state recomputation. Network participation dropped as low as 75 percent, and 248 blocks went missing across the 42 affected epochs, according to Prysm’s own post-mortem. Finality needs two-thirds. Ethereum kept it because enough validators ran other clients. So I ask what they would have been watching that night, and what they think client diversity is actually worth. You want someone who answers in numbers. Vague answers don’t count.

Zero-knowledge engineers are their own world. One question does most of the work. Show them a small circuit and ask where it’s under-constrained, meaning where a prover could satisfy every constraint with a value the designer never meant to allow. The few people who do this well answer slowly, which is the right speed.

Scoring the Answers

Panels drift without a rubric. Someone liked the candidate’s energy, someone else preferred last Tuesday’s candidate, and three weeks later nobody can reconstruct why the offer went where it went. Here’s the sheet I’d hand them.

The right-hand column leaves one thing out on purpose. “Hadn’t heard of EIP-7702” isn’t there. Not knowing one proposal is fixable in an afternoon. Defending the old answer after you’ve explained the new one is a different problem, and it doesn’t fix itself.

A Three-Hour Loop That Covers It

The format that has worked best for our clients fits in one afternoon, and it’s short on purpose. Across our IT desks, the average search closes in 17 days, and good blockchain candidates rarely give anyone longer than that. They notice slow loops. One that sprawls over three weeks tends to lose them to the company that booked a single afternoon.

• Half an hour with the hiring manager, no code at all. The signing question and the incident question both fit here, and they tell you more about judgment than anything else in the day.
• The code round runs about 75 minutes on a contract the candidate received the day before. Sixty to eighty lines. We plant three problems from different categories (an access-control gap, a storage-layout trap, and a rounding bug), and none of them is reentrancy. When they find the first one, watch whether they keep reading.
• Then design, roughly 45 minutes. How would they ship version two, who holds the keys, how long is the timelock? For a Solana seat, the account list.
• Whatever time is left belongs to the candidate. The strong ones ask who can stop a deploy and when the last audit happened. Some ask nothing. Write that down.

Who grades the code round matters more than which questions you pick. A client in Irvine learned that when their only reviewer, a Java architect, scored a finalist highly for clean naming and never noticed that his version-two contract shifted every storage slot by one. They hired him. Their external auditor caught the same habit in production code four months later. If nobody on your side writes production Solidity, borrow someone for the afternoon, an auditor on a short engagement or a senior engineer from a portfolio company, and have them score on their own before anyone compares notes. We fill a lot of these seats as contract-to-hire for a related reason, since three months of real work settles what three hours can only estimate. Long-term protocol owners usually go direct hire. Either way, our twelve-month retention sits at 92 percent, and a loop like this one is part of how it stays there.

Loose Ends From Hiring Managers

Which of these questions can a candidate with no crypto background answer well?

The application-seat and incident questions, usually, because finality, stuck transactions, and on-call judgment carry over from payments, trading, and banking systems.

Contract questions don’t transfer. Storage layout, vault rounding, and delegatecall aren’t things you reason your way into on the spot, and a smart backend engineer who tries will often sound confident and be wrong. Hire that person for the application seat and let them grow into the rest.

Should the code-round contract go out before the interview?

24 hours ahead is what we recommend, since reading unfamiliar Solidity cold with a clock running measures nerves more than judgment.

Nobody reads a new codebase cold on the job. Send the file, say roughly what it’s supposed to do, and say nothing about the bugs. Some candidates will find all three before they walk in. Let them. The interview is really the conversation about what they found.

Is it fair to ask about exploits from 2022 and 2023?

Fair, as long as the mechanism behind the exploit could still appear in your own code, and unverified accounts and unexamined compiler versions are still everywhere.

What I’d avoid is trivia. Asking for the dollar figure on a 2022 hack tests memory. Asking how the same class of bug would appear in the contract on the screen tests the job.

We build on Base, not Ethereum mainnet. Does anything here change?

Most of the contract questions carry over unchanged because Base runs the EVM, but add questions on sequencer downtime, bridge withdrawals, and what “final” means on a rollup.

Base is built on the OP Stack, which makes it an optimistic rollup, and the week-long withdrawal window back to mainnet shapes product decisions more than people expect. Ask what their app should do if the sequencer stops producing blocks for an hour. No single answer wins here, but several lose, and you’ll recognize those when you hear them.

What does a blockchain developer cost once we find the right one?

Plan on something like $125,000 to $170,000 base for a mid-level smart-contract developer, and $175,000 to $230,000 once you’re hiring a senior protocol or smart-contract engineer.

Security and audit engineers sit at $180,000 to $260,000. Tokens muddy the rest. At crypto-native employers a grant can push total compensation well past any of those figures. Application-tier developers price closer to backend engineers. The full breakdown, contract rates included, is in our 2026 blockchain developer pay benchmarks, and you can run a proposed band through our salary benchmark assistant for your metro before finance sees it.

How many people should grade the code round?

Two people scoring separately, one who writes production contracts and one who has signed or reviewed a real mainnet deployment.

They’ll disagree more than you’d guess. That’s the useful part. One tends to reward elegant code, and the other keeps asking what happens when it breaks.

Date the Answer

If I could keep one habit from all of this, it would be asking every candidate when they last changed their mind about something in this field, and what changed it. The good ones have a date ready. Pectra, for some of them. OpenZeppelin 5 for others. Bybit, for nearly everyone who holds a key. The weak ones can’t come up with anything, and in a field that rewrites its own rules every year or so, that silence worries me more than any wrong answer. Whether a new hire will be one of those key holders belongs in the posting too, and our job description template for blockchain developers shows where to say it.

If you’d like help running the search, or just want someone to look over your code-round contract before it goes out, get in touch with our team. KORE1 opened in 2005 and recruits in 30-plus U.S. metros today, and our Web3 and smart-contract recruiting team has sat in on a lot of these loops.