Top 20 Blockchain Career Questions

What it tests: whether you can explain the concept without jargon or hype.

Model answer: A blockchain is a distributed ledger — a list of records that is replicated across many nodes instead of being owned by a central server. Each new batch of records (a block) contains a cryptographic hash of the previous block, which is what makes the chain tamper-evident: changing an old block would invalidate every hash after it. Nodes agree on the order of blocks through a consensus mechanism. Because no single party controls it, blockchains are useful when multiple parties need to agree on a shared record of truth without a trusted middleman. Beyond crypto, that is useful for supply chain, identity, and tokenised assets.

What it tests: whether you understand the mechanism that makes blockchains secure, not just the terminology.

Model answer: A hash function takes any input and produces a fixed-length output. It is deterministic — the same input always produces the same hash — one-way — you cannot reverse it — and collision-resistant — two inputs producing the same hash is practically impossible. Blockchains use hashing in three places: each block stores the previous block's hash, so tampering breaks the chain; transactions are hashed into a Merkle tree, so you can verify a transaction without downloading the whole block; and proof-of-work requires finding a hash below a target, which is what makes mining expensive. SHA-256 in Bitcoin and Keccak-256 in Ethereum are the ones most people encounter.

What it tests: whether you understand consensus as a trade-off, not a slogan.

Model answer: Proof-of-work (PoW) secures the network by requiring miners to spend computational power on finding a valid hash; producing a block is expensive, and attacking the chain means out-computing the rest of the network. Bitcoin uses PoW. Proof-of-stake (PoS) secures the network by requiring validators to lock up tokens as stake; if they behave maliciously, they lose their stake. Ethereum moved to PoS in 2022. PoW is battle-tested but energy-intensive. PoS is energy-efficient but relies on different incentives, and its long-term security properties are still being studied. Neither is universally "better" — they optimise for different things.

What it tests: whether you understand wallet security, which is the single most common source of loss in crypto.

Model answer: A private key is a large secret number that controls your funds. A public key is derived from it using elliptic curve cryptography, and a wallet address is derived from the public key. You share the public key and address freely; you never share the private key. To authorise a transaction, you sign it with your private key, and any node can verify the signature using your public key. This is why losing your private key means losing access — no central authority can reset it. In practice, wallets use seed phrases to encode the private key in a human-readable form, and hardware wallets keep the key off the internet entirely.

What it tests: whether you understand what a smart contract actually is and is not.

Model answer: A smart contract is code deployed to a blockchain that executes automatically when its conditions are met. On Ethereum it is typically written in Solidity, compiled to bytecode, and deployed at a specific address. Once deployed, its code is immutable — you interact with it by sending transactions, and every state change is recorded on-chain. "Smart contract" is a slightly misleading name: it is not a legal contract, and it is not inherently smart. It is deterministic code with real financial consequences. That is why testing and auditing matter so much — a bug cannot be "patched" the way it can in a traditional web app, unless you build in an upgrade mechanism from day one.

What it tests: whether you understand the economic model of on-chain computation, not just the syntax.

Model answer: Gas is a unit of computational effort. Every operation on Ethereum — storage write, transfer, loop iteration — costs a defined amount of gas, and users pay a fee in ETH for the gas their transaction consumes. Gas price fluctuates with network congestion. The practical consequence is that code design has direct economic cost: storing data on-chain is much more expensive than computing it locally, so good contracts minimise storage and avoid unbounded loops. In interviews, the gas question is really a design question — "can you write code that respects the cost of computation?"

What it tests: whether you understand the most famous smart contract vulnerability class.

Model answer: Reentrancy is when an external contract calls back into your contract before your first execution has finished updating state — allowing the attacker to drain funds repeatedly. It was the cause of the 2016 DAO hack. You prevent it by following the checks-effects-interactions pattern: validate inputs, update your own state, and only then make external calls. The other common defence is a reentrancy guard (a simple lock modifier). Both are standard practice in modern Solidity. The important point is that the vulnerability is about ordering of operations, not about the external call itself — some external calls are necessary, but the state update must come first.

What it tests: whether you know a historical vulnerability and how modern Solidity changed.

Model answer: Integers in Solidity have fixed sizes. If a uint8 is 255 and you add 1, older versions would wrap to 0 (overflow). Similarly, subtracting 1 from 0 would underflow to 255. Before Solidity 0.8.0, you had to use SafeMath to prevent this. Since 0.8.0, overflow and underflow revert by default, so this class of bug is largely gone in modern code. But you still need to handle it in unchecked blocks, and it is still an interview topic because it teaches the general lesson: fixed-size arithmetic in financial code is dangerous, and you need to reason about boundaries.

