---
title: Blockchain Developer Interview Questions & Answers (2026)
description: Blockchain developer interview questions for 2026 — consensus, smart contracts, gas, wallets, public vs private chains and a dApp design question — with real answers.
url: https://usegreenroom.app/blog/blockchain-developer-interview-questions
last_updated: 2026-06-20
---

← Back to blog

Roles

# Blockchain developer interview questions and answers

June 20, 2026 · 31 min read

![Blockchain developer interview questions and answers — cover from Greenroom, the AI mock interviewer](/assets/blog/blockchain-developer-interview-questions-hero.webp)

You're on a video call with a Web3 startup's CTO, and you've spent the last week rehearsing exactly one fact about yourself: you understand blockchain *deeply*, deeply enough that you once explained Bitcoin to your grandmother using a shared Google Sheet as a metaphor for distributed ledgers, and she nodded along like she got it (she did not get it, but she was proud of you, which is close enough). You walk in ready to talk consensus mechanisms and decentralization philosophy. The CTO opens with: "Walk me through what happens, line by line, if I call `withdraw()` on this contract twice in the same transaction."

You freeze, because somewhere between "blockchain is the future of trust" and this exact moment, nobody told you the interview would actually require you to trace a reentrancy attack through actual function calls rather than discuss decentralization in the abstract for forty-five minutes. You say something about "smart contracts being secure by design," which is the blockchain-interview equivalent of saying "well, planes are usually safe" to a pilot who just asked you to explain lift. The CTO's webcam doesn't move, but you can feel the silence develop opinions about you.

This is the gap that defines almost every weak **blockchain developer interview** performance: candidates who can talk fluently about blockchain as an *idea* — decentralization, trustlessness, "banking the unbanked," whatever slide deck language got them excited about the space in the first place — and freeze the moment they're asked to reason about it as *code*, with real function calls, real storage slots, and real money that disappears permanently if you get the ordering wrong. Blockchain interviews are unusually unforgiving this way, for a reason that's actually worth sitting with for a second: in almost every other engineering discipline, a bug ships, breaks something, and gets patched. In smart contract development, a bug ships, breaks something, and the something is frequently gone forever, because the entire selling point of the technology is that nobody — not even the team that wrote the code — can quietly roll it back.

That's why blockchain interviews test how distributed ledgers actually work — consensus, cryptography, smart contracts (usually Solidity on Ethereum), and the unique security concerns of immutable, money-handling code. They also test judgment: when you'd reach for a public chain versus a private one, how a transaction actually gets signed, and how you'd split a dApp's data between on-chain and off-chain storage. This guide covers the **blockchain developer interview questions** that actually get asked, organized by area, with a real answer for each one, a look at how candidates typically prepare and where each method falls short, and a realistic prep plan.

## Blockchain fundamentals

### How does a blockchain actually work?

A blockchain is a sequence of blocks, each containing a batch of transactions, a timestamp, and a cryptographic hash of the *previous* block's header. That last part is what makes it a chain: change one byte in block 100, and its hash changes, which breaks the hash pointer stored in block 101, which breaks 102, and so on — so altering history requires redoing every block after the one you touched, on every copy of the ledger held by every node. Each node independently validates new blocks against the same rules (valid signatures, no double-spends, correct hash), so the network agrees on one canonical history without any single party owning it. The interview signal here isn't reciting "blocks and hashes" — it's being able to explain *why* that structure makes tampering expensive rather than just "hard."

### What makes a blockchain immutable and decentralized, really?

Immutability isn't a technical guarantee that data can never change — it's an economic one: changing past data requires more computational or economic power than the rest of the honest network combined, and that cost grows with every block added on top (more "confirmations"). Decentralization means no single node's copy is authoritative; consensus rules (covered next) decide which version of the ledger is "true" when nodes disagree, typically by favoring whichever chain represents the most accumulated work or stake. A practical follow-up interviewers ask: "if 51% of miners colluded, what could they actually do?" — the honest answer is they could censor or reorder transactions and double-spend their own coins, but they still can't forge someone else's signature or create coins out of thin air, because that's enforced by cryptography, not consensus.

### What's a hash function and a digital signature doing in a blockchain?

