Fatskills
Practice. Master. Repeat.
Study Guide: Blockchain and Web3 Development: Career and Portfolio Web3 Developer Interview Questions and Coding Challenges
Source: https://www.fatskills.com/cryptocurrency-bitcoin-blockchain-and-more/chapter/blockchain-and-web3-development-blockchain-and-web3-development-career-and-portfolio-web3-developer-interview-questions-and-coding-challenges

Blockchain and Web3 Development: Career and Portfolio Web3 Developer Interview Questions and Coding Challenges

By Fatskills Exam Guides Team — the exam nerds behind 28,500+ quizzes and 2.1M practice questions across 500+ global exams.

⏱️ ~5 min read

What This Is

A Web3 developer interview focuses on your ability to design, code, and secure decentralized applications (dApps) that run on the Ethereum Virtual Machine (EVM). Recruiters want proof that you can write Solidity contracts, understand token standards, and reason about gas‑costs and attack surfaces—skills that power real‑world products like a Uniswap swap, an NFT minting portal, or a DAO voting contract.


Key Terms & Code Snippets

  • Solidity ≥ 0.8.0 – The mainstream smart‑contract language. pragma solidity ^0.8.18; enables built‑in overflow checks, removing the need for SafeMath.
  • EVM (Ethereum Virtual Machine) – The sandbox that executes bytecode. Every transaction consumes gas, a unit that measures computational work.
  • ERC‑20 – The fungible token interface (totalSupply, balanceOf, transfer, allowance, approve, transferFrom).

solidity contract MyToken is ERC20 {
constructor() ERC20("MyToken", "MTK") {
_mint(msg.sender, 1_000_000 * 10decimals());
} }


  • ERC‑721 – The non‑fungible token (NFT) standard. Includes ownerOf, safeTransferFrom, and a tokenURI metadata hook.
  • Reentrancy Attack – When a contract calls an external address that re‑enters the vulnerable contract before state changes are finalized. Mitigate with checks‑effects‑interactions or nonReentrant from OpenZeppelin.

solidity function withdraw(uint256 amount) external nonReentrant {
require(balances[msg.sender] >= amount, "Insufficient");
balances[msg.sender] -= amount; // effect
(bool ok,) = msg.sender.call{value: amount}("");
require(ok, "Transfer failed"); }


  • Delegatecall – Executes code from another contract in the context of the caller, preserving msg.sender and storage. Used for upgradeable proxies; misuse can lead to storage‑collision bugs.
  • AMM (x * y = k) – Constant‑product formula behind Uniswap V2. Swaps preserve the invariant k; price impact grows with trade size.

solidity // Simplified swap: dy = y - k/(x+dx) function getAmountOut(uint256 amountIn, uint256 reserveIn, uint256 reserveOut)
internal pure returns (uint256) {
uint256 amountInWithFee = amountIn * 997; // 0.3% fee
uint256 numerator = amountInWithFee * reserveOut;
uint256 denominator = reserveIn * 1000 + amountInWithFee;
return numerator / denominator; }


  • Gas‑Optimization Pattern – Packing – Store multiple uint8/bool values in a single uint256 slot to cut gas.

