Blockchain Developer interview questions and how to answer them
Blockchain interviews mostly test whether you'd lose someone's money. Expect a code review of a broken contract, questions on how the EVM stores data, and a conversation about how you test code that can't be patched after launch. Here's what each round is checking and how to answer the questions that come up again and again.
What happens in each round
- 1
Recruiter or founder screen
What happens
Which chains and languages you've actually shipped on, whether you've deployed anything real, and whether you understand the team's product well enough to talk about it.
- 2
Smart contract code review
What happens
You're handed a Solidity contract with planted bugs. They watch how you read it: whether you spot reentrancy, missing access control and unsafe external calls, and whether you explain the fix as well as the flaw.
- 3
Take-home or live build
What happens
A small contract plus tests, often in Foundry or Hardhat. They care more about your test suite, your comments on trade-offs and your gas choices than about finishing every feature.
- 4
System design
What happens
How you split logic between on-chain and off-chain parts, how you handle upgrades and admin keys, and how an indexer, a backend and a front end fit around the contracts.
- 5
Team and values conversation
What happens
How you behave during an incident, how you take audit feedback, and whether you'd push back on a launch date when the code isn't ready.
Questions you're likely to get
1.Walk me through a reentrancy attack and how you'd prevent it.
Why they ask
It's the classic contract bug, and how you explain it shows whether you understand execution order on the EVM or just memorised a pattern.
How to answer
- Describe the flow: a contract sends funds or calls out before updating its own state, and the receiver calls back in
- Name checks-effects-interactions as the first defence
- Mention a reentrancy guard such as OpenZeppelin's ReentrancyGuard as a second layer
- Bring up read-only and cross-function reentrancy, where a guard on a single function doesn't protect the rest
2.How does storage work in the EVM, and how does that affect gas?
Why they ask
Storage writes are the most expensive thing most contracts do, and teams want someone who designs around that from the start.
How to answer
- Explain storage slots and how variables are packed into them
- Contrast storage, memory and calldata and when each is cheaper
- Give a concrete change you've made, like packing a struct or caching a storage read in a local variable
- Say where you'd stop optimising because readability matters more
3.How would you make this contract upgradeable, and would you?
Why they ask
Upgrades bring their own bugs and a trust problem, and they want to see you weigh both instead of reaching for a proxy by habit.
How to answer
- Compare transparent proxies, UUPS and the diamond pattern at a high level
- Call out storage layout collisions and initializer mistakes as the usual failures
- Discuss who holds the upgrade key: a multisig, a timelock, or governance
- Say when an immutable contract is the better choice
4.How do you test a smart contract before it goes to mainnet?
Why they ask
You can't hotfix a deployed contract easily, so your testing habits are the main thing standing between the team and a loss.
How to answer
- Unit tests for every function, including the revert paths
- Fuzz tests and invariant tests in Foundry for properties that must always hold
- Fork tests against real mainnet state for integrations with other protocols
- Static analysis with Slither, then an external audit and a testnet deployment
5.What's an oracle, and how can one be manipulated?
Why they ask
Price oracle attacks have drained real protocols, and any DeFi team needs developers who spot the risk in a design review.
How to answer
- Explain that contracts can't read off-chain data, so an oracle brings it in
- Describe manipulating a spot price from a single pool with a flash loan
- Name defences like Chainlink price feeds, time-weighted average prices and sanity checks on staleness
- Mention what your contract should do when the feed looks wrong
6.How would you design the off-chain side of a dapp that shows a user's history?
Why they ask
Most real products need an indexer and an API, and reading everything straight from a node doesn't hold up.
How to answer
- Emit well-designed events from the contracts so the data can be indexed
- Choose between a subgraph on The Graph and your own indexer writing to Postgres
- Handle chain reorganisations and missed blocks
- Keep the front end reading from the index, with the node as a fallback
7.What's front-running, and how do you reduce it in a contract you write?
Why they ask
Anything that trades or auctions is exposed to it, and the fix usually has to be in the design, not bolted on later.
How to answer
- Explain the public mempool and how bots reorder or copy transactions
- Give defences such as slippage limits, deadlines and commit-reveal schemes
- Mention private transaction relays as a user-side option
- Be honest that some value extraction can't be designed away
8.Tell me about a bug you shipped and how you found out.
Why they ask
They want to hear how you own mistakes, and whether you changed your process afterwards.
How to answer
- Pick a real bug, contract or not, and say plainly what went wrong
- Explain how it was caught: a test, a reviewer, a user report, or monitoring
- Describe the fix and who you told
- End with what you now do differently
9.An auditor flags an issue you think isn't real. What do you do?
Why they ask
Audit feedback causes friction, and they need someone who argues with evidence instead of ego.
How to answer
- Read the finding carefully and try to reproduce it with a test
- If you still disagree, write down why, with the test attached
- Accept a cheap fix even when the risk is low
- Keep the conversation in the audit thread so there's a record
10.Product wants to launch next week and you're not confident in the contracts. How do you handle it?
Why they ask
Pressure to ship is constant in crypto, and a developer who folds can cost the company everything.
How to answer
- Name the specific risks, not a general bad feeling
- Offer options: a capped launch, a pause function, a guarded beta, or a short delay
- Put the trade-off in writing to whoever makes the call
- Show that you'd help find a way to launch safely, not just block it
11.Why this protocol, and what would you change about it?
Why they ask
Crypto teams want people who've used the product and read the contracts, not someone applying to every token project.
How to answer
- Show you've used it, read the docs, and looked at the verified contracts
- Point to a design choice you admire and explain why
- Suggest a change with a clear reason, such as a gas cost or a user flow
- Keep the tone curious rather than critical
Mistakes that sink good candidates
Saying you'd skip tests because an audit is planned
Talking about tokens or prices more than about code
Pasting in contract code you can't explain line by line
Brushing off gas cost or security questions as details for later
Need more Blockchain Developer interviews to prep for?
HeroApply applies to Blockchain Developer jobs that match you, every day. 5 jobs are open today.