A cryptographic hash function (SHA-256 in Bitcoin, Keccak-256 in Ethereum) takes any input and produces a fixed-size output that's effectively impossible to reverse or to find a second input that produces the same output — that's what lets a block "fingerprint" all its transactions and its parent block cheaply. A digital signature proves a transaction was authorized by whoever holds a specific private key, without ever revealing that key: the sender signs the transaction hash with their private key, and anyone can verify the signature against the corresponding public key. Together, hashing gives you tamper-evidence and signatures give you authenticity — a transaction can't be altered in transit without invalidating its signature, and it can't be forged without the private key.

## Consensus mechanisms

### What's the difference between Proof of Work and Proof of Stake?

Proof of Work has miners compete to find a hash below a target value (essentially trial-and-error guessing), which costs real electricity and hardware — the first miner to find a valid hash adds the next block and collects the reward. It's been battle-tested since Bitcoin in 2009 and its security comes directly from the cost of the hardware and energy required to out-compute the honest network. Proof of Stake instead selects validators to propose and attest blocks in proportion to how much cryptocurrency they've locked up as collateral; validators who act dishonestly (double-signing, proposing invalid blocks) get a portion of their stake "slashed." Ethereum's 2022 move to Proof of Stake cut its energy use by roughly 99.95% — a number interviewers like to hear you know, because it's the actual headline reason the switch happened.

### What are the real tradeoffs between PoW and PoS — security, energy, and finality?

On security: PoW attacks require buying or renting enough hashpower to out-race the network (a 51% attack), which is expensive but anonymous and reversible once you stop paying for hardware; PoS attacks require acquiring a third of the staked supply, which is even more expensive in practice and the attacker's capital is *visibly at risk* and gets slashed if caught, making it self-punishing in a way PoW isn't. On energy: PoW's security is literally proportional to wasted electricity, which is the core criticism; PoS achieves comparable security with validators running ordinary servers. On finality: PoW chains only get *probabilistic* finality — each additional confirming block makes a reorg exponentially less likely but never impossible — while many PoS designs (like Ethereum's) add explicit "checkpointing" so blocks become economically irreversible after a fixed number of epochs, giving you a harder finality guarantee. The honest answer interviewers want isn't "PoS is strictly better" — it's that PoW has a longer track record and arguably stronger censorship-resistance against state-level attackers with unlimited capital, while PoS is cheaper to run and faster to finalize.

### What other consensus mechanisms should I know about?

Beyond PoW and PoS, interviewers occasionally probe whether you've looked past Ethereum specifically. **Delegated Proof of Stake (DPoS)** (EOS, early Tron) has token holders vote for a small set of delegates who actually produce blocks, trading some decentralization for much higher throughput. **Practical Byzantine Fault Tolerance (PBFT)**-style consensus (used in many permissioned/enterprise chains) has a known, fixed set of validators reach agreement through multiple rounds of message-passing, tolerating up to roughly a third of participants being faulty or malicious — it gives instant finality with no probabilistic waiting, but only works because the validator set is small and known, which is exactly why it fits permissioned chains and not an open, anonymous network. Knowing that "consensus mechanism" isn't a synonym for "Proof of Work or Proof of Stake" — that it's a whole design space with real tradeoffs between throughput, decentralization, and finality speed — is itself a signal that you've thought past the two most-memorized answers.

## Smart contracts

### What is a smart contract, concretely?

A smart contract is code deployed at an address on the blockchain that runs deterministically — every node that processes a transaction calling it gets the exact same result, which is what lets the network agree on the new state. It holds its own storage (state variables) and balance, and other accounts or contracts interact with it by sending transactions that call its functions. Unlike a contract in the legal sense, it doesn't "interpret" intent — it executes exactly what's written, which is precisely why bugs in deployed contracts are so dangerous: there's no judge to appeal to, only the code.

### What are common smart contract design patterns you should know?

