Blockchain developer roles are strange to interview for. The field is young enough that no two companies run the same process, and many hiring managers are themselves figuring out what “senior blockchain engineer” means. I’ve talked to engineers who cleared interviews at Chainlink, Consensys, and a couple of DeFi protocols, and the pattern I see: depth on smart contract security and gas optimization matters far more than breadth on Web3 trivia.
This guide covers what actually gets asked, roughly organized by the three layers interviewers probe: protocol fundamentals, smart contract engineering, and practical dApp development.
Blockchain fundamentals: the questions candidates underestimate
Most candidates expect fundamentals to be easy warm-up questions. They’re not. At Consensys and similar firms, the fundamentals round is where a lot of mid-level candidates get filtered out, because the questions are deceptively specific.
Questions you should be able to answer cold:
- Explain the difference between proof of work and proof of stake at the validator incentive level, not just the “energy usage” level.
- What’s the difference between the UTXO model (Bitcoin) and the account model (Ethereum), and why does it matter for transaction composability?
- How does Ethereum’s EIP-1559 fee mechanism change miner/validator incentives compared to the old first-price auction?
- What is a Merkle Patricia Trie, and why does Ethereum use one for state storage?
- Explain finality: what’s the difference between probabilistic finality (Bitcoin) and economic finality (Ethereum PoS)?
The Merkle Patricia Trie question trips up a lot of people. You don’t need to implement one from memory, but you should understand that it lets Ethereum efficiently prove state membership and compact storage across nodes. If you can’t explain why that matters for light clients, go read the Ethereum documentation on the topic before your next interview.
Solidity and smart contract questions
This is the core of most blockchain developer interviews at protocol companies. The questions here range from “explain how the EVM stack works” to live coding exercises on Remix or Hardhat. The specific topics that come up most often:
Gas optimization. Interviewers at DeFi protocols will ask you to look at a Solidity snippet and identify where gas is being wasted. Common patterns include unnecessary storage reads inside loops, using uint256 vs. packed struct fields, and event emission costs. If you haven’t spent time on the Solidity optimizer documentation, do that.
Reentrancy vulnerabilities. The DAO hack in 2016 involved reentrancy. Nine years later, interviewers still open with reentrancy questions because it reveals whether you think in terms of the Checks-Effects-Interactions pattern or whether you write code that reads logically but fails in adversarial conditions. Be ready to write a vulnerable contract and then fix it.
Access control patterns. OpenZeppelin’s Ownable and AccessControl modules come up constantly. Know when to use role-based access vs. simple ownership, and understand why multisig wallets matter for production contract administration.
Upgradeable contracts. Proxy patterns (transparent proxy, UUPS) are common in DeFi, and they’re also genuinely confusing. Many candidates claim to know upgradeable contracts but can’t explain storage collision risks between proxy and implementation contracts.
Web3 and dApp integration
For front-end-leaning blockchain roles, expect questions on wallet integration (ethers.js vs. web3.js vs. viem in 2026), handling transaction state in the UI (pending, confirmed, failed), and dealing with RPC rate limits from Infura or Alchemy.
Layer 2 questions are increasingly common. Know the difference between optimistic rollups (Optimism, Arbitrum) and ZK rollups (zkSync, StarkNet) at a conceptual level. You don’t need to have deployed on all of them, but you should understand the fraud proof vs. validity proof distinction and why it affects finality time.
MEV (maximal extractable value) questions show up more at DeFi protocol interviews than at enterprise blockchain shops. If the role involves protocol economics, expect a question like: “How would you protect a protocol’s users from sandwich attacks?”
Security questions that separate strong candidates
Beyond reentrancy, interviewers at security-focused companies ask about:
- Oracle manipulation attacks and how protocols like Chainlink’s price feeds or Uniswap TWAP oracles mitigate them
- Integer overflow before Solidity 0.8 (automatic revert after 0.8, SafeMath before)
- Front-running and commit-reveal schemes as a mitigation
- Flash loan attack mechanics, not the “how to use a flash loan” angle but “how an attacker uses one to manipulate a protocol’s state in a single transaction”
I don’t have solid data on what percentage of blockchain developer interviews include a live security audit exercise, but from the conversations I’ve had, it’s common enough that you should practice reading unfamiliar Solidity code and narrating potential vulnerabilities out loud.
What interviewers say they actually want
According to LinkedIn’s Economic Graph research, blockchain-related job postings have fluctuated significantly with market cycles, but the skills that persist across cycles (security, protocol architecture, cross-chain interoperability) are the ones that matter for long-term career positioning.
The engineers who do well in these interviews share one quality: they treat blockchain as a constrained execution environment with specific adversarial properties, not as a buzzword stack. If your answers reference economic incentives, gas costs, and failure modes rather than just “decentralization is good,” you’ll stand out from candidates who learned Web3 as a career pivot without digging into the underlying mechanics.
One more thing worth knowing: most blockchain developer interviews will ask you to review code that has bugs in it. Not write perfect code from scratch, review someone else’s flawed code. Practice that more than you practice whiteboard problems.