Blockchain Developer and Solidity Interview Questions and Answers (2026)

The short answer: blockchain developer interviews, most of them for Ethereum and other EVM chains, test how well you understand the execution environment and how seriously you take security. Expect questions on blockchain fundamentals and consensus, how the EVM works (stack, memory, storage, gas), Solidity specifics (data locations, visibility, msg.sender vs tx.origin, upgradeability, token standards), smart contract vulnerabilities such as reentrancy, access control and oracle manipulation, testing and audits, and gas optimization, often with a code review or a small contract to write. Because deployed contracts are hard to change and hold real value, interviewers weigh your security instincts above clever code.

Blockchain fundamentals

• “What is a blockchain?” A shared, append-only ledger maintained by a network of nodes that agree on its state through a consensus mechanism, so no single party controls it.
• “Proof of work vs proof of stake?” In proof of work, miners compete to solve computational puzzles to propose blocks; in proof of stake, validators lock up (stake) the native token and are chosen to propose and attest to blocks, losing stake for misbehavior. Ethereum uses proof of stake.
• “What’s the difference between a layer 1 and a layer 2?” A layer 1 is the base chain; a layer 2 (such as an optimistic or zero-knowledge rollup) executes transactions off the main chain and posts data or proofs back to it for security, lowering costs.
• “What are externally owned accounts and contract accounts?” EOAs are controlled by private keys and can start transactions; contract accounts are controlled by their code and only act when called.

How the EVM works

“Explain how the EVM executes a contract.”

Ethereum’s documentation describes the EVM as a stack machine with a depth of 1,024 items, where each item is a 256-bit word. During execution it uses memory, a temporary byte array that doesn’t persist between transactions; contracts also have persistent storage, and the EVM has transient storage (via the TSTORE and TLOAD opcodes), which is cleared at the end of each transaction. Every operation costs gas, which limits computation and pays for it.

“Why is storage expensive, and how do you use it efficiently?”

Writing to storage changes the global state every node keeps, so it costs far more gas than memory. Cache storage reads in local variables, pack small variables into the same 32-byte slot, avoid unnecessary writes, and use events for data that doesn’t need to be read on-chain.

Solidity questions

The Solidity documentation describes the language as “an object-oriented, high-level language for implementing smart contracts” designed to target the EVM, and recommends deploying with the latest released version, since only the latest version generally receives security fixes.

• “What’s the difference between storage, memory and calldata?” storage is persistent contract state; memory is temporary and modifiable during a call; calldata is read-only function input data, cheapest for external function parameters.
• “What are view and pure functions?” view reads but doesn’t modify state; pure neither reads nor modifies state.
• “Explain function visibility.” public (callable anywhere, with an automatic getter for state variables), external (callable only from outside), internal (this contract and derived contracts), private (this contract only). Note that private data is still visible on-chain.
• “msg.sender vs tx.origin?” msg.sender is the immediate caller; tx.origin is the EOA that started the transaction. Never use tx.origin for authorization: a malicious contract the user calls can pass that check.
• “How does Solidity handle integer overflow?” Since version 0.8.0, arithmetic reverts on overflow and underflow by default; unchecked blocks turn checks off where you’ve proven they’re safe, to save gas.
• “What are receive and fallback?” receive handles plain ether transfers with empty calldata; fallback handles calls that match no function (and ether transfers if there’s no receive).
• “What are events used for?” Logging data cheaply for off-chain indexing and front ends; contracts can’t read them.
• “How do upgradeable contracts work?” Usually through a proxy that holds the state and delegates calls (delegatecall) to an implementation contract that can be swapped. Discuss storage layout collisions, initializers instead of constructors, and who controls upgrades (ideally a multisig with a timelock).
• “What are ERC-20, ERC-721 and ERC-1155?” Standards for fungible tokens, non-fungible tokens, and multi-token contracts respectively.

Smart contract security questions

“What are the most common smart contract vulnerabilities?”

The OWASP Smart Contract Top 10 (2025) lists:

1. Access control vulnerabilities
2. Price oracle manipulation
3. Logic errors
4. Lack of input validation
5. Reentrancy attacks
6. Unchecked external calls
7. Flash loan attacks
8. Integer overflow and underflow
9. Insecure randomness
10. Denial of service attacks

Be ready to explain any of them with an example and a fix.

“What is a reentrancy attack, and how do you prevent it?”

A contract makes an external call before updating its own state, and the called contract calls back in to repeat the action, for example withdrawing the same balance several times.

// Vulnerable: sends ether before updating the balance
function withdraw() external {
    uint256 amount = balances[msg.sender];
    (bool ok, ) = msg.sender.call{value: amount}("");
    require(ok, "transfer failed");
    balances[msg.sender] = 0;
}

// Fixed: checks-effects-interactions
function withdraw() external {
    uint256 amount = balances[msg.sender];
    require(amount > 0, "nothing to withdraw");
    balances[msg.sender] = 0;               // effect first
    (bool ok, ) = msg.sender.call{value: amount}("");
    require(ok, "transfer failed");         // interaction last
}

Prevent it by following checks-effects-interactions, adding a reentrancy guard where needed, and being careful with any external call, including token callbacks.

Other security questions

• “How do you get randomness on-chain?” Not from block values that validators can influence; use a verifiable randomness service or a commit-reveal scheme.
• “How do you protect against oracle manipulation?” Use decentralized or time-weighted price feeds rather than a single pool’s spot price, and add sanity checks and circuit breakers.
• “How do you design access control?” Role-based permissions, the fewest privileged roles possible, multisig and timelocks for admin actions, and events for every privileged change.

Testing and audit questions

• “How do you test smart contracts?” Unit tests for every function and revert path, fuzz tests with random inputs, invariant tests (properties that must always hold, such as total supply equaling the sum of balances), fork tests against mainnet state, and static analysis. Name the tools you’ve used, such as Foundry or Hardhat, and an analyzer such as Slither.
• “What does an audit involve, and what do you do before one?” Freeze the scope, document the design and assumptions, reach high test coverage, run static analysis, and fix known issues; then auditors review the code manually and with tools, and you fix and re-verify findings. An audit reduces risk; it doesn’t guarantee safety.
• “Tell me about a vulnerability you found or fixed.” Have a real example, from an audit report, a bug bounty, a contest or your own code.

Gas optimization questions

Mention: minimizing storage writes, packing variables, using calldata for external inputs, immutable and constant for fixed values, custom errors instead of long revert strings, avoiding unbounded loops over arrays, and short-circuiting checks. Stress that security and readability come before small gas savings.

Design questions

• “Design a token vesting contract for employees.”
• “Design an escrow between a buyer and a seller with dispute resolution.”
• “How would you build a staking contract with rewards?”

Clarify requirements, define roles and state, walk through the main functions and events, then discuss failure cases: reentrancy, rounding, admin powers, upgrades and what happens if an external dependency fails.

Behavioral questions

• “Tell me about a time you shipped a contract to mainnet. How did you reduce risk?”
• “Tell me about a disagreement over a security trade-off.”
• “How do you keep up with new vulnerabilities and exploits?”

Questions to ask the interviewer

• “How are contracts reviewed and audited before deployment?”
• “Who controls upgrades and admin keys?”
• “Is there a bug bounty program, and how are incidents handled?”

Related guides: backend developer interview questions, security engineer interview questions, penetration tester interview questions and Python interview questions for junior developers.

Frequently asked questions

Sources

• ethereum.org, Ethereum Virtual Machine (EVM). Read on 2 October 2026.
• Solidity documentation, Solidity. Read on 2 October 2026.
• OWASP, OWASP Smart Contract Top 10. Read on 2 October 2026.