Blockchain

Blockchain Interviews (FAANG)

In 2024, the average salary of a Senior Blockchain Engineer at FAANG was $350-500K total compensation. Coinbase, a16z crypto, Paradigm, and Jump Crypto pay even more. Yet the blockchain interview pass rate is under 15%, because candidates prepare as for a regular software engineering interview. They grind LeetCode but cannot explain why Tendermint halts under a network partition while Bitcoin does not. They write Solidity but miss reentrancy in code review. They design systems but put the order book on the blockchain. This lesson is concentrated preparation: four types of questions asked in blockchain interviews, with model answers at the Staff Engineer level.

  • **Coinbase** (Backend/Blockchain Engineer): rounds on Consensus + System Design ("Design our custody solution for institutional clients") + Coding (Solidity/Go). Pass rate ~12% for Senior+
  • **a16z crypto / Paradigm**: deep security questions ("audit this DeFi protocol") and protocol design. Expect research-level understanding of consensus and MEV
  • **Jump Crypto / Wintermute**: focus on performance - latency-sensitive systems, MEV extraction, cross-chain arbitrage. System Design with strict latency requirements (<10ms)

Предварительные знания

  • Blockchain System Design (FAANG)

Consensus: Questions and Answer Frameworks

In blockchain interviews at FAANG and major Web3 companies (Coinbase, Consensys, a16z crypto), consensus questions are a first-level filter. The interviewer is not checking your ability to implement Raft from scratch - they are testing **depth of understanding of trade-offs**. A common trap: the candidate confidently explains PoW but cannot answer "why not use PoW for a private blockchain?" Those nuances are exactly what separate a Senior from a Staff-level engineer.

**Question #1: "Explain Byzantine Fault Tolerance in 2 minutes."** This question tests the ability to structure thoughts under pressure. Most candidates start with the story about Byzantine generals - and spend a minute on the tale without reaching the substance. The interviewer wants specifics: the failure model, the tolerance threshold, the practical significance.

**Question #2: "Compare PoW vs PoS - when would you choose each?"** A weak answer: "PoS is better because it doesn't waste energy." A strong answer shows that the choice depends on the **threat model and system requirements**.

**Question #3: "What happens during a network partition?"** This question reveals whether the candidate understands the CAP theorem in practice. The key insight: different blockchains **make different sacrifices** under a partition. Bitcoin continues operating on both sides (availability), but one chain will be discarded when connectivity is restored (fork). Tendermint halts (consistency), but guarantees that no transaction will ever be rolled back.

**Red flag for the interviewer:** the candidate says "blockchain solves the Byzantine Generals problem" without specifying **which blockchain and under which assumptions**. Bitcoin solves it with <50% attacker hash power. Ethereum PoS - with <1/3 of stake. PBFT - with <1/3 of nodes. Each model has its own boundaries, and confusing them is a signal of superficial understanding.

The interviewer asks: "You are designing a private blockchain for a banking consortium of 20 participants. Why is PoW a poor choice?" Which answer demonstrates the greatest depth?

Smart Contract Design: Architecture Challenges

The coding round of a blockchain interview is not LeetCode. The interviewer does not ask you to implement a red-black tree in Solidity. Instead they test skills specific to on-chain development: **gas optimization**, **security patterns**, **upgradability**, and the ability to work within EVM constraints. Problems are often framed as "Design a [protocol]" followed by deep dives into specific aspects.

**Problem #1: "Design a token vesting contract."** A classic question because it covers multiple skills simultaneously: working with time on the blockchain, reentrancy protection, pull vs push payment pattern, and edge cases (what if the token is rebasing?).

**CEI pattern (Checks-Effects-Interactions)** - mandatory knowledge for interviews. Order: 1. check conditions 2. update state 3. external call. Violating CEI is the classic reentrancy vulnerability. The interviewer WILL check the order in which you write `s.released += claimable` and `token.safeTransfer()`.

**Problem #2: "Implement a simple DEX with limit orders."** Here the interviewer assesses understanding of the difference between on-chain and off-chain. A naive implementation (full order book on-chain) is a red flag: O(n) gas for matching, storing each order costs ~20,000 gas per SSTORE. The right approach: **off-chain order book + on-chain settlement** (0x Protocol) or AMM (Uniswap).