The **checks-effects-interactions** pattern (validate inputs, update your own state, *then* call external contracts — covered in detail below under reentrancy) is the most important one. The **pull-over-push payment** pattern has users withdraw funds themselves (`withdraw()`) rather than the contract pushing payments out to a list of addresses, because a single failing/malicious recipient in a push loop can block payment to everyone else. **Access control modifiers** like `onlyOwner` gate sensitive functions (pausing the contract, upgrading a pointer, withdrawing fees) behind a check on `msg.sender`. And the **proxy/upgradeability pattern** separates a contract's storage from its logic behind a delegatecall proxy, so a team can fix bugs in already-deployed code — at the cost of added complexity and a new class of storage-collision bugs.

### Why is smart contract code so hard to fix after deployment?

Once deployed, a contract's bytecode lives at a fixed address and can't be edited in place — there's no "redeploy the patch" the way you'd push a hotfix to a server, because the whole point of the chain is that code execution is deterministic and trustless, which requires the code to be fixed. Teams work around this with upgradeable proxy patterns (the logic contract address can be swapped, though this reintroduces a layer of trust and a history of storage-layout bugs) or by designing contracts with circuit breakers (a `pause()` function) and strict caps on funds at risk. This is also why audits, formal verification, and testnets matter so much more here than in typical web development — a missed edge case in a contract holding real money is a permanent, public, often irreversible loss, not a ticket in a bug tracker.

### Explain the reentrancy attack and the fix.

A reentrancy attack happens when a contract sends funds to an external address (or calls another contract) *before* updating its own internal state to reflect that the funds were sent. If the receiving address is itself a malicious contract, its fallback function can call straight back into the original function — and since the original contract's balance hasn't been updated yet, the check that should stop a second withdrawal still passes, letting the attacker drain funds in a loop within a single transaction. This was exactly the bug behind the 2016 DAO hack, which drained roughly $60M in ETH and led to Ethereum's contentious hard fork. The fix is the **checks-effects-interactions** pattern: validate the request, update your state (decrement the balance) *first*, and only then make the external call:

```solidity
// Vulnerable
function withdraw(uint amount) public {
    require(balances[msg.sender] >= amount);
    (bool ok, ) = msg.sender.call{value: amount}("");
    require(ok);
    balances[msg.sender] -= amount; // too late — already called out
}

// Fixed
function withdraw(uint amount) public {
    require(balances[msg.sender] >= amount);
    balances[msg.sender] -= amount;  // effects before interaction
    (bool ok, ) = msg.sender.call{value: amount}("");
    require(ok);
}
```

A `nonReentrant` modifier (OpenZeppelin's `ReentrancyGuard`, which sets a lock flag for the duration of the call) is the standard belt-and-suspenders addition on top of getting the ordering right. If an interviewer asks you to trace through the vulnerable version line by line — the exact "walk me through it" moment from the opening story — narrate it as a stack: `withdraw()` calls out, the malicious contract's fallback fires and calls `withdraw()` again *before the first call has returned*, and because `balances[msg.sender]` is still the original, unreduced number, the `require` passes a second time, and a third, and a fourth, until the contract's balance or the call stack runs out. Saying this calmly, in order, function call to function call, is worth more than any abstract definition of "reentrancy."

### What about integer overflow/underflow and other common vulnerabilities?

Before Solidity 0.8, arithmetic silently wrapped around — subtracting 1 from a `uint` at 0 would wrap to the maximum value instead of reverting, which attackers exploited to mint themselves huge balances. Solidity 0.8+ reverts on overflow/underflow by default, so this is largely a solved problem in modern code, but interviewers still ask it to check whether you understand *why* it was dangerous and whether you know it's no longer the default failure mode. Other recurring vulnerabilities worth naming: **front-running** (a pending transaction is visible in the mempool before it's mined, so a miner or bot can see a profitable trade and insert their own ahead of it), **timestamp dependence** (using `block.timestamp` for randomness or critical logic, when miners have some latitude to manipulate it), and **unchecked external call return values** (assuming a `.send()` or low-level `.call()` succeeded without checking its return value).

## Gas

### What is gas, and why does it exist?

Gas is the unit that measures the computational work a transaction or contract call requires — every opcode (storage write, arithmetic, external call) costs a fixed amount of gas, and the sender pays `gas used × gas price` in the network's native currency to get their transaction processed. It exists to solve a real problem: without a cost per computation, anyone could submit an infinite loop and stall every node on the network forever (the "halting problem" applied to a shared computer). Gas turns computation into a scarce, paid resource, which both funds the validators/miners doing the work and makes spam and denial-of-service attacks economically irrational.

