50 Web3 Technical Interview Questions & How to Answer Them

Web3 technical interviews don't follow the FAANG playbook. You won't be reversing linked lists or calculating Big-O complexity on a whiteboard. Instead, you'll face domain-specific questions that test your understanding of smart contracts, DeFi mechanics, security vulnerabilities, frontend integration patterns, and system architecture in a blockchain context.

We compiled the 50 most commonly asked technical questions from hiring managers across DeFi protocols, L2 infrastructure companies, security firms, and crypto exchanges. For each question, we provide a brief answer framework — the key points you should hit and the depth interviewers expect.

These questions reflect what the State of Web3 Hiring 2026 report identifies as the core competencies companies are evaluating. Use this as a study guide, not a script — interviewers can tell when someone has memorized an answer versus when they genuinely understand the concept.

Solidity Fundamentals (Questions 1-10)

1. What's the difference between memory, storage, and calldata?

Difficulty: Easy

Key points to hit:

• storage is persistent on-chain data — it's the contract's state that lives between function calls and costs significant gas to read and write
• memory is temporary data that exists only during function execution and is wiped after the function returns
• calldata is read-only, non-modifiable data location for function parameters in external functions — more gas-efficient than memory because it avoids copying
• Mention the gas implications: storage writes are ~20,000 gas for new slots, memory is much cheaper, calldata is cheapest

2. Explain the proxy pattern. What are the tradeoffs between UUPS and Transparent proxies?

Difficulty: Medium

Key points to hit:

• Proxy pattern separates logic from storage using delegatecall, enabling contract upgradeability
• Transparent proxy: Admin calls go to proxy logic, user calls go to implementation. Pro: clear separation of admin vs user. Con: extra gas for every call (admin check), proxy contract is more complex
• UUPS (Universal Upgradeable Proxy Standard): Upgrade logic lives in the implementation contract. Pro: cheaper calls (no admin check in proxy), simpler proxy. Con: if you deploy an implementation without upgrade logic, the contract is permanently frozen
• Mention storage collision risks and the importance of using unstructured storage patterns (EIP-1967 slots)

3. How does delegatecall work, and what are its security implications?

Difficulty: Medium

Key points to hit:

• delegatecall executes another contract's code in the context of the calling contract — same msg.sender, same msg.value, same storage
• Storage layout must match between proxy and implementation, or you'll get storage collision bugs
• Security risk: if the implementation contract has a selfdestruct or modifies storage in unexpected ways, it operates on the proxy's storage
• Reference the Parity wallet hack as a historical example of delegatecall misuse

4. What are the differences between require, revert, and assert?

Difficulty: Easy

Key points to hit:

• require validates inputs and conditions — reverts with remaining gas refunded, supports custom error messages
• revert explicitly reverts execution — can be used with custom errors (revert CustomError()) which are more gas-efficient than string messages
• assert is for invariant checking — should only fail if there's a bug in the code. Historically consumed all gas, but post-Solidity 0.8.0 it also refunds remaining gas
• Best practice: use custom errors with revert for gas efficiency, require for input validation, assert sparingly for internal invariants

5. Explain how events work in Solidity. When would you use indexed parameters?

Difficulty: Easy

Key points to hit:

• Events emit data to the transaction log — they're stored in the blockchain but not accessible to smart contracts
• indexed parameters (up to 3 per event) are stored as topics, enabling efficient filtering and searching
• Non-indexed parameters are ABI-encoded in the data field
• Use indexed for values you'll query by (addresses, IDs). Don't index large data types (strings, bytes) as only the keccak256 hash is stored
• Events are significantly cheaper than storage for data that only needs to be read off-chain

6. How does the EVM handle integer overflow and underflow?

Difficulty: Easy

Key points to hit:

• Pre-Solidity 0.8.0: arithmetic silently wrapped around (0 - 1 = 2^256 - 1). Required SafeMath library for protection
• Solidity 0.8.0+: built-in overflow/underflow checks that revert on overflow. No more SafeMath needed
• unchecked {} blocks can disable these checks for gas optimization when overflow is impossible (e.g., loop counters)
• Security note: be careful when using unchecked — only use it when you can mathematically prove overflow is impossible