**Problem #3: "Design an upgradeable NFT marketplace."** The key word is **upgradeable**. The interviewer checks knowledge of proxy patterns. Three main ones: 1. **Transparent Proxy** - admin and users are separated; admin cannot call implementation functions 2. **UUPS** - upgrade logic is in the implementation, cheaper to deploy 3. **Diamond (EIP-2535)** - multiple implementation contracts, modularity. For a marketplace, UUPS is the standard choice: lower gas, supported by OpenZeppelin.

**A common candidate mistake:** using `transfer()` to send ETH. Since EIP-1884 (Istanbul hard fork), `transfer()` can fail if the recipient is a contract with an expensive fallback. Better: `(bool ok, ) = payable(to).call{value: amount}("")` + check `require(ok)`. An interviewer who spots `transfer()` will definitely ask about this.

You are designing an upgradeable smart contract. In version 1 you have: `uint256 totalSupply; mapping(address => uint256) balances;`. In version 2 you need to add `mapping(address => bool) frozen;`. Where should the new variable go?

Security Scenarios: Find the Vulnerability

The security round of a blockchain interview is the most intense. The interviewer shows a Solidity code snippet and asks you to find the vulnerability. This tests not knowledge of an attack list but the **ability to think like an attacker** - red team thinking. In the real industry, a bug in a smart contract can cost millions of dollars with no possibility of rollback. In 2024 alone, DeFi protocol hacks resulted in losses exceeding $1.7 billion.

**Scenario #1: Spot the reentrancy.** A classic, but interviewers still use this pattern because candidates confuse the variants of reentrancy: **single-function**, **cross-function**, and **cross-contract**. The 2016 DAO hack ($60M) - single-function. The 2023 Curve hack ($70M) - reentrancy via a Vyper compiler bug.

**Scenario #2: "How would you prevent reentrancy?"** Three layers of protection, and the interviewer expects knowledge of all: 1. **CEI pattern** - update state before external calls 2. **ReentrancyGuard (mutex)** - `nonReentrant` modifier that blocks re-entry 3. **Pull payment** - don't send ETH at all; let the recipient claim it via a separate function.

**Scenario #3: "Explain flash loan attack vectors."** A flash loan is an uncollateralized loan for a single block. The attacker borrows millions of dollars, manipulates the price in an AMM pool, uses the distorted price for liquidations or arbitrage, repays the loan - all in one transaction. **Euler Finance** ($197M, March 2023): flash loan → deposit → self-liquidation with inflated reward. **Cream Finance** ($130M, October 2021): oracle manipulation via flash loan.

**Incident response questions:** "You discovered a critical vulnerability in a deployed contract with $50M TVL. What do you do?" The correct answer: 1. DO NOT disclose publicly - responsible disclosure 2. white-hat rescue: use the vulnerability yourself to move funds to a safe contract 3. check the mempool - is an exploit already in progress 4. if upgradeable - immediately upgrade 5. if not upgradeable - emergency pause (if available) 6. contact Immunefi/the protocol team.

**In a security interview:** think out loud. The interviewer evaluates not just the result but the process: "I see an external call... let me check whether state is updated before it... no, the balance is written after the call - this is reentrancy." Systematic approach: 1. find external calls 2. check CEI 3. check access control 4. check arithmetic (overflow/underflow in pre-0.8) 5. check oracle manipulation.

A lending protocol uses `price = reserveUSDC / reserveETH` from a Uniswap pool as the oracle for ETH price. What attack vector is most dangerous?

System Design: Blockchain Systems for Millions

The system design round of a blockchain interview differs from a classic one because the architecture splits into **on-chain** and **off-chain** components. The mistake most candidates make is trying to put everything on the blockchain. An experienced engineer understands: blockchain is a **settlement layer**, not a database. The designer's task is to determine **which operations must be on-chain** (finality, trustless, censorship resistance) and which can be off-chain (speed, low cost, UX).

**Problem #1: "Design a blockchain explorer."** Etherscan handles millions of requests daily, displaying transactions, balances, contract source code, and token transfers. But here is what candidates often miss: data from the blockchain must be **indexed**, because native RPC calls to a node are extremely limited. You cannot ask a node "show me all transactions for this address" - that API simply does not exist.

**Problem #2: "Design a wallet service for 10M users."** The primary question the interviewer will ask: **custodial or non-custodial?** Custodial (Coinbase): the company holds private keys, simpler UX, but single point of failure. Non-custodial (MetaMask): keys are with the user, the company has no access to funds. Hybrid: **MPC (Multi-Party Computation)** - the key is split between the user and the service; neither party alone can sign a transaction.