### What are real gas optimization techniques?

Pack related state variables to fit fewer storage slots — Solidity storage operates in 32-byte slots, so declaring two `uint128` values back-to-back lets them share one slot instead of two, and that's a real `SSTORE` (the most expensive opcode) saved per write. Use `calldata` instead of `memory` for function arguments that don't need mutation, since copying into memory costs gas you don't need to spend. Cache repeated storage reads into a local variable inside a loop — every `SLOAD` is far more expensive than reading a local variable. Prefer `mapping` over `array` for lookups you don't need to iterate, since array iteration cost scales with length while mapping access is constant. And batch operations where possible, since each transaction has a fixed overhead (21,000 gas base cost) on top of its actual work.

### Why do gas fees spike, and what does EIP-1559 change?

Gas fees spike when many transactions compete for limited block space — each block has a gas limit, so when demand for inclusion exceeds that limit, users effectively bid against each other via gas price to get their transaction mined sooner. Before EIP-1559, this was a blind first-price auction: everyone guessed a gas price, often overpaying out of fear of being left out. EIP-1559 (live on Ethereum since 2021) replaced that with a **base fee** that adjusts block-by-block based on how full the previous block was — rising when blocks are consistently full, falling when they're not — plus an optional **priority fee** (tip) that goes directly to the validator for faster inclusion. The base fee itself is burned (destroyed, not paid to anyone), which removes it from circulating supply and makes fee estimation far more predictable than the old auction model.

## Public vs private/permissioned chains

### When would you choose a public chain over a private one, and vice versa?

Public chains (Ethereum, Bitcoin) are permissionless — anyone can run a node, submit transactions, or read the full state — which is exactly right when the point is trustlessness between parties who don't know or trust each other: DeFi, public token issuance, anything where "no one can secretly change the rules" is the actual product requirement. Private or permissioned chains (Hyperledger Fabric, R3 Corda, a consortium-run network) restrict who can run nodes or see transaction data, trading some decentralization for throughput, privacy, and known, accountable participants — which fits enterprise use cases like a consortium of banks settling trades, or a supply chain network where competitors need a shared ledger but not full public visibility into each other's volumes and prices. The interview signal is knowing that "blockchain" isn't one architecture — it's a spectrum from fully public and trustless to fully permissioned and closer to a shared, audit-friendly database, and picking the right point on that spectrum is a real design decision, not a default.

### How is something like Hyperledger Fabric actually different from Ethereum under the hood?