7. What is the fallback function? How does it differ from the receive function?

Difficulty: Easy

Key points to hit:

• receive() is called when the contract receives ETH with empty calldata (plain transfers, send(), transfer())
• fallback() is called when no function matches the call signature, or when ETH is sent with data
• If receive() doesn't exist, fallback() handles ETH transfers (if it's payable)
• Security consideration: both should be minimal — complex logic in fallback/receive can cause reentrancy issues and unexpected failures due to the 2300 gas stipend from transfer()/send()

8. Explain struct packing and how it affects gas costs.

Difficulty: Medium

Key points to hit:

• EVM uses 32-byte storage slots. Multiple smaller variables can be packed into a single slot
• Variables are packed in order of declaration — uint128, uint128 fits in one slot, but uint128, uint256, uint128 uses three slots
• Packing saves ~20,000 gas per slot saved on first writes (SSTORE to non-zero)
• Trade-off: packed reads require bit masking, which adds a small gas overhead. For frequently read values, sometimes unpacked is better
• Best practice: group smaller types together in struct definitions

9. What are function selectors and how does the EVM route function calls?

Difficulty: Medium

Key points to hit:

• Function selector is the first 4 bytes of the keccak256 hash of the function signature (e.g., transfer(address,uint256))
• When a contract receives a call, the EVM matches the first 4 bytes of calldata against known selectors
• Selector collision: two functions can theoretically have the same 4-byte selector. The compiler prevents this within a single contract, but it's relevant for proxy patterns
• This is why function signature matters for ABI encoding and interface compatibility

10. Explain the CREATE2 opcode. What are its use cases and risks?

Difficulty: Hard

Key points to hit:

• CREATE2 deploys a contract to a deterministic address calculated from: keccak256(0xff ++ deployer ++ salt ++ keccak256(bytecode))
• Use cases: counterfactual deployment (knowing an address before deployment), factory patterns, meta-transactions, and Layer 2 deployment strategies
• Risk: if a contract at a CREATE2 address is destroyed, a new contract with different bytecode could be deployed to the same address (if the factory allows it), potentially tricking users who trusted the original code
• Used extensively in account abstraction (ERC-4337) for counterfactual wallet deployment

DeFi Concepts (Questions 11-20)

11. How does a constant-product AMM (like Uniswap v2) work?

Difficulty: Medium

Key points to hit:

• Core invariant: x * y = k where x and y are the reserves of two tokens
• Swaps move along the curve: adding token A means removing token B, maintaining the invariant (minus fees)
• Price impact increases with trade size relative to pool depth
• LP fees (0.3% in Uniswap v2) are added to reserves, growing k over time
• Explain slippage, price impact, and the relationship between pool size and execution quality

12. What is impermanent loss, and when does it become permanent?

Difficulty: Medium

Key points to hit:

• Impermanent loss occurs when the price ratio of pooled tokens changes from the ratio at deposit time
• The LP's position is worth less than if they had simply held the tokens
• Formula: for a price change of r, the loss is 2*sqrt(r)/(1+r) - 1
• It becomes "permanent" when you withdraw liquidity at a different price ratio
• Mitigated by: high trading fees, concentrated liquidity ranges (Uniswap v3/v4), or pools of correlated assets (stableswap)

13. Explain how flash loans work. Walk through a potential use case.

Difficulty: Medium

Key points to hit:

• Flash loans allow borrowing any amount of tokens within a single transaction, with the constraint that the loan must be repaid (plus fees) before the transaction ends
• If repayment fails, the entire transaction reverts — no collateral needed because atomicity eliminates credit risk
• Use case walkthrough: arbitrage between two DEXes — borrow 1000 ETH from Aave, swap to USDC on DEX A (higher price), swap back to ETH on DEX B (lower price), repay loan + fee, keep profit
• Other use cases: collateral swaps, self-liquidation, governance attacks (flash loan voting power)
• Security consideration: protocols must be designed to resist flash loan manipulation of price oracles