**Problem #3: "Design a cross-chain bridge."** A Staff/Principal level problem, because bridges are one of the most complex and dangerous components of blockchain infrastructure. In 2022 alone: Ronin Bridge ($625M), Wormhole ($326M), Nomad ($190M). The interviewer checks whether the candidate understands **why bridges break** and how to minimize trust assumptions.

**Structured approach for any System Design problem:** 1. **Requirements** - functional + non-functional, clarifying questions (5 min) 2. **High-level design** - on-chain vs off-chain, main components (10 min) 3. **Deep dive** - the most complex component, trade-offs (15 min) 4. **Scaling + Failure modes** - what breaks at 10x load, disaster recovery (5 min). The interviewer values **structure of thinking** more than the specific solution.

In a blockchain interview you need to know Solidity by heart and write code from memory. Coding skills are what matter most.

Coding is just one of 4-5 rounds. System Design, Security analysis, and Consensus theory carry equal weight. Many Staff+ engineers at Coinbase and Consensys write in Go/Rust, not Solidity. The interviewer evaluates **depth of understanding** and **ability to reason about trade-offs**, not typing speed. A candidate who writes slowly but explains every decision ("I'm using the CEI pattern because...") will score higher than someone who quickly writes vulnerable code.

The blockchain industry differs from web development in that a code mistake can cost millions of dollars with no possibility of rollback. That is why FAANG companies and Web3 startups value engineers who think through the consequences of every decision. The coding interview checks not algorithmic complexity but blockchain-specific patterns: gas optimization, proxy upgrades, oracle design, key management.

You are designing a blockchain explorer for Ethereum. A user wants to see all ERC-20 transfers for an address over the past year. Which architectural component handles this functionality?

Key Takeaways

  • **Consensus questions** require not reciting definitions but understanding trade-offs: PoW vs PoS is a choice between decentralization and throughput, not between "bad" and "good." The SPAT framework (Situation → Problem → Approach → Trade-offs) structures an answer in 2 minutes
  • **Smart Contract Design** in interviews is not LeetCode - it is gas optimization, proxy patterns, CEI, and awareness of EVM constraints. A Staff-level candidate explains every decision: "uint96 for price because it packs with address into one storage slot"
  • **Security Scenarios** test red team thinking: reentrancy, flash loan attacks, oracle manipulation. Systematic approach: external calls → CEI → access control → arithmetic → oracle. Thinking out loud during the process matters more than the final answer
  • **System Design** for blockchain is the art of splitting on-chain and off-chain. Explorer, wallet, bridge - every problem starts with the question: "what MUST be on the blockchain, and what does not?" Structured approach: Requirements → High-Level → Deep Dive → Trade-offs
  • Going back to the salaries at the start: $350-500K is paid not for knowing Solidity, but for the ability to reason about trade-offs in systems where a mistake costs millions. Each section of this lesson is one interview round, and preparation for each requires practice, not memorization

Related Topics

Blockchain interview preparation rests on deep understanding of the foundational topics covered in the course:

  • Blockchain System Design — The foundation for the System Design round - patterns for designing blockchain systems, on-chain/off-chain separation, indexing and scaling strategies
  • Blockchain at Scale — Scaling questions (sharding, L2, rollups) are a frequent topic at Senior+ interviews. The interviewer expects understanding of real throughput constraints
  • Blockchain Research Frontiers — Awareness of current research directions (MEV mitigation, Account Abstraction, ZK proofs) is what distinguishes a Staff candidate from a Senior
  • Consensus: Introduction — Core consensus models (PoW, PoS, BFT) - prerequisite for the first round. Without deep understanding of the BFT threshold (3f+1), the consensus questions cannot be passed

Вопросы для размышления

  • If asked to "Design a DEX" - would you choose an on-chain order book, AMM, or off-chain matching with on-chain settlement? How would you justify the choice depending on the target blockchain (Ethereum L1 vs Solana vs L2)?
  • Flash loan attacks exploit composability - the same property that makes DeFi powerful. Can a protocol be protected against flash loan manipulation without sacrificing composability? What are the trade-offs between a TWAP oracle and Chainlink?
  • Why are bridges the most hacked component of blockchain infrastructure ($2.5B+ in losses in 2022-2024)? Is the Light Client approach (IBC) the final solution, or does it have fundamental limitations?

Связанные уроки

  • dist-10-byzantine
Blockchain Interviews (FAANG)

0

1

Sign In