Ethereum has every node execute every transaction and agree on one global state via consensus, with gas pricing computation because resources are shared among anonymous parties. Hyperledger Fabric instead lets you define "channels" — sub-networks of known participants who share only the transactions relevant to them — and separates the roles of *endorsing* a transaction (deciding it's valid), *ordering* it into a block, and *committing* it to the ledger, which lets you tune throughput and privacy independently in a way a single global public chain can't. There's also typically no native cryptocurrency or gas market in an enterprise chain like Fabric — since participants are known and accountable, you don't need an economic deterrent against spam, you can just use access control.

## Wallets and keys

### How do public/private key pairs and wallets actually work?

A wallet doesn't store coins — it stores a private key, and the blockchain's ledger tracks balances against public addresses derived from public keys. Your private key is a large random number; your public key is mathematically derived from it via elliptic curve cryptography (secp256k1 for Bitcoin and Ethereum) in a way that's trivial to compute in one direction and computationally infeasible to reverse — you can't derive the private key from the public key or address. Your address is itself derived from your public key (typically hashed and truncated). Anyone can send funds to your address using only your public information; only the holder of the matching private key can sign a transaction spending those funds.

### Walk through how a transaction actually gets signed and verified.

You construct a transaction (recipient, amount, nonce, gas parameters), hash it, and sign that hash with your private key using ECDSA, producing a signature. You broadcast the transaction plus the signature (not the private key) to the network. Every node that receives it recovers your public key from the signature and the transaction hash, derives the address from that public key, and checks it matches the `from` address you claimed — if it matches, the signature is valid and the transaction is authentic, without your private key ever having left your device. This is also why losing a private key is unrecoverable and why a leaked private key is catastrophic and immediate: whoever holds the bytes can sign anything as you, no password reset possible.

### What's the difference between custodial and non-custodial wallets?

In a **custodial** wallet (a centralized exchange like Coinbase holding your funds), the platform holds the private keys on your behalf — you trust them to manage security and honor withdrawals, similar to trusting a bank, and they can freeze or lose your funds. In a **non-custodial** wallet (MetaMask, a hardware wallet like a Ledger), you hold the private key yourself, typically backed by a seed phrase (a human-readable encoding of the key) — no one can freeze your funds or go bankrupt with them, but there's also no customer support number if you lose the seed phrase. The phrase you'll hear constantly in this space, "not your keys, not your coins," is exactly this distinction, and interviewers ask it to see whether you understand custody as a real security and product tradeoff, not just wallet trivia.

## ERC-20 and ERC-721 (tokens and NFTs)

### What's the actual difference between ERC-20 and ERC-721?

ERC-20 defines a standard interface for **fungible** tokens — every unit is identical and interchangeable, like a currency: `balanceOf`, `transfer`, `approve`, and `transferFrom` let any wallet or exchange interact with any ERC-20 token the same way, which is exactly why thousands of tokens all work in the same wallets and DEXs without custom integration per token. ERC-721 defines **non-fungible** tokens — each token ID is unique and tracked individually (`ownerOf(tokenId)`), so it's the right standard for things where identity matters: a specific deed, a specific in-game item, a specific piece of art. The interview-useful detail: both are just interfaces (a set of function signatures), which is the entire reason the ecosystem interoperates — a marketplace doesn't need to know anything about your specific NFT project, only that it implements the standard functions.

### What is ERC-1155, and why does it exist alongside the other two?

ERC-1155 is a "multi-token" standard that lets a single contract manage many token types — fungible, non-fungible, or semi-fungible — under one address, with batch transfer support (`safeBatchTransferFrom`) that moves multiple token types in a single transaction instead of one transaction per token. It exists because a game with thousands of item types (swords, potions, unique skins) would otherwise need a separate ERC-20 or ERC-721 contract deployed per item type, which is both expensive (deployment gas) and operationally painful. The interview signal: knowing ERC-1155 exists, and specifically that batch operations are the actual reason it was created — rather than treating ERC-20 and ERC-721 as the only two standards worth knowing — shows you've looked slightly past the two most commonly cited ones.

## How candidates actually prepare for blockchain interviews — and where each method falls short

Almost every candidate preparing for a blockchain developer role ends up leaning on some mix of four approaches, and each one trains a different slice of the actual interview — which is exactly why over-relying on just one leaves a predictable, visible gap.

**Reading Solidity docs and tutorial repos (CryptoZombies, Solidity-by-example, a Udemy "build your first dApp" course).** Genuinely useful, and close to mandatory — you need the syntax fluency these build. The gap: tutorials are written to demonstrate a *working* pattern, not to put you under the kind of adversarial pressure a real interviewer applies. You can complete a full CryptoZombies course and still freeze the first time someone asks "what happens if I call this twice in the same transaction" rather than "build a feature that works once, in the happy path."

**LeetCode and generic DSA grinding.** Useful for the data-structures-adjacent parts of a blockchain role (most teams still expect solid backend fundamentals underneath the chain-specific knowledge — see our [backend developer guide](/blog/backend-developer-interview-questions)), but it trains essentially none of the security-reasoning skill that differentiates a blockchain interview from any other backend interview. A candidate who's great at LeetCode and has never traced a reentrancy attack by hand is still under-prepared for the round that actually decides this kind of hire.

**A friend's "my Web3 interview experience" thread or a Web3-focused Discord/Telegram group.** Genuinely useful for calibration — knowing that a particular protocol's interview leans heavily on gas optimization, or that another one spends the whole call on a single design question, helps you mentally prepare for the *shape* of the conversation. The honest limitation, as with any single-source experience report: one person's loop at one protocol in one hiring cycle isn't a guarantee of what you'll get, and chains/protocols vary more in interview style than most "big tech" companies do.

**Generic ChatGPT mock-interview prompting.** Better than nothing for drilling factual recall (consensus definitions, ERC standard differences, vulnerability names), but it's a text-based, turn-taking exercise with no real adversarial pressure, and the follow-ups are only ever as sharp as the prompt you wrote yourself. It doesn't replicate the specific, uncomfortable moment of being asked to trace a vulnerable function call by call, live, with someone watching you think and ready to interrupt the moment your explanation gets vague.

The honest throughline across all four: blockchain interviews specifically grade **security reasoning narrated out loud, under a live trace-through-the-code follow-up** — not whether you can eventually produce a correct, audited contract with no time pressure and unlimited lookup access. That's the exact gap [Greenroom](/)'s spoken mock-interview format is built to close: you talk through a vulnerability, a consensus tradeoff, or a contract design out loud, the AI interviewer asks real follow-ups the way a Web3 hiring manager would (a constraint change, a "walk me through what happens if you call this twice" trace request, a request to extend your design to handle an edge case), and you get feedback on the clarity of your reasoning, not just whether the final answer was technically right. It's not a replacement for actually knowing Solidity and the EVM — you still need the tutorial reps and the fundamentals — but it's the one method on this list that rehearses the verbal, interrupted, defend-your-trace format the real interview actually is.

## Scenario: design a token vesting contract

This is the kind of design question interviewers use to see whether you can turn a real-world requirement into a contract structure under questioning, not just recite definitions.

1. **Clarify requirements out loud first.** Who's vesting (employees, investors)? Is there a cliff (e.g., nothing vests for the first 12 months, then it starts)? Linear vesting after the cliff, or milestone-based? Can the company revoke unvested tokens if someone leaves?
2. **Core state.** Per beneficiary: total allocated amount, start timestamp, cliff duration, total vesting duration, and amount already claimed. Store these in a struct in a mapping keyed by beneficiary address — keeping each beneficiary's vesting fully independent avoids one buggy entry affecting another's claim.
3. **The vested-amount calculation.** Before the cliff, vested amount is zero. After the cliff, it's linear: `vestedAmount = totalAllocated * (now - start) / vestingDuration`, capped at `totalAllocated` once `now >= start + vestingDuration`. This calculation should be a `view` function so anyone (including a frontend) can check vesting progress without spending gas.
4. **The claim function.** `claimable = vestedAmount() - alreadyClaimed`. Apply checks-effects-interactions exactly as in the reentrancy fix above: validate `claimable > 0`, update `alreadyClaimed` *before* transferring tokens out, then transfer. This is the same bug class as a withdrawal function — vesting contracts hold real value and get attacked the same way.
5. **Revocation, if required.** If the company can revoke, store a `revoked` flag and a `revokedAt` timestamp — vested-but-unclaimed tokens up to the revocation point should still be claimable by the beneficiary (revoking unvested-but-already-earned tokens is both a legal and a trust problem), while everything after revocation stops vesting.
6. **Edge cases to mention unprompted.** What happens if `claim()` is called before the cliff (should simply return/claim zero, not revert confusingly)? What if the contract doesn't hold enough tokens to honor a claim (a funding/accounting bug upstream, should fail loudly)? Should vesting schedules be modifiable after creation (almost always no, for trust reasons — if you need flexibility, build it into the schedule itself, not into a function that lets an admin silently change someone's deal)?

The same shape — clarify requirements, define core state, write the read-only calculation first, then the state-changing function with checks-effects-interactions, then enumerate edge cases out loud — is what interviewers want to see on *any* contract design question, not just vesting.

## Scenario: on-chain vs off-chain data in a dApp

A second common design question: "you're building a dApp — what goes on-chain, and what doesn't?"

The rule of thumb is to put on-chain only what *must* be trustlessly verifiable or directly moves value: token balances, ownership records, the rules that govern a transfer, and anything where you need every party to agree on one canonical, tamper-evident state without trusting a server. Everything else — user profile data, images, large metadata, search indexes, anything that changes frequently or is expensive to store — belongs off-chain, because on-chain storage costs real gas per byte and every node has to store and replicate it forever. A typical NFT project, for example, stores only a token ID and a content hash (pointing to IPFS or a CDN) on-chain, while the actual image and metadata JSON live off-chain — the hash is what makes the off-chain content verifiable without needing it to live on the expensive ledger itself. The follow-up interviewers like to ask: "what if the off-chain storage goes down?" — the honest answer is that's exactly the tradeoff being made, and it's why IPFS (content-addressed, so the same hash always resolves to the same content from whoever's still hosting it) is preferred over a single centralized URL for anything claiming decentralization.

<div class="verdict"><strong>The core truth:</strong> Blockchain interviews weight security and judgment heavily — because smart contracts are immutable and hold real value, a single bug can be catastrophic and unfixable. Knowing reentrancy and checks-effects-interactions cold is table stakes; being able to trace a vulnerable function call by call, and design a contract or a dApp's data split under follow-up questions, is what separates a pass from a strong pass.</div>

## Why strong-looking candidates get rejected anyway

A surprising number of candidates who can recite every definition in this guide still get rejected, and the reasons cluster predictably.

**Fluent on theory, silent under a trace request.** Being able to define reentrancy correctly and being able to trace it function-call-by-function-call, live, while an interviewer asks "okay, now what does the stack look like at this point" are genuinely different skills — and the second one is what most blockchain interviews are actually scoring. Candidates who've only ever read about an attack, never narrated one, visibly stall here.

**No security instinct without being prompted.** Strong candidates volunteer the checks-effects-interactions framing, the pull-over-push pattern, and access control modifiers *before* being asked "but is this secure" — because in a domain where bugs are irreversible and public, proactively naming the failure mode you're defending against is itself the signal. Waiting to be asked reads as someone who's seen the pattern in a tutorial but hasn't internalized why it exists.

**Treating gas optimization as a footnote.** Candidates who can write correct Solidity but have never thought about storage packing, `calldata` vs `memory`, or why a loop over an unbounded array is a real production risk (it can grow expensive — or outright unusable — as the array grows) read as someone who's written contracts for a tutorial, not for production traffic with real users paying real fees.

**No instinct for the on-chain/off-chain split.** A candidate who defaults to "put everything on-chain for maximum decentralization" without weighing storage cost and practicality is solving the wrong problem — interviewers specifically ask the dApp data-split question to catch candidates who haven't yet developed judgment about when decentralization is actually buying you something versus when it's just expensive.

**Confusing "blockchain enthusiasm" with engineering depth.** Being able to talk fluently about tokenomics, the next bull cycle, or a project's whitepaper is not the same skill as being able to write and defend a secure contract, and interviewers — especially technical ones doing the actual hiring — notice immediately when a candidate's depth is heavily weighted toward the former.

## A realistic prep timeline

Give yourself two to three weeks if you're coming from solid backend fundamentals but light blockchain-specific exposure; longer if Solidity itself is new to you.

**Week 1 — Fundamentals and Solidity syntax.** Rebuild the mental model from scratch: blocks, hashes, consensus, public-key cryptography, what a transaction actually contains. Work through a Solidity tutorial series end to end (CryptoZombies or Solidity-by-example), writing every example yourself rather than just reading it, and get comfortable with the EVM's basic execution model — what a transaction actually does step by step from submission to inclusion in a block.

**Week 2 — Security, traced out loud.** This is the week to specifically drill reentrancy, integer overflow history, front-running, and timestamp dependence — not just defining each one, but practicing narrating the vulnerable code path out loud, function call by function call, the way an interviewer will actually ask you to. Write the vulnerable version and the fixed version of at least three classic bugs yourself, from memory, and explain out loud why each fix works rather than just that it does.

**Week 3 — Design questions and mock interviews.** Practice the vesting-contract and on-chain/off-chain design questions from this guide end to end, talking through requirements, state, and edge cases out loud rather than silently. Run full mock interviews under realistic time pressure, prioritizing clear verbal reasoning over silent correctness — since that's specifically what gets graded. If your prep so far has been entirely tutorial-reading and silent practice, this is the week to deliberately swap some of that for spoken rehearsal.

A quick gut check for readiness: can you explain, out loud, in under ninety seconds, exactly what happens at each step if a malicious contract calls back into your `withdraw()` function before its first call returns — without writing any code first? If that's hard to do cleanly, you're not behind on Solidity syntax; you're behind on the specific verbal security-reasoning skill the interview is actually testing.

## Practise explaining, not just memorizing

You can recognize every vulnerability in this guide on a flashcard and still freeze the moment an interviewer asks you to trace one through actual function calls, live, with someone watching you think. Blockchain rounds probe the mental model and security reasoning verbally, not just through a coding exercise — be ready to explain consensus tradeoffs, walk through a reentrancy fix line by line, and design a contract out loud while someone asks "what if" questions. [Greenroom](/) runs spoken technical interviews that follow up on your reasoning the way a real interviewer would. Pair it with our [backend developer](/blog/backend-developer-interview-questions) guide, since most blockchain roles still expect solid backend fundamentals underneath the chain-specific knowledge, and our [system design guide](/blog/system-design-interviews-what-they-test) for the on-chain/off-chain data-split question.

## Frequently asked questions

### What questions are asked in a blockchain developer interview?

Blockchain developer interviews cover how blockchains work (blocks, hashes, immutability, decentralization), consensus mechanisms (Proof of Work vs Proof of Stake and their tradeoffs), smart contracts and Solidity, gas and gas optimization, public vs private/permissioned chains, wallets and key pairs, token standards (ERC-20, ERC-721, ERC-1155), security vulnerabilities like reentrancy and integer overflow, and design questions like building a token vesting contract or splitting a dApp's on-chain and off-chain data.

### What is the difference between Proof of Work and Proof of Stake?

Proof of Work secures the network by having miners compete to solve computationally expensive puzzles, with the winner adding the next block — secure and battle-tested but energy-intensive. Proof of Stake selects validators to propose and attest blocks based on the amount of cryptocurrency they stake as collateral, which is far more energy-efficient and is what Ethereum now uses, though it requires acquiring and risking a large amount of capital to attack rather than just computing power. Both prevent malicious actors from cheaply rewriting history, just through different economic mechanisms.

### What is a reentrancy attack in smart contracts?

A reentrancy attack happens when a contract makes an external call before updating its own state, allowing the called contract to call back into the original function repeatedly and, for example, drain funds before balances are updated. It's prevented with the checks-effects-interactions pattern — update state before making external calls — plus a reentrancy guard as a second layer of protection. It's the bug behind the 2016 DAO hack and remains the most-asked smart-contract security question in interviews, often with a live request to trace the attack function call by function call.

### What is gas and why does it cost money on Ethereum?

Gas measures the computational work a transaction requires, and the sender pays gas used multiplied by gas price to get it processed. It exists because, without a cost per computation, anyone could submit code that loops forever and stall the network — gas turns computation into a paid, scarce resource, funding the validators doing the work and making spam economically irrational. EIP-1559 replaced the old first-price gas auction with a predictable base fee that rises and falls with block fullness, plus an optional tip for faster inclusion.

### When would I use a private blockchain instead of a public one like Ethereum?

Public chains are the right choice when trustlessness between unrelated parties is the actual requirement — DeFi, public token issuance, anything where no single party should be able to secretly change the rules. Private or permissioned chains, like Hyperledger Fabric, fit enterprise cases such as a bank consortium settling trades or a supply chain network, where participants are known and accountable and you'd rather trade some decentralization for throughput and data privacy. The decision is about where on the public-to-permissioned spectrum a given use case actually needs to sit, not about one being universally better.

### How should I prepare for a blockchain developer interview?

Understand blockchain fundamentals, consensus tradeoffs, smart contracts and Solidity, gas and the EVM, wallets and key signing, and public vs private chain design, but weight security heavily — reentrancy, the checks-effects-interactions pattern, and common vulnerabilities — since immutable code holding real value makes bugs catastrophic. Practise designing a contract (like a vesting schedule), tracing a vulnerability function call by function call, and explaining consensus and reentrancy out loud with a voice-based mock interview that follows up on your reasoning the way a real interviewer would.

Blockchain rounds weight security and design judgment heavily, reasoned out loud. Greenroom runs spoken technical interviews that follow up on your reasoning. Free to start.