Блокчейн
Blockchain на собеседовании (FAANG)
В 2024 году средняя зарплата Senior Blockchain Engineer в FAANG составила 350-500K total compensation. Coinbase, a16z crypto, Paradigm, Jump Crypto платят ещё больше. Но проходимость blockchain-собеседований - менее 15%, потому что кандидаты готовятся как к обычному software engineering интервью. Они решают LeetCode, но не могут объяснить, почему Tendermint останавливается при network partition, а Bitcoin - нет. Они пишут Solidity, но не замечают reentrancy в код-ревью. Они проектируют системы, но кладут order book на блокчейн. Этот урок - concentrated preparation: четыре типа вопросов, которые задают на blockchain-собеседованиях, с модельными ответами уровня Staff Engineer.
- **Coinbase** (Backend/Blockchain Engineer): раунды по Consensus + System Design ("Design our custody solution for institutional clients") + Coding (Solidity/Go). Проходимость ~12% для Senior+
- **a16z crypto / Paradigm**: глубокие вопросы по security ("audit this DeFi protocol") и protocol design. Ожидают research-level понимание consensus и MEV
- **Jump Crypto / Wintermute**: акцент на performance - latency-sensitive системы, MEV extraction, cross-chain arbitrage. System Design с жёсткими latency requirements (<10ms)
Предварительные знания
Consensus: вопросы и фреймворки ответов
На blockchain-собеседованиях в FAANG и крупных Web3-компаниях (Coinbase, Consensys, a16z crypto) вопросы по consensus - это фильтр первого уровня. Интервьюер проверяет не умение написать Raft с нуля, а **глубину понимания trade-offs**. Типичная ловушка: кандидат уверенно объясняет PoW, но не может ответить "а почему бы не использовать PoW для приватного блокчейна?". Именно такие нюансы отделяют Senior от Staff-уровня.
**Вопрос #1: "Объясните Byzantine Fault Tolerance за 2 минуты."** Этот вопрос проверяет способность структурировать мысли под давлением. Большинство кандидатов начинают с истории про византийских генералов - и тратят минуту на сказку, не добравшись до сути. Интервьюер хочет услышать конкретику: модель отказов, порог толерантности, практическое значение.
**Вопрос #2: "Compare PoW vs PoS - when would you choose each?"** Слабый ответ: "PoS лучше, потому что не тратит энергию". Сильный ответ показывает, что выбор зависит от **threat model и требований системы**.
**Вопрос #3: "What happens during a network partition?"** Этот вопрос вскрывает понимание кандидатом CAP теоремы на практике. Ключевой инсайт: разные блокчейны **по-разному жертвуют** при partition. Bitcoin продолжает работать на обеих сторонах (availability), но одна из цепей будет отброшена при восстановлении связи (fork). Tendermint останавливается (consistency), но гарантирует, что ни одна транзакция не будет отменена.
**Красный флаг для интервьюера:** кандидат говорит "blockchain решает проблему Byzantine генералов" без уточнения, **какой именно blockchain и при каких допущениях**. Bitcoin решает её при <50% хэш-мощности атакующего. Ethereum PoS - при <1/3 стейка. PBFT - при <1/3 узлов. Каждая модель имеет свои границы, и путаница между ними - сигнал поверхностного понимания.
Интервьюер спрашивает: "Вы проектируете приватный блокчейн для банковского консорциума из 20 участников. Почему PoW - плохой выбор?" Какой ответ демонстрирует наибольшую глубину?
Smart Contract Design: задачи на проектирование
Coding-раунд blockchain-собеседования - это не LeetCode. Интервьюер не просит реализовать красно-чёрное дерево на Solidity. Вместо этого проверяются навыки, специфичные для on-chain разработки: **gas-оптимизация**, **паттерны безопасности**, **upgradability** и умение работать с ограничениями EVM. Задачи часто формулируются как "Design a [протокол]" с последующим углублением в конкретные аспекты.
**Задача #1: "Design a token vesting contract."** Классический вопрос, потому что покрывает сразу несколько навыков: работа с временем на блокчейне, защита от reentrancy, паттерн pull vs push payments, и edge cases (что если токен - rebasing?).
**Паттерн CEI (Checks-Effects-Interactions)** - обязательный на собеседовании. Порядок: 1. проверить условия 2. обновить state 3. внешний вызов. Нарушение CEI - классическая reentrancy уязвимость. Интервьюер БУДЕТ проверять, в каком порядке вы пишете `s.released += claimable` и `token.safeTransfer()`.
**Задача #2: "Implement a simple DEX with limit orders."** Здесь интервьюер оценивает понимание разницы между on-chain и off-chain. Наивная реализация (полный order book на chain) - это красный флаг: O(n) gas за matching, хранение каждого ордера - ~20,000 gas за SSTORE. Правильный подход: **off-chain order book + on-chain settlement** (0x Protocol) или AMM (Uniswap).
**Задача #3: "Design an upgradeable NFT marketplace."** Ключевое слово - **upgradeable**. Интервьюер проверяет знание proxy patterns. Три основных: 1. **Transparent Proxy** - admin и пользователи разделены, admin не может вызывать функции implementation 2. **UUPS** - логика upgrade в implementation, дешевле deploy 3. **Diamond (EIP-2535)** - несколько implementation контрактов, модульность. Для marketplace UUPS - стандартный выбор: дешевле gas, OpenZeppelin поддерживает.
**Частая ошибка кандидатов:** использование `transfer()` для отправки ETH. С EIP-1884 (Istanbul hard fork) `transfer()` может fail, если получатель - контракт с дорогим fallback. Лучше: `(bool ok, ) = payable(to).call{value: amount}("")` + проверка `require(ok)`. Интервьюер, заметивший `transfer()`, обязательно спросит об этом.
Вы проектируете upgradeable smart contract. В версии 1 у вас: `uint256 totalSupply; mapping(address => uint256) balances;`. В версии 2 нужно добавить `mapping(address => bool) frozen;`. Куда поместить новую переменную?
Security Scenarios: найди уязвимость
Security-раунд на blockchain-собеседовании - самый интенсивный. Интервьюер показывает фрагмент Solidity-кода и просит найти уязвимость. Это проверка не знания списка атак, а **способности думать как атакующий** - red team thinking. В реальной индустрии ошибка в smart contract означает потерю миллионов долларов без возможности rollback. Только в 2024 году хаки DeFi-протоколов привели к потерям более 1.7 млрд.
**Сценарий #1: Spot the reentrancy.** Классика, но интервьюеры до сих пор используют этот паттерн, потому что кандидаты путают варианты reentrancy: **single-function**, **cross-function**, и **cross-contract**. DAO hack 2016 года ($60M) - single-function. Curve hack 2023 года ($70M) - reentrancy через Vyper compiler bug.
**Сценарий #2: "How would you prevent reentrancy?"** Три уровня защиты, и интервьюер ожидает знание всех: 1. **CEI pattern** - обновить state до внешнего вызова 2. **ReentrancyGuard (mutex)** - `nonReentrant` модификатор, блокирующий повторный вход 3. **Pull payment** - не отправлять ETH вообще, пусть получатель сам забирает через отдельную функцию.
**Сценарий #3: "Explain flash loan attack vectors."** Flash loan - беззалоговый займ на один блок. Атакующий берёт миллионы долларов, манипулирует ценой в AMM-пуле, использует искажённую цену для ликвидации или арбитража, возвращает займ - всё в одной транзакции. **Euler Finance** ($197M, март 2023): flash loan → депозит → самоликвидация с завышенной наградой. **Cream Finance** ($130M, октябрь 2021): манипуляция oracle через flash loan.
**Incident Response вопросы:** "Вы обнаружили critical уязвимость в deployed контракте с 50M TVL. Ваши действия?" Правильный ответ: 1. НЕ раскрывать публично - responsible disclosure 2. white-hat rescue: использовать уязвимость первым, чтобы перевести средства в безопасный контракт 3. проверить mempool - нет ли уже эксплойта 4. если upgradeable - немедленный upgrade 5. если не upgradeable - emergency pause (если есть) 6. связаться с Immunefi/команда протокола.
**На собеседовании по security:** проговаривайте вслух ход мысли. Интервьюер оценивает не только результат, но и процесс: "Я вижу внешний вызов... проверю, обновлён ли state до него... нет, баланс пишется после call - это reentrancy". Систематический подход: 1. найти внешние вызовы 2. проверить CEI 3. проверить access control 4. проверить arithmetic (overflow/underflow в pre-0.8) 5. проверить oracle manipulation.
Lending протокол использует `price = reserveUSDC / reserveETH` из Uniswap пула как oracle для цены ETH. Какой attack vector наиболее опасен?
System Design: blockchain-системы для миллионов
System Design раунд на blockchain-собеседовании отличается от классического тем, что архитектура разделяется на **on-chain** и **off-chain** компоненты. Ошибка большинства кандидатов - пытаться поместить всё на блокчейн. Опытный инженер понимает: блокчейн - это **settlement layer**, а не база данных. Задача проектировщика - определить, **какие операции должны быть on-chain** (финальность, trustless, censorship resistance), а какие - off-chain (скорость, дешевизна, UX).
**Задача #1: "Design a blockchain explorer."** Etherscan обрабатывает миллионы запросов в день, показывая транзакции, балансы, contract source code и token transfers. Но вот что кандидаты часто упускают: данные из блокчейна нужно **индексировать**, потому что нативные RPC-запросы к ноде крайне ограничены. Нельзя спросить ноду "покажи все транзакции этого адреса" - такого API нет.
**Задача #2: "Design a wallet service for 10M users."** Главный вопрос, который задаст интервьюер: **custodial или non-custodial?** Custodial (Coinbase): компания хранит private keys, проще UX, но single point of failure. Non-custodial (MetaMask): ключи у пользователя, компания не имеет доступа к средствам. Гибрид: **MPC (Multi-Party Computation)** - ключ разделён на части между пользователем и сервисом, ни одна сторона не может подписать транзакцию в одиночку.
**Задача #3: "Design a cross-chain bridge."** Это задача уровня Staff/Principal, потому что bridges - один из самых сложных и опасных компонентов blockchain-инфраструктуры. Только в 2022 году были взломаны Ronin Bridge ($625M), Wormhole ($326M), Nomad (190M). Интервьюер проверяет, понимает ли кандидат, **почему bridges ломаются** и как минимизировать trust assumptions.
**Structured approach для любой System Design задачи:** 1. **Requirements** - functional + non-functional, уточняющие вопросы (5 мин) 2. **High-level design** - on-chain vs off-chain, основные компоненты (10 мин) 3. **Deep dive** - самый сложный компонент, trade-offs (15 мин) 4. **Scaling + Failure modes** - что ломается при 10x нагрузке, disaster recovery (5 мин). Интервьюер ценит **структуру мышления** больше, чем конкретное решение.
На blockchain-собеседовании нужно знать Solidity наизусть и уметь писать код по памяти. Главное - coding skills.
Coding - лишь один из 4-5 раундов. System Design, Security analysis и Consensus theory весят не меньше. Многие Staff+ инженеры в Coinbase и Consensys пишут на Go/Rust, не на Solidity. Интервьюер оценивает **depth of understanding** и **ability to reason about trade-offs**, а не скорость набора кода. Кандидат, который медленно пишет, но объясняет каждое решение ("я использую CEI pattern, потому что..."), получит оценку выше, чем тот, кто быстро пишет уязвимый код.
Blockchain-индустрия отличается от web development тем, что ошибка в коде может стоить миллионы долларов без возможности rollback. Поэтому FAANG-компании и Web3-стартапы ценят инженеров, которые думают о последствиях каждого решения. Coding interview проверяет не алгоритмическую сложность, а специфические blockchain-паттерны: gas optimization, proxy upgrades, oracle design, key management.
Итоги
- **Consensus-вопросы** требуют не пересказа определений, а понимания trade-offs: PoW vs PoS - это выбор между decentralization и throughput, не между "плохим" и "хорошим". Фреймворк SPAT (Situation → Problem → Approach → Trade-offs) структурирует ответ за 2 минуты
- **Smart Contract Design** на собеседовании - это не LeetCode, а gas-оптимизация, proxy patterns, CEI и осознание ограничений EVM. Кандидат уровня Staff объясняет каждое решение: "uint96 для price, потому что упакуется с address в один storage slot"
- **Security Scenarios** проверяют red team thinking: reentrancy, flash loan attacks, oracle manipulation. Систематический подход: внешние вызовы → CEI → access control → arithmetic → oracle. Проговаривание процесса вслух важнее финального ответа
- **System Design** для blockchain - это искусство разделения on-chain и off-chain. Explorer, wallet, bridge - каждая задача начинается с вопроса: "что ДОЛЖНО быть на блокчейне, а что нет?". Structured approach: Requirements → High-Level → Deep Dive → Trade-offs
- Вернёмся к зарплатам из начала: 350-500K платят не за знание Solidity, а за ability to reason about trade-offs в системах, где ошибка стоит миллионы. Каждый раздел этого урока - один раунд собеседования, и подготовка к каждому требует практики, а не заучивания
Связанные темы
Подготовка к blockchain-собеседованию опирается на глубокое понимание фундаментальных тем курса:
- Blockchain System Design — Фундамент для System Design раунда - паттерны проектирования blockchain-систем, разделение on-chain/off-chain, indexing и scaling strategies
- Blockchain at Scale — Вопросы о масштабировании (sharding, L2, rollups) - частая тема на Senior+ собеседованиях. Интервьюер ожидает понимание реальных ограничений throughput
- Blockchain Research Frontiers — Awareness текущих research направлений (MEV mitigation, Account Abstraction, ZK proofs) отличает Staff-кандидата от Senior
- Consensus: введение — Базовые модели consensus (PoW, PoS, BFT) - prerequisite для первого раунда. Без глубокого понимания BFT threshold (3f+1) невозможно пройти consensus-вопросы
Вопросы для размышления
- Если вас спросят "Design a DEX" - что вы выберете: on-chain order book, AMM, или off-chain matching с on-chain settlement? Как обосновать выбор в зависимости от целевого блокчейна (Ethereum L1 vs Solana vs L2)?
- Flash loan атаки эксплуатируют composability - ту же свойство, которое делает DeFi привлекательным. Можно ли защитить протокол от flash loan манипуляций, не жертвуя composability? Какие trade-offs у TWAP oracle vs Chainlink?
- Почему bridges - самый взламываемый компонент blockchain-инфраструктуры (2.5B+ потерь за 2022-2024)? Является ли Light Client подход (IBC) окончательным решением, или у него есть фундаментальные ограничения?