Blockchain Interview Questions for 7 Years Experience
40 questions with answers for candidates with 7 years of experience — 20 medium, 20 hard.
What interviewers expect: 7 years experience
With seven years, you are expected to lead engineering for a protocol or blockchain practice. Discussions centre on long-term architecture, upgrade and governance strategy, risk management, regulatory awareness in India and abroad, and hiring. You should show measurable outcomes, such as secure launches, reduced costs or scaled systems, and explain how you balance speed of delivery with safety.
This set is weighted towards Smart Contract Security (8), DeFi, Tokens and NFTs (6), Blockchain Fundamentals (6), Consensus and Scaling (6).
Technical strategy Governance and upgrades Regulation and compliance Hiring and mentoring
Solved at this levelStart practicing
3 QUESTIONS FREESign up to unlock the full question bank and track your progress.Unlock every question and answer, then continue practising company-wise and package-wise.
✓ 3 questions free • Unlock the rest in seconds
01
Your team is preparing a contract for an external audit. What do you do beforehand?
Freeze the code at a commit and stop adding features. Write clear documentation: architecture, roles, trust assumptions, invariants and known risks. Reach high test coverage including fuzz and invariant tests, and run Slither and fix its findings. Remove dead code, add NatSpec comments, and make the build reproducible. Share a scope list and a walkthrough call. A clean, well-documented codebase lets auditors spend their limited time on deep logic bugs.
A multisig wallet is a smart contract, such as a Safe, that needs M of N owner signatures to execute a transaction; rules are visible on-chain and easy to audit, but every action costs extra gas and works per chain. An MPC wallet splits one private key into shares held by different parties who jointly produce a normal signature; it looks like a regular address, works on any chain and allows key rotation, but the security depends on the off-chain implementation.
03
You are launching a 10,000-piece NFT collection and fear gas wars and bots. How do you design the mint?
Avoid a first-come public rush. Use an allowlist phase with Merkle proofs or signatures, per-wallet limits, and staggered time slots. Consider a Dutch auction or raffle so price, not gas, decides allocation. Use ERC-721A or efficient batch minting to cut gas. Reveal traits later with Chainlink VRF so bots cannot snipe rare items. Load-test the front-end and RPC, and keep pause functions ready in case something goes wrong.
04
Write a minimal Python example showing how blocks are linked by hashes.
Each block stores the previous hash, so changing any earlier data breaks the chain.
import hashlib, json
def block_hash(block):
data = json.dumps(block, sort_keys=True).encode()
return hashlib.sha256(data).hexdigest()
chain = [{'index': 0, 'data': 'genesis', 'prev': '0'}]
for i, tx in enumerate(['A pays B 5', 'B pays C 2'], 1):
chain.append({'index': i, 'data': tx, 'prev': block_hash(chain[-1])})
valid = all(chain[i]['prev'] == block_hash(chain[i-1]) for i in range(1, len(chain)))
print(valid)
05
How do you manage deployer private keys in a CI/CD pipeline?
Never commit keys or put them in plain environment files. For testnets, use CI secret storage with restricted access. For mainnet, avoid hot keys in CI entirely: have CI produce a transaction proposal that signers approve in a multisig, or use a cloud KMS or HSM signer so the key never leaves secure hardware. Separate deployer and admin roles, transfer ownership to a multisig immediately after deployment, and log and review every deployment.
06
What is account abstraction, and how do ERC-4337 and EIP-7702 differ?
Account abstraction makes accounts programmable, so wallets can support batching, gas paid in tokens or by sponsors, passkeys, spending limits and social recovery. ERC-4337 does this without protocol changes: users send UserOperations to an alternate mempool, bundlers submit them to an EntryPoint contract, and paymasters can sponsor gas. EIP-7702 is a protocol change that lets an existing EOA point to smart account code, so users keep their address while gaining these features.
The trilemma says a blockchain finds it hard to maximise decentralisation, security and scalability at the same time on a single layer. Raising block size or using few validators increases throughput but reduces decentralisation. Ethereum's answer is a rollup-centric roadmap: keep the base layer decentralised and secure, and move execution to Layer 2 rollups that post data back to Layer 1. Many high-throughput chains instead accept fewer, more powerful validators.
08
Write a Foundry invariant test for a token's total supply.
Invariant tests call random functions on target contracts and check a property after every call.
import {Test} from 'forge-std/Test.sol';
import {MyToken} from '../src/MyToken.sol';
import {Handler} from './Handler.sol';
contract SupplyInvariant is Test {
MyToken token;
Handler handler;
function setUp() public {
token = new MyToken();
handler = new Handler(token);
targetContract(address(handler));
}
function invariant_supplyMatchesBalances() public view {
assertEq(token.totalSupply(), handler.sumOfBalances());
}
}
The handler bounds inputs and tracks actors so calls stay realistic.
09
How do you read the latest finalized block with ethers.js, and why use it?
Pass the block tag to getBlock. The finalized tag returns the latest block that Proof of Stake has finalised, which cannot be reverted without slashing a third of stake.
import { JsonRpcProvider } from 'ethers';
const provider = new JsonRpcProvider(process.env.RPC_URL);
const latest = await provider.getBlock('latest');
const safe = await provider.getBlock('safe');
const finalized = await provider.getBlock('finalized');
console.log(latest.number - finalized.number); // usually about 64-96
Use finalized for deposits and accounting; use latest for UI updates.
10
Four organisations are building a private EVM network. Which consensus would you pick: Raft or QBFT?
Raft is crash fault tolerant: fast and simple, but it assumes no node lies, so it fits when all members trust each other's infrastructure. QBFT is Byzantine fault tolerant and tolerates f malicious nodes out of 3f+1, so with four validators it survives one bad actor and gives immediate finality. Since the organisations are separate businesses that may not fully trust each other, I would choose QBFT and run at least four validators, ideally more.
11
A lending protocol reads collateral prices from one DEX pool's current reserves. What is the risk and fix?
Spot prices from a single pool can be moved within one transaction by a flash-loaned swap, letting an attacker inflate collateral value and borrow far more than it is worth, or trigger unfair liquidations. Replace it with a robust oracle such as Chainlink price feeds, or a long-window TWAP from deep pools, check staleness and deviation between sources, cap borrow amounts per block, and add circuit breakers for extreme price moves.
12
Calculate impermanent loss when one token's price doubles.
Formula: IL = 2 x sqrt(r) / (1 + r) - 1, where r is the price ratio change.
For r = 2: sqrt(2) = 1.414, so IL = 2 x 1.414 / 3 - 1 = -0.057, about 5.7 percent.
Example: deposit 1 ETH plus 3,000 USDC when ETH is 3,000 (6,000 dollars). ETH goes to 6,000. Holding would be 9,000 dollars; the pool position is worth about 8,485. Fees earned must exceed the 515 dollar gap for providing liquidity to beat holding.
13
What are state channels, such as the Lightning Network?
A state channel locks funds in an on-chain contract or multisig between parties, who then exchange many signed off-chain updates and settle only the final state on-chain. Lightning on Bitcoin links channels into a network so payments route through intermediaries using hashed timelock contracts. Channels give instant, nearly free payments but need participants to be online or use watchtowers, and they lock liquidity, so they suit repeated payments between known parties rather than general smart contracts.
14
How do you build a tokenised vault using ERC-4626?
ERC-4626 standardises yield vaults: users deposit an asset and receive shares, and share price rises as the vault earns yield.
import {ERC4626} from '@openzeppelin/contracts/token/ERC20/extensions/ERC4626.sol';
import {ERC20} from '@openzeppelin/contracts/token/ERC20/ERC20.sol';
import {IERC20} from '@openzeppelin/contracts/token/ERC20/IERC20.sol';
contract YieldVault is ERC4626 {
constructor(IERC20 asset_) ERC20('Vault Share', 'vSHR') ERC4626(asset_) {}
function totalAssets() public view override returns (uint256) {
return IERC20(asset()).balanceOf(address(this)); // plus deployed funds
}
}
OpenZeppelin uses virtual shares to defend against the first-depositor inflation attack.
15
What are seed phrases and HD wallets (BIP-39, BIP-32, BIP-44)?
BIP-39 encodes random entropy as a 12 or 24 word mnemonic, which is turned into a binary seed. BIP-32 defines hierarchical deterministic wallets that derive a tree of key pairs from that seed. BIP-44 standardises the derivation path, for example m/44'/60'/0'/0/0 for the first Ethereum account. So one backed-up seed phrase can restore unlimited addresses across chains. Whoever knows the phrase controls every derived account, so it must never be stored online.
16
What is the difference between call, delegatecall and staticcall?
call runs the target contract's code in the target's own context, with its own storage, and msg.sender becomes the caller contract. delegatecall runs the target's code in the caller's context, using the caller's storage, balance and original msg.sender; this is how proxies and libraries work, and storage layouts must match. staticcall is like call but reverts on any state change, used for view functions. Delegatecall to untrusted code is extremely dangerous.
17
You need the same contract at the same address on five chains. How do you do it?
Use CREATE2 through a deterministic deployment factory that already exists at the same address on all those chains. Keep the init code identical: same compiler version, optimiser settings, constructor arguments and metadata. Pick a salt, compute the expected address off-chain, then deploy on each chain. Foundry scripts support this by passing a salt. Avoid constructor arguments that differ per chain, or move chain-specific settings into an initialiser restricted to the deployer.
18
What is finality, and how does probabilistic finality differ from deterministic finality?
Finality is the guarantee that a confirmed transaction will not be reversed. In proof of work, finality is probabilistic: each new block on top makes reversal exponentially less likely, so exchanges wait for several confirmations. In BFT-style and Ethereum proof of stake, finality is economic and deterministic: once two-thirds of stake attests to a checkpoint, reverting it would require burning at least one-third of all staked ETH. Ethereum finalises in about two epochs, roughly 13 minutes.
19
Design a blockchain solution for farm-to-store supply chain traceability. What goes on-chain?
I would use a permissioned or low-cost chain where farmers, transporters, warehouses and retailers are known members. On-chain I would record batch IDs, ownership handovers, timestamps, signer identity and hashes of certificates or sensor data. Large documents, images and IoT streams stay off-chain in object storage or IPFS, referenced by hash. QR codes on packs link consumers to the trail. The main risk is bad input data, so I would add signed device readings and audits.
20
Design a back-end relayer so users can make transactions without holding gas.
Users sign an EIP-712 meta-transaction or an ERC-4337 UserOperation. The relayer validates the signature, checks business rules and rate limits per user, then submits it, paying gas from a hot wallet or via a paymaster. Contracts must verify the original signer, using ERC-2771 trusted forwarders or account abstraction. Manage nonces carefully with a queue, replace stuck transactions, keep the relayer wallet funded and monitored, and cap daily sponsorship to prevent abuse.
21
A product team wants to store user documents and personal details directly on a public chain. What do you advise?
Do not put personal data on a public chain. Data there is permanent, public and replicated globally, which conflicts with the right to erasure under India's DPDP Act and GDPR, and storage is extremely expensive. Store documents encrypted in off-chain storage, keep only a salted hash or commitment on-chain for integrity, and control access through the application. If the data must be deleted, delete the off-chain copy and the encryption key; the hash alone reveals nothing.
22
How would you implement Sign-In with Ethereum on a web back-end?
Follow EIP-4361. The server generates a random nonce and stores it in the session. The front-end builds a SIWE message with domain, address, statement, URI, chain ID, nonce and issued-at time, and the wallet signs it. The server verifies the signature with a SIWE library, checks domain, nonce, expiry and chain, then issues a session cookie or JWT and deletes the nonce. For smart contract wallets, verify via ERC-1271 isValidSignature.
23
An auditor flags that a single owner key can mint tokens and change fees. How do you address it?
This is centralisation risk: if the key is compromised or misused, users lose funds. Move ownership to a multisig with signers on separate devices, add a timelock so users can see and react to changes, set hard-coded bounds such as a maximum fee, and remove powers that are not needed, like unlimited minting. Use role-based access instead of one all-powerful owner, and document the remaining admin powers publicly.
24
What is the difference between CREATE and CREATE2?
CREATE computes a new contract's address from the deployer's address and nonce, so the address depends on deployment order. CREATE2 computes it from the deployer address, a chosen 32-byte salt and the hash of the init code, so the address is known before deployment and is the same wherever those inputs match. CREATE2 enables counterfactual wallets, deterministic factory deployments and same-address deployments across chains, but redeploying at the same address needs care.
Cross-function reentrancy happens when an attacker re-enters a different function that shares state with the one making the external call, so a guard on only one function does not help. Read-only reentrancy happens when a view function, such as a pool's price getter, returns inconsistent state mid-execution, and another protocol reads it during the callback and misprices assets. Mitigate by guarding all state-sharing functions, updating state before calls, and checking a reentrancy lock in view functions other protocols rely on.
26
After a transaction is confirmed, your front-end still shows old data. How do you fix it?
The UI is probably reading cached results or a lagging RPC node. After tx.wait() resolves, explicitly refetch or invalidate the relevant queries, for example with wagmi or TanStack Query invalidation. Show optimistic updates while pending. If you use an indexer, it may lag by a few blocks, so poll until it reaches the receipt's block number. Use the same RPC endpoint for writes and immediate reads, and avoid long caching for balances.
27
How do flash loans enable oracle manipulation attacks?
A flash loan lets anyone borrow huge amounts without collateral if it is repaid in the same transaction. An attacker borrows, makes a large trade in a thin DEX pool to move its spot price, then uses a protocol that reads that pool as its price oracle, for example borrowing too much against inflated collateral, and finally reverses the trade and repays. Defend with decentralised oracles like Chainlink, TWAPs, multiple sources and sanity bounds.
28
Why is on-chain randomness insecure, and what should you use instead?
Values like block.timestamp, blockhash or block.prevrandao are visible to or partly controlled by block producers, and any contract can read them in the same transaction and only proceed when the outcome is favourable. So lotteries and NFT trait reveals based on them can be gamed. Use a verifiable random function such as Chainlink VRF, which delivers randomness with a cryptographic proof in a later transaction, or a commit-reveal scheme for simpler cases.
29
What are storage collision and uninitialised implementation risks in proxies?
With delegatecall, the implementation's code writes to the proxy's storage. If the proxy stores its admin or implementation address in a normal slot, implementation variables can overwrite it, so EIP-1967 uses pseudo-random slots. New implementation versions must only append variables, or use namespaced storage (ERC-7201). Implementations must also disable initialisers in their constructor; otherwise an attacker can initialise the implementation directly, take ownership and, in UUPS, potentially destroy or hijack it.
30
Write the core reward-per-token logic for a staking rewards contract.
EIP-4844, shipped in the Dencun upgrade in March 2024, added blob-carrying transactions. Blobs are large data chunks of about 128 KB that rollups use to post batch data, priced in a separate fee market and pruned by nodes after roughly 18 days. Contracts cannot read blob contents, only their KZG commitments. This cut L2 data costs dramatically. Later upgrades raised blob capacity, and PeerDAS in the Fusaka upgrade lets nodes sample data instead of downloading every blob.
32
You need to send ETH to hundreds of winners. Should you push payments or let them pull?
Prefer pull payments. If a contract pushes ETH in a loop, one recipient that reverts, perhaps a contract without receive, can block everyone, and the loop may exceed the gas limit. With pull payments, the contract records each winner's amount in a mapping and winners call withdraw, which zeroes their balance before sending. This isolates failures and limits reentrancy risk. Push only for small fixed lists using call with a checked result.
33
A user lost funds on our DeFi app due to their own mistake and is angry. How would you handle it?
Situation: a user sent tokens to the contract address directly instead of using deposit, and they were stuck. Task: support him honestly. Action: I listened, explained calmly what happened without blaming him, checked whether a recovery function existed, and escalated to the team. We had a rescue function for stray tokens behind the multisig, so after verification we returned them. Result: he thanked us publicly, and we added a front-end warning.
34
Your exchange credited a deposit, but the block was later dropped in a reorg and the funds vanished. How do you prevent this?
Credit deposits only after enough confirmations for the chain's risk profile, and on Ethereum prefer waiting for finalized or at least safe block tags rather than the latest block. Make the deposit indexer reorg-aware: track block hashes, detect when a parent hash changes, roll back credits from orphaned blocks and reprocess. Scale required confirmations with deposit size, and alert on unusually deep reorgs on smaller chains, which can signal a 51 percent attack.
35
Tell me about working with product, legal or compliance teams on a blockchain feature.
Situation: we planned a token reward feature for Indian users, and legal raised VDA tax and securities concerns. Task: as tech lead I had to find a compliant design. Action: I ran workshops to understand their constraints, proposed non-transferable points that convert to vouchers, and documented the data flow for compliance. Result: we launched a month later than planned but with sign-off from all teams, and avoided a costly redesign after launch.
36
What is signature malleability and how is it prevented?
For any valid ECDSA signature (r, s), the value (r, n - s) is also valid for the same message. If code uses a signature as a unique ID, for example to mark it as used, an attacker can submit the flipped version and replay it. Ethereum's EIP-2 requires s to be in the lower half of the curve order for transactions. In contracts, use a library like OpenZeppelin ECDSA that enforces low s, and track nonces instead of signatures.
37
How do upgradeable contracts work, and how do Transparent and UUPS proxies differ?
A proxy holds the state and delegates every call to an implementation contract whose address is stored in a standard EIP-1967 slot; upgrading means pointing to a new implementation. In the Transparent pattern, upgrade logic lives in the proxy and an admin cannot call implementation functions, which avoids selector clashes. In UUPS, upgrade logic lives in the implementation, making proxies cheaper, but a faulty upgrade can brick it. Both use initialisers instead of constructors and require storage-layout compatibility.
38
How do you handle unclear or changing requirements from a client?
Situation: a client asked for a marketplace dApp but kept changing royalty and fee rules. Task: deliver without endless rework. Action: I wrote a short spec with examples and edge cases, got sign-off, and made fees configurable parameters with limits instead of hard-coded logic. Changes went through a simple change log with impact estimates. Result: we delivered in eight weeks, and later fee changes needed only a governance transaction, not a redeployment.
39
Your dApp's users are paying high gas fees on Ethereum mainnet. How would you choose a Layer 2?
I would compare candidate rollups on security (proof system live, stage of decentralisation, upgrade keys), EVM compatibility so our Solidity code deploys unchanged, ecosystem fit (wallets, oracles, liquidity, bridges our users already use), fees and throughput, and withdrawal experience. I would deploy to testnets first, measure real costs and latency, and check that our dependencies such as Chainlink feeds exist there. Then migrate gradually, keeping L1 contracts for high-value settlement if needed.
40
Tell me about a technical decision you made where you had to balance trade-offs.
Situation: our loyalty-points product needed on-chain points but users would not pay mainnet fees. Task: pick a chain. Action: I compared three rollups and a sidechain on fees, security model, wallet support and bridge maturity, built a quick benchmark, and wrote a one-page decision record with risks. Result: we chose a rollup with live fraud proofs, cut per-transaction cost by over 95 percent, and documented a migration path if our requirements changed.
Frequently asked questions
What is asked in Blockchain interviews for 7 years of experience?
With seven years, you are expected to lead engineering for a protocol or blockchain practice. Discussions centre on long-term architecture, upgrade and governance strategy, risk management, regulatory awareness in India and abroad, and hiring. You should show measurable outcomes, such as secure launches, reduced costs or scaled systems, and explain how you balance speed of delivery with safety.
How many questions should I practise before a Blockchain interview?
Work through all 40 questions here, then the company-wise sets for the employers you are targeting. Quality matters more than count: be able to explain why each answer is right.
Which topics matter most for 7 years of experience?
Focus first on Technical strategy, Governance and upgrades, Regulation and compliance, Hiring and mentoring.