solidity struct Packed {
uint128 a; // 128 bits
uint128 b; // 128 bits → same storage slot }


  • Hardhat – A development environment that compiles, tests, and deploys contracts. npx hardhat compilenpx hardhat run scripts/deploy.js --network goerli.
  • Ethers.js Provider/Signer – JavaScript objects that read blockchain state (provider.getBlockNumber()) and sign transactions (signer.sendTransaction(tx)).
  • Optimistic Rollup vs. ZK Rollup – Layer‑2 scaling solutions. Optimistic assumes transactions are valid unless disputed; ZK publishes succinct proofs that verify correctness off‑chain.


Step‑by‑Step / Process Flow

  1. Write the contract – Open Remix or VS Code, create MySwap.sol with the AMM logic.
  2. Compile & test – Run npx hardhat compile and write unit tests in test/MySwap.test.js using chai + ethers.
  3. Deploy to a testnet
    bash
    npx hardhat run scripts/deploy.js --network goerli \
    --private-key $PRIVATE_KEY --infura-id $INFURA_ID
  4. Verify on Etherscannpx hardhat etherscan-verify --network goerli <CONTRACT_ADDRESS> to make the source public.
  5. Interact from the front‑end – In React, instantiate an ethers.Contract with the ABI and the deployed address, then call swapExactTokensForTokens(...).

Common Mistakes

  • Mistake: Using tx.origin for access control.
    Correction: Always rely on msg.sender; tx.origin can be spoofed through a malicious contract, breaking the permission model.

  • Mistake: Forgetting to reset allowance before changing it (ERC‑20 race condition).
    Correction: Either set allowance to 0 first or use increaseAllowance/decreaseAllowance from OpenZeppelin to avoid the “double‑spend” window.

  • Mistake: Hard‑coding the owner address in the constructor, making upgrades impossible.
    Correction: Deploy via a proxy pattern (e.g., TransparentUpgradeableProxy) and store the admin in a separate storage slot.

  • Mistake: Ignoring unchecked external calls (call without verifying the return value).
    Correction: Always check the boolean success flag (require(success, "Call failed")) or use Address.functionCall from OpenZeppelin.

  • Mistake: Over‑using public state variables for sensitive data.
    Correction: Keep variables private/internal and expose only read‑only getters; this reduces accidental external reads and future upgrade collisions.


Blockchain Developer Interview / Practical Insights

  1. “Explain the difference between call and delegatecall.” Interviewers expect you to discuss context (storage, msg.sender) and typical use‑cases (proxy upgrades vs. external calls).
  2. “When would you choose ERC‑777 over ERC‑20?” Highlight ERC‑777’s hooks (tokensReceived) and built‑in operator functionality, useful for advanced DeFi composability.
  3. “How do you mitigate front‑running in a DEX?” Mention techniques like commit‑reveal, time‑weighted average price (TWAP) oracles, and slippage limits.
  4. “What’s the gas‑cost impact of using require vs. assert?” require refunds remaining gas, while assert consumes all gas and signals a bug; auditors look for assert only on internal invariants.

Quick Check Questions

  1. Scenario: A contract uses tx.origin to restrict withdrawals to the contract deployer.
    Answer: Dangerous – a phishing contract can call the vulnerable contract, making tx.origin the attacker’s address, and steal funds.

  2. Scenario: You see a function marked external payable that forwards all received ether with address(this).call{value: amount}("").
    Answer: This pattern is a reentrancy risk; the contract should first update its internal balance before forwarding ether, or use ReentrancyGuard.

  3. Scenario: A DeFi pool’s addLiquidity function does not emit an event.
    Answer: Missing events hinder indexing and off‑chain analytics; auditors will flag it as a visibility/monitoring issue.


Last‑Minute Cram Sheet (10 one‑liners)

  1. ⚠️ Never trust tx.origin for auth – it can be hijacked via a malicious contract.
  2. nonReentrant (OpenZeppelin) = one‑line guard against reentrancy.
  3. pragma solidity ^0.8.x; gives automatic overflow/underflow checks; no need for SafeMath.
  4. ERC‑20 decimals() is usually 18; token amounts are stored as uint256 with 10¹⁸ scaling.
  5. delegatecall shares storage; always align storage layout when upgrading.
  6. Packing uint128 + uint128 into one slot saves ~15 % gas per write.
  7. Uniswap V2 fee = 0.3 % → multiply input by 997, denominator by 1000.
  8. Hardhat --network goerli automatically uses the Infura endpoint if ETHERSCAN_API_KEY is set.
  9. ZK Rollups verify proofs on‑chain; Optimistic Rollups rely on fraud proofs (challenge window).
  10. Top attack vectors: Reentrancy, unchecked external calls, storage collisions, and front‑running (MEV).


ADVERTISEMENT