What it tests: whether you know that "deployed once" is not testing.

Model answer: I use Hardhat or Foundry as the testing framework. I write unit tests for each function — happy paths, edge cases, reverts — and integration tests for interactions between contracts. For anything handling funds, I write tests that specifically try to break the security model: reentrancy attempts, access control bypasses, arithmetic boundaries. I use Foundry's fuzzing for arithmetic and property-based tests because it catches cases I would not write by hand. For larger systems, I would run static analysis (Slither) and consider a professional audit before mainnet deployment. Testing smart contracts is a different discipline from testing web apps — the cost of a bug is measured in stolen funds, not in a rollback.

What it tests: whether you can reason about trade-offs between immutability and practicality.

Model answer: Immutable contracts cannot be changed after deployment, which is a security feature but also a problem when a bug or a feature gap appears. Upgradeable contracts use a proxy pattern: users interact with the proxy address, and the proxy delegates calls to an implementation contract whose address can be changed. This lets the team ship fixes, but it also means the team can change the rules — a centralisation risk. In interviews, the right answer is usually "it depends": for a small, well-audited contract, immutability is a strength; for a complex protocol with ongoing development, upgradeability is a practical necessity, and the design should include timelocks and governance so users are not surprised.

What it tests: whether you understand how blockchains stay verifiable without being enormous.

Model answer: A Merkle tree hashes pairs of transactions repeatedly until a single root hash remains. That root is included in the block header. To prove a specific transaction is in a block, you only need the small set of sibling hashes on the path from that transaction to the root — a Merkle proof — not the full set of transactions. This is what makes light clients possible: they can verify inclusion with a tiny fraction of the data. It also makes tampering easy to detect: changing any transaction changes the root, which breaks the chain. In interviews, the point is that Merkle trees solve verification, not just storage.

What it tests: whether you understand the scaling landscape, not just the base chain.

Model answer: Layer 1 is the base blockchain — Ethereum, Bitcoin, Solana. It is the source of security and consensus. But layer 1 throughput is limited, and fees rise when demand is high. Layer 2 is a class of protocols built on top of a layer 1 to increase throughput and reduce fees while inheriting layer 1's security. Rollups (Optimistic and ZK) are the main categories today — they batch many transactions and post a summary to layer 1. Sidechains are a different pattern: they run their own consensus and therefore have different security properties. In interviews, the important distinction is between inheriting security from L1 (rollups) versus relying on separate consensus (sidechains).

What it tests: whether you can structure a technical story for a mixed audience.

Model answer: I use a four-part structure: problem, approach, result, and what I learned. For example: "The problem was a small internal reward system that kept losing track of allocations across three teams. I built a simple ERC-20 token plus a distributor contract — allocation tables stored off-chain and hashed on-chain, claims executed by signed message — with Hardhat tests covering the claim path and a small admin panel. It went live on a testnet and removed the manual monthly reconciliation. The biggest lesson was that off-chain data hashing gives you most of the benefits with far less gas than storing every allocation on-chain."

What it tests: whether you can reason about security problems rather than just write happy-path code.

Model answer: I was auditing a small lottery contract and noticed that the winner's payout used call before updating internal state — the classic reentrancy shape. In the specific contract, a fallback function on the winner's address could have re-entered the payout and drained the pool. I rewrote it to follow checks-effects-interactions and added a reentrancy guard, then wrote a test that simulates a malicious receiver. The fix was small, but it was a good lesson in reading contract code as a series of state transitions rather than as functions — which is how the actual attack works.

What it tests: whether you understand the deployment lifecycle, which many beginners skip.

Model answer: I deploy with Hardhat or Foundry scripts, parameterised per network, and keep deploy scripts in the repo alongside the contracts. After deployment, I verify the source code on the block explorer so anyone can read what is running — verification matters because unverified contracts look suspicious to users and auditors. I record deployment addresses in a config file and tag the commit that matches, so the code that is live is exactly the code in the repository. For anything user-facing, I also set up a small monitoring script that watches for unexpected events or large withdrawals, so I learn about problems from my own tooling rather than from a support message.

What it tests: whether you can read code critically — the single most valuable blockchain skill.