14. What is an oracle manipulation attack? How do protocols defend against it?

Difficulty: Hard

Key points to hit:

• Oracle manipulation occurs when an attacker artificially moves the price reported by an oracle to exploit a protocol (e.g., inflate collateral value to borrow more than it's worth)
• Spot price oracles (single-block DEX prices) are easily manipulable via flash loans
• Defenses: time-weighted average prices (TWAPs), Chainlink price feeds (off-chain aggregation), multiple oracle sources, circuit breakers for extreme price movements
• Mention specific examples: Euler Finance exploit, Mango Markets manipulation

15. How does a lending protocol handle liquidations?

Difficulty: Medium

Key points to hit:

• Borrowers must maintain a health factor (collateral value / borrow value) above a threshold (e.g., 1.0)
• When health factor drops below threshold, the position becomes liquidatable
• Liquidators repay part of the debt and receive the corresponding collateral plus a liquidation bonus (typically 5-10%)
• Liquidation incentive design is critical: too low and no one liquidates (bad debt), too high and borrowers lose excessive value
• Cascading liquidations during market crashes are a systemic risk — mention Aave's safety module and bad debt handling

16. Explain concentrated liquidity (Uniswap v3/v4).

Difficulty: Hard

Key points to hit:

• LPs provide liquidity within a specific price range instead of across the entire curve
• Capital efficiency: concentrated liquidity in a narrow range provides more depth than the same capital spread across all prices
• Tick system: the price range is divided into discrete ticks. Liquidity is only active when the current price is within an LP's range
• Trade-off: higher impermanent loss if price moves outside your range, requires active management
• v4 hooks extend this with programmable logic at various points in the swap lifecycle

17. What are the key differences between optimistic and ZK rollups?

Difficulty: Medium

Key points to hit:

• Optimistic rollups (Arbitrum, Optimism, Base): assume transactions are valid, allow a challenge period (~7 days) for fraud proofs. Simpler to build, EVM-compatible, but longer withdrawal times
• ZK rollups (zkSync, Starknet, Scroll): generate cryptographic proofs of validity. Faster finality, no challenge period needed, but more complex to build and historically harder to achieve full EVM equivalence
• Current state: optimistic rollups have broader adoption and EVM compatibility. ZK rollups are catching up on compatibility and are the likely long-term winner for performance
• Mention the trust assumptions, data availability requirements, and the role of sequencers

18. How does EIP-4337 (Account Abstraction) work?

Difficulty: Hard

Key points to hit:

• Separates account logic from the protocol level, allowing smart contract wallets with custom validation logic
• Key components: UserOperations (pseudo-transactions), Bundlers (package UserOps into transactions), EntryPoint contract (validates and executes), Paymasters (sponsor gas for users)
• Enables: social recovery, multi-sig with flexible policies, session keys, gasless transactions, batched operations
• Implications for developers: new UX patterns, different transaction flow, paymaster integration

19. What is MEV (Maximal Extractable Value)?

Difficulty: Medium

Key points to hit:

• MEV is the profit that block producers (or searchers) can extract by reordering, inserting, or censoring transactions within a block
• Common forms: DEX arbitrage, sandwich attacks (front-run + back-run around a victim's swap), liquidation sniping
• Impact on users: worse execution prices, higher effective costs
• Mitigations: Flashbots, MEV-protected RPC endpoints, intent-based trading (CoW Protocol), encrypted mempools
• Protocol design considerations: building MEV-resistant mechanisms (batch auctions, time-weighted fills)

20. Explain the concept of composability in DeFi and its risks.

Difficulty: Medium

Key points to hit:

• Composability: DeFi protocols can be combined like building blocks — use Aave deposits as collateral in MakerDAO, use LP tokens as collateral for borrowing
• Benefits: capital efficiency, innovation without permission, complex strategies from simple primitives
• Risks: systemic risk (failure in one protocol cascades), oracle dependencies across protocols, smart contract risk multiplication (your risk = product of all protocols' risk)
• The "money legos" narrative is powerful but the interconnected risk is often underestimated

Security & Auditing (Questions 21-30)

21. What is a reentrancy attack? How do you prevent it?

Difficulty: Easy

Key points to hit:

• Reentrancy occurs when an external call allows the called contract to call back into the calling contract before the first invocation is complete
• Classic example: withdraw function sends ETH before updating balance, attacker's receive function calls withdraw again
• Prevention: Checks-Effects-Interactions pattern (update state before external calls), reentrancy guards (OpenZeppelin's ReentrancyGuard), pull payment pattern
• Mention cross-function and cross-contract reentrancy as more subtle variants
• Reference the DAO hack (2016) as the canonical historical example

22. Explain the difference between access control vulnerabilities and what patterns prevent them.

Difficulty: Easy

Key points to hit:

• Missing access control: critical functions (withdraw, upgrade, pause) without proper permission checks
• Common patterns: OpenZeppelin's Ownable (single admin), AccessControl (role-based), multi-sig requirements for sensitive operations
• Subtle issues: tx.origin vs msg.sender for authentication (never use tx.origin), missing modifiers on implementation contracts in proxy patterns
• Best practice: principle of least privilege, time-locked admin actions, multi-sig for irreversible operations

23. What are the security implications of using delegatecall with user-supplied addresses?

Difficulty: Hard

Key points to hit:

• delegatecall to an arbitrary address lets the attacker execute any code in the context of your contract — full storage access, can drain funds, can selfdestruct
• This is effectively giving an attacker root access to your contract
• Proxy patterns must restrict which implementation address is used
• Reference: Parity multi-sig wallet vulnerability where the library contract was initialized by an attacker and then self-destructed

24. How would you identify and prevent oracle manipulation in a smart contract?

Difficulty: Hard

Key points to hit:

• Check what oracle is used — spot prices from DEXes are manipulable, especially via flash loans
• Look for price-dependent operations: borrowing, liquidation, minting based on collateral values
• Mitigations: use TWAP with sufficient window (at least 30 minutes), use Chainlink or other decentralized oracle networks, implement price deviation checks, use multiple oracle sources with medianization
• Check for stale price handling — what happens if the oracle stops updating?

25. What is a sandwich attack and how can protocols mitigate it?

Difficulty: Medium

Key points to hit:

• Attacker sees a pending swap in the mempool, front-runs it (buys before the victim, pushing price up), lets the victim's swap execute at a worse price, then back-runs (sells after the victim)
• The attacker profits from the price impact they created at the victim's expense
• Mitigations: slippage protection (max acceptable price impact), private mempools (Flashbots Protect), intent-based DEXes (CoW Protocol), on-chain commit-reveal schemes, MEV-aware AMM designs
• Protocol design: batch auctions (all trades in a batch execute at the same price) eliminate sandwich opportunities

26. Explain the security considerations for upgradeable contracts.

Difficulty: Medium

Key points to hit:

• Storage layout compatibility: new implementation must maintain the same storage layout as the old one (can only append new variables)
• Initialization: upgradeable contracts use initialize() instead of constructors — must use initializer modifier to prevent re-initialization
• Implementation contract security: the implementation should be initialized or have _disableInitializers() to prevent direct initialization
• Admin key management: whoever controls the upgrade function controls the contract. Multi-sig or timelock is essential
• Testing: test upgrade paths, not just individual implementations

27. What is a front-running vulnerability, and how does it differ from MEV?

Difficulty: Medium

Key points to hit:

• Front-running: an attacker observes a pending transaction and submits their own with higher gas to execute first
• MEV is the broader category — it includes front-running but also back-running, sandwich attacks, arbitrage, and liquidation
• In smart contracts, front-running vulnerabilities exist when the outcome of a transaction depends on its ordering relative to other transactions
• Common vulnerable patterns: commit-reveal schemes with insufficient entropy, approval/permit race conditions, first-come-first-served mechanisms
• Protocol mitigations: commit-reveal with deadlines, threshold encryption, private mempools

28. How do you audit for gas griefing attacks?

Difficulty: Hard

Key points to hit:

• Gas griefing: an attacker causes a victim's transaction to consume excessive gas or fail by manipulating the state or return data
• Examples: returning large data from a callback to force the caller to pay for memory expansion, creating many small positions to make iteration expensive, pushing a loop past the block gas limit
• Look for: unbounded loops over user-controlled arrays, external calls where the callee can consume arbitrary gas, patterns where attacker can grow data structures that other functions iterate over
• Mitigations: gas limits on external calls, pagination patterns, pull over push for payments

29. What are the risks of using transfer() or send() for ETH transfers?

Difficulty: Easy

Key points to hit:

• Both forward only 2300 gas to the recipient — not enough for the recipient to execute meaningful logic
• Problem: smart contract wallets (multi-sigs, account abstraction wallets) often need more than 2300 gas in their receive function. transfer() and send() will fail for these recipients
• After EIP-1884 (Istanbul hard fork), gas costs for some opcodes increased, making the 2300 gas limit even more restrictive
• Best practice: use call{value: amount}("") with a reentrancy guard instead
• Always check the return value of call

30. Explain what a storage collision is in the context of proxy contracts.

Difficulty: Medium

Key points to hit:

• In proxy patterns, the proxy and implementation share the same storage space (because of delegatecall)
• If both contracts declare variables that map to the same storage slots, they'll overwrite each other
• EIP-1967 defines specific storage slots (based on keccak256 hashes minus 1) for proxy admin and implementation address to avoid collisions with implementation storage
• Example: if the proxy stores its admin address at slot 0, and the implementation's first variable also uses slot 0, writing to either corrupts the other
• Unstructured storage patterns (using keccak256 of a unique string as the slot) prevent collisions

Frontend & Web3 Integration (Questions 31-40)

31. How do you handle wallet connection across multiple chains?

Difficulty: Medium

Key points to hit:

• Modern approach: use wagmi/viem with WalletConnect or similar multi-chain connector
• Chain switching: wallet_switchEthereumChain RPC method, with wallet_addEthereumChain as fallback for unknown chains
• State management: track connected chain ID, handle chain changes reactively, show appropriate UI for unsupported chains
• Account abstraction consideration: smart contract wallets may exist on some chains but not others — handle this edge case
• UX pattern: let users switch chains within the app rather than forcing manual wallet switching

32. Explain the difference between a signed message and a transaction.

Difficulty: Easy

Key points to hit:

• A signed message (via personal_sign or EIP-712 typed data) proves the signer controls an address without submitting anything on-chain. No gas cost, no state change
• A transaction is a state-changing operation submitted to the network that costs gas and is included in a block
• Use cases for signed messages: authentication (Sign-In with Ethereum), off-chain approvals (permit signatures for ERC-2612), meta-transactions, order signing for off-chain order books
• EIP-712 provides structured, human-readable signing that prevents replay attacks across contracts and chains

33. How do you implement gasless transactions (meta-transactions)?

Difficulty: Hard

Key points to hit:

• User signs a message containing the transaction data (no gas spent)
• A relayer submits the actual transaction on the user's behalf, paying gas
• Contract validates the user's signature and executes the intended operation
• Standards: ERC-2771 (trusted forwarder pattern), EIP-2612 (permit for ERC-20 approvals), ERC-4337 paymasters
• Implementation choices: GSN (Gas Station Network), Gelato Relay, Biconomy, or custom relayer infrastructure
• Security: prevent replay attacks with nonces, validate the forwarder address, handle msg.sender correctly (use _msgSender() from ERC-2771)

34. How do you display real-time on-chain data without excessive RPC calls?

Difficulty: Medium

Key points to hit:

• Event-based updates: subscribe to contract events via WebSocket connections (eth_subscribe) and update UI reactively
• Polling with intelligent intervals: poll critical data frequently (every block), non-critical data less often (every 30-60 seconds)
• Multicall: batch multiple read calls into a single RPC request using Multicall3 contract
• Caching: use React Query (TanStack Query) or SWR with appropriate stale times. wagmi has built-in caching
• Indexers: for historical data, use The Graph subgraphs or similar indexing services instead of scanning blocks via RPC
• Trade-off: real-time accuracy vs RPC costs. Most UIs don't need block-by-block updates for every piece of data

35. What happens when a user sends a transaction and closes the browser?

Difficulty: Easy

Key points to hit:

• The transaction has already been signed and submitted to the mempool — closing the browser doesn't cancel it
• The transaction will be mined (or eventually dropped) regardless of the client state
• Challenge: the UI loses track of the pending transaction
• Solutions: persist pending transaction hashes in localStorage, use a service worker to track status, or query the chain for the user's nonce to detect completed transactions on next visit
• Good UX: show transaction status on return, handle stuck/dropped transactions gracefully

36. How would you implement a token approval flow with good UX?

Difficulty: Medium

Key points to hit:

• Traditional: two transactions — approve() then the actual operation. Bad UX because users have to sign twice and pay gas twice
• Better: EIP-2612 permit() — user signs a typed message (no gas), contract uses the permit signature to set the approval atomically. One transaction, better UX
• Even better: batch approve + operation in a single transaction via account abstraction (ERC-4337)
• Always show the user what they're approving, the amount, and the spender. Never request unlimited approvals without clear explanation
• Handle the case where approval already exists (don't ask again)

37. Explain how you'd build error handling for failed transactions.

Difficulty: Medium

Key points to hit:

• Simulate the transaction before sending (eth_estimateGas or eth_call) to catch reverts early and show the user a clear error before they sign
• Decode revert reasons from custom errors — parse the error selector and parameters
• Common failure modes: insufficient balance, slippage exceeded, approval expired, nonce too low, gas price too low
• UX: show human-readable error messages, suggest corrective actions (increase slippage, approve more tokens, retry with higher gas)
• Differentiate between user rejections (they clicked "Reject" in wallet) and on-chain failures

38. How do you handle chain reorganizations in a frontend?

Difficulty: Hard

Key points to hit:

• Reorgs occur when a block that was initially accepted is replaced by a competing block — transactions in the original block may be dropped
• Frontend impact: a transaction you showed as "confirmed" may become unconfirmed
• Strategy: wait for multiple confirmations before showing finality (12+ blocks on Ethereum mainnet, fewer on L2s with faster finality)
• Implementation: track transaction by hash, re-check confirmation count, handle the case where a transaction disappears
• L2 consideration: optimistic rollups have a 7-day challenge period for finality; ZK rollups finalize when proofs are posted to L1

39. How do you securely handle private keys or sensitive data in a frontend application?

Difficulty: Easy

Key points to hit:

• Never store private keys in the frontend. Period. That's what wallets are for
• Sensitive data (API keys for RPC providers, etc.) should be server-side, not in client-side environment variables
• Use wallet connections (WalletConnect, injected providers) for all signing operations — the private key never leaves the wallet
• For server-side signing (bots, backend services): use hardware security modules (HSMs), encrypted key management services (AWS KMS, GCP Cloud KMS), or dedicated signing services
• Never log or transmit signed messages or transaction data that could be replayed

40. How would you implement Sign-In with Ethereum (SIWE)?

Difficulty: Medium

Key points to hit:

• SIWE (EIP-4361) authenticates users by having them sign a structured message with their wallet
• Flow: server generates a nonce, frontend constructs a SIWE message including domain, nonce, and statement, user signs with wallet, server verifies the signature and creates a session
• Security: validate the domain matches your app (prevents phishing), check nonce to prevent replay, implement session expiry
• Libraries: siwe package handles message construction and verification
• Consideration for smart contract wallets: use ERC-1271 to verify signatures from contract wallets (not just EOAs)

System Design & Architecture (Questions 41-50)

41. Design a decentralized exchange (DEX) architecture.

Difficulty: Hard

Key points to hit:

• Core contracts: Router (handles swaps and routing), Factory (deploys pair contracts), Pair/Pool (holds liquidity and executes swaps)
• Discuss AMM model choice (constant product, concentrated liquidity, order book) and tradeoffs
• Periphery considerations: price oracle integration, multi-hop routing, flash swaps
• Frontend architecture: real-time price updates, transaction simulation, slippage calculation
• Infrastructure: subgraph for historical data, price feeds, analytics
• Security: access control, pause functionality, audit requirements, governance for parameter changes

42. How would you design a cross-chain bridge?

Difficulty: Hard

Key points to hit:

• Core challenge: verifying that an event on chain A actually happened, from the perspective of chain B
• Approaches: light client verification, optimistic with fraud proofs, committee/multi-sig attestation, ZK proof of state
• Token model: lock-and-mint (lock on source, mint wrapped on destination) vs burn-and-mint (native bridge tokens)
• Security: the bridge is only as secure as its weakest verification mechanism. Discuss the trust assumptions of each approach
• Liveness and failure handling: what happens if validators go offline? How do users recover funds?
• Reference recent bridge exploits (Wormhole, Ronin) and what went wrong

43. Design an NFT marketplace with royalty enforcement.

Difficulty: Medium

Key points to hit:

• Core contracts: marketplace (listing, bidding, settlement), royalty registry (ERC-2981 for on-chain royalty info)
• Royalty enforcement challenge: royalties are only enforceable when trades go through your marketplace. Direct transfers bypass royalty payment
• Solutions: operator filterer (block marketplaces that don't enforce royalties), soul-bound trading (limit transfers to approved contracts), social consensus
• Auction mechanisms: English auction, Dutch auction, reserve price
• Off-chain components: metadata indexing, image storage (IPFS/Arweave), search and discovery
• Gas optimization: lazy minting, off-chain order books with on-chain settlement

44. Design a DAO governance system with delegation and timelocked execution.

Difficulty: Hard

Key points to hit:

• Core components: governance token (with voting power snapshots), governor contract (proposal lifecycle), timelock (delayed execution for safety)
• Proposal lifecycle: propose, voting period, queue (if passed), timelock delay, execute
• Delegation: users delegate voting power without transferring tokens. Snapshot at proposal creation prevents flash loan governance attacks
• Security considerations: proposal threshold (minimum tokens to propose), quorum requirements, timelock delays, emergency shutdown mechanisms
• Advanced: optimistic governance (proposals pass unless vetoed), on-chain vs off-chain voting (Snapshot + on-chain execution)

45. How would you design a vault system for yield aggregation?

Difficulty: Hard

Key points to hit:

• Core pattern: ERC-4626 tokenized vault standard — users deposit assets, receive share tokens, vault deploys capital to strategies
• Strategy architecture: separate strategy contracts that implement a standard interface, swappable by governance
• Key mechanics: deposit/withdraw, share price calculation, harvest (claim rewards and reinvest), performance fees
• Risk management: strategy allocation limits, emergency withdrawal, loss reporting
• Gas optimization: batched harvests, lazy accounting where possible
• Security: strategy whitelisting, migration paths, slippage protection on swaps during harvest

46. Design an on-chain order book.

Difficulty: Hard

Key points to hit:

• Challenge: fully on-chain order books are gas-intensive due to sorting and matching
• Architecture: use a red-black tree or sorted linked list for price levels, FIFO within each level
• Matching engine: process incoming orders against the book, emit fill events
• Alternative: hybrid model — off-chain order book with on-chain settlement (similar to dYdX v3, 0x protocol)
• Gas considerations: batch matching, off-chain matching with on-chain verification
• Discuss tradeoffs: fully on-chain (censorship resistant but expensive) vs hybrid (cheaper but requires trust in the off-chain component)

47. Design a token vesting system with multiple beneficiaries and cliffs.

Difficulty: Medium

Key points to hit:

• Core contract: holds total token allocation, tracks vesting schedules per beneficiary
• Vesting parameters: total amount, start time, cliff duration, vesting duration, revocability
• Claim mechanic: beneficiaries call claim() to receive vested-but-unclaimed tokens. Calculate vested amount based on time elapsed
• Edge cases: cliff period (nothing vests until cliff is reached, then cliff amount vests instantly), early termination (revocable grants), token transfer during vesting
• Gas optimization: calculate vested amount on-the-fly rather than storing per-period data
• Admin controls: add/remove beneficiaries, revoke unvested tokens, emergency pause

48. How would you design a multi-chain deployment and management system?

Difficulty: Hard

Key points to hit:

• Deterministic deployments: use CREATE2 for consistent addresses across chains
• Configuration management: chain-specific parameters (gas tokens, oracle addresses, bridge endpoints) managed through a deployment framework
• Cross-chain governance: admin actions on one chain propagated to others via bridge messages
• Monitoring: unified dashboard tracking contract state, TVL, and events across all chains
• Upgrade coordination: deploy new implementations on all chains before switching proxies
• Tools: Foundry scripts for deployment, Safe multi-sig for admin, custom monitoring infrastructure

49. Design a decentralized identity and reputation system.

Difficulty: Medium

Key points to hit:

• Core components: attestation registry (who vouches for what), resolver (translate queries into reputation scores), revocation mechanism
• Attestation model: EAS-style (flexible schema, on-chain or off-chain attestations) or SBT-style (soul-bound tokens representing credentials)
• Privacy consideration: how to prove reputation without revealing all underlying data (ZK proofs for selective disclosure)
• Composability: reputation should be queryable by other contracts (lending protocols using reputation for undercollateralized loans)
• Challenges: Sybil resistance, attestation quality, cross-chain identity

50. Design a system for real-time protocol monitoring and alerting.

Difficulty: Medium

Key points to hit:

• Data sources: on-chain events (via WebSocket subscriptions), mempool monitoring (pending transactions), oracle price feeds
• Processing pipeline: event ingestion, normalization, rule evaluation, alert dispatch
• Alert types: large withdrawals, governance proposals, price deviations, contract upgrades, unusual gas usage, known attack patterns
• Architecture: event listener nodes, message queue (Kafka/Redis), rule engine, notification service (Telegram, Discord, PagerDuty)
• Latency requirements: mempool monitoring needs sub-second latency for MEV protection; event monitoring can tolerate block-time delays
• Reference existing tools: OpenZeppelin Defender, Forta Network, custom monitoring stacks

How to Use This Guide

Don't try to memorize these answers. Instead:

1. Identify your gaps — Go through each category and honestly assess which questions you can answer confidently. Focus your study time on the gaps
2. Build depth, not breadth — For each concept, go deeper than the answer framework here. Read the actual EIPs, look at real protocol code, understand the historical context
3. Practice out loud — Technical communication matters. Practice explaining these concepts verbally, as if you're in an interview. Time yourself — you should be able to give a solid answer in 2-3 minutes
4. Build reference projects — The best way to solidify your understanding is to implement the concepts. Build a small lending protocol to understand liquidations. Deploy a UUPS proxy to understand upgradeability
5. Pair with your resume — Every strong answer should connect to something in your portfolio. "I know about reentrancy guards because I implemented one in this contract" is more convincing than theoretical knowledge

Conclusion

These 50 questions cover the core technical ground that Web3 interviews test. The specific questions you'll encounter will vary by company, role, and seniority level, but the underlying concepts are consistent. If you can speak confidently and specifically about Solidity mechanics, DeFi primitives, security patterns, frontend integration, and system architecture, you're well-prepared for the technical stages of any Web3 interview.

The technical interview is one part of the process. Pair your preparation with a strong portfolio and a well-structured resume, and you'll enter every interview with confidence.

Explore open roles on gm.careers.