Model answer: I start by reading for the money flow — where funds enter, where they leave, and what state gates those exits. Then I look at access control: who can call the sensitive functions, and can that be bypassed. Then arithmetic and boundary conditions: what happens with zero, with the maximum, with an array at capacity. Then external calls: are they made before state updates, and can a malicious receiver re-enter. Finally I run static analysis tools like Slither for automated checks, and I write small tests for anything suspicious. Auditing well is slower than writing — the point is not to find the happy path, it is to find the path the developer did not imagine.

What it tests: whether your motivation is durable or just trend-driven.

Model answer: I want to work in blockchain because it combines two things I care about — careful systems thinking and real consequences for the user. I built projects because I wanted to understand why a transaction fails and what it means for the person on the other side, not just how to make the test pass. I am drawn to roles where the code has financial weight — payments, custody, tokenised assets. I know most of the work is not glamorous: it is testing, reading, and being paranoid about edge cases. That is exactly the part I find interesting.

What it tests: whether you have a real habit, not just an answer you rehearsed.

Model answer: I follow a small set of sources — the Ethereum Foundation blog, a couple of audit firm write-ups, and a handful of developers on social media whose work I trust. When I read about a new vulnerability or design pattern, I try to reproduce it in a test project rather than just note it down. Blockchain has a lot of noise, so I try to weight primary sources — EIPs, code, audit reports — over commentary. The habit I care about is turning reading into something I can explain in an interview or implement in my own code.

What it tests: whether you can communicate, which is the most common gap in junior blockchain candidates.

Model answer: I start with the decision they need to make, not with the technology. If it is about fees, I compare gas to postage — you pay more when the network is busy, and you design the letter to be small. If it is about wallets, I compare a private key to a physical key, except there is no locksmith if you lose it. I avoid the words "consensus", "cryptography", and "immutable" unless they use them first. I finish by repeating back the decision or action I need from them, so nothing is assumed.

What it tests: whether you have self-awareness about your gaps and a plan.

Model answer: I want to get stronger at security and systems. Concretely: learn Foundry properly so I can write better tests and fuzz arithmetic, spend real time on audit reports to build intuition for what breaks, and understand how layer 2 works so I can reason about cost and finality. I also want to read production contracts — Uniswap, Aave, ENS — because that is where the patterns that are not in books actually show up. Blockchain is a field where the difference between junior and mid-level is almost entirely security judgment, and that is what I want to build.

None of them word-for-word. Prepare the structure of your answer and one concrete example per question. Word-for-word answers sound rehearsed and fall apart on the first follow-up. What you should memorise is the shape — frame, map, answer, trade-off, close — and the specific examples you will use.

Use a project you built on your own — a small contract, a token, a DAO experiment, a hackathon submission. The interviewer is testing whether you can structure a technical story, not whether the project was paid. Be honest about the context, and focus on the decisions you made, especially the security ones.

Start with a plain-language definition, then go one level deeper only if the interviewer asks. Juniors who recite details they cannot explain sound weaker than juniors who explain the concept simply and add one concrete example. Blockchain has a lot of vocabulary — the candidates who stand out are the ones who can drop it and still be understood.

Yes — but not immediately. Try to reason out loud first. Say what you do know, then what you would check or look up. In blockchain, admitting a gap in one area while showing solid reasoning in another is far stronger than confidently guessing on a security question.

You are ready when you can answer all twenty questions in under two minutes each, with a concrete example and one trade-off — and when your five project stories are written down and rehearsed out loud. Do two mock interviews with a friend or mentor before the real one, and try to have at least one deployed contract you can walk through line by line.

Most junior blockchain interviews draw from this set — not always the exact wording, but the underlying concepts. You will typically see five to eight questions from this list across two rounds, plus company-specific variations and follow-ups on your projects.

Not deeply. Most junior interviews weight fundamentals, contract writing, and security reasoning. Zero-knowledge proofs, elliptic curve internals, and advanced cryptography come up at mid-level and above. The twenty here are the foundation.

Start with Solidity if you are targeting Ethereum and EVM chains, which cover the vast majority of junior roles today. Learn Rust if you are targeting Solana or high-performance chains. The reasoning you build — about state, access control, and reentrancy — transfers across languages; the syntax is the easier part.

Pause, say what you do remember, and reason from there. Most interviewers prefer a candidate who thinks out loud to one who delivers a memorised answer that falls apart on the first follow-up. Recovery is a positive signal, not a negative one.

Yes. Bring links to your GitHub and, ideally, a deployed contract on a testnet the interviewer can inspect. Even if you are not asked, having it ready lets you say "I can show you" when they ask about a project. It also signals preparation.