Вопросы на собеседовании блокчейн-разработчика

Пример сильного ответа

Я объясняю это так: блокчейн — это цепочка блоков, где каждый блок хранит набор транзакций, свой хеш и хеш предыдущего блока. Именно ссылка на предыдущий хеш делает цепочку неизменяемой: правка старого блока ломает все последующие хеши. Хеширование — односторонняя функция: из данных легко получить отпечаток, а восстановить данные нельзя. Консенсус решает, кто добавляет следующий блок: в одних сетях — вычислительная работа, в других — ставка, в корпоративных — голосование валидаторов. В моей практике приходилось проектировать приватную сеть на четыре узла: время финальности блока держали в пределах пары секунд, а рассинхрон после падения узла устранялся за минуты.

• Ответ идёт от простого к сложному: блок, хеш, консенсус
• Есть личный пример с измеримым результатом
• Нет спорных утверждений, которые могут устареть

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Proof of Work требует вычислений: узлы соревнуются за право добавить блок, а безопасность держится на стоимости оборудования и электричества. Плюс — высокая устойчивость к атакам и проверенная временем модель, минус — энергозатраты и низкая пропускная способность. Proof of Stake заменяет работу ставкой: валидатор блокирует монеты и получает право предложить блок, а за нарушения теряет часть залога. Плюс — энергоэффективность и дешевле вход, минус — риски концентрации stake и «ничего не поставлено на кон». В работе мне чаще приходилось иметь дело со стейкингом: сеть на десятки валидаторов, и время отклика API после оптимизации сократили примерно на 40%.

• Сравнение симметричное: плюсы и минусы обеих моделей
• Показан практический опыт, а не только теория
• Честно назван риск концентрации stake

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

EVM — это виртуальная машина, которая исполняет байт-код смарт-контракта. Она изолирована от внешнего мира: контракт не читает диск и сеть напрямую, а общается только с состоянием блокчейна и с другими контрактами. Вызов создаёт контекст: выделяется газ, загружается код по адресу, выполняются инструкции над стеком, памятью и хранилищем. Любая запись в storage стоит дорого, поэтому вычисления стараются вести в памяти. Если газа не хватает, всё откатывается, и состояние возвращается к исходному. Мне приходилось оптимизировать контракт на Solidity: после переноса части логики в память и упаковки структур расход газа на ключевую операцию снизился примерно на треть.

• Объяснена изоляция EVM и роль газа
• Названа конкретная оптимизация с результатом
• Показано понимание механики, а не заучивание терминов

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Путь такой: приватный ключ — это случайное большое число. Из него по кривой secp256k1 получается публичный ключ, точнее точка на кривой. Дальше берётся Keccak-256 от публичного ключа без первого байта-префикса, и последние двадцать байт этого хеша становятся адресом. То есть адрес — это не «имя» аккаунта, а производная от ключа, поэтому восстановить ключ из адреса нельзя. В работе мне приходилось писать сервис генерации кошельков: на одной ноде получалось порядка нескольких тысяч адресов в секунду, а ключи хранились только в зашифрованном виде в KMS.

• Пошаговая цепочка: ключ, публичный ключ, хеш, адрес
• Подчёркнута необратимость преобразования
• Есть пример из практики с числами

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Газ — это единица измерения вычислительной работы: у каждой операции своя стоимость, а итоговая комиссия равна потраченному газу, умноженному на цену газа. После EIP-1559 модель стала двухсоставной: есть базовый сбор, который сжигается и автоматически подстраивается под загруженность блоков, и чаевые валидатору, которые пользователь добавляет, чтобы транзакцию взяли быстрее. Поэтому при перегрузке сети базовая часть растёт, а при спаде — падает. На практике мне приходилось настраивать батчинг транзакций: объединение выплат в пакеты сократило расход газа примерно на 30% и убрало зависшие транзакции.

• Разделены базовая часть комиссии и чаевые
• Объяснено, почему комиссия меняется во времени
• Приведён практический результат оптимизации

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

В Bitcoin состояние — это набор неизрасходованных выходов: отдельного баланса у адреса нет, он складывается из UTXO, а транзакция тратит старые выходы и создаёт новые. Поэтому валидация хорошо параллелится, приватность выше — под операцию можно дать новый адрес, но сложную логику строить тяжело. В Ethereum есть аккаунты с балансом, nonce и хранилищем, транзакции меняют глобальное состояние, и контрактам удобно переиспользовать данные друг друга. В моей практике индексер кошелька на 200 тысяч адресов потребовал отдельного слоя агрегации балансов из-за UTXO, а на аккаунтах состояние читается напрямую.

• Показано понимание обеих моделей, а не заученные определения
• Есть личный пример с реальным объёмом данных
• Названы практические следствия: параллелизм, приватность, сложность логики

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Storage — постоянное хранилище контракта: данные лежат в слотах и сохраняются между вызовами, запись стоит дорого. Memory — временная изменяемая область на время вызова, туда копируются данные, после вызова она очищается. Calldata — только для чтения, это аргументы внешних функций: копирования нет, поэтому это самый дешёвый вариант. На практике перевод параметров внешней функции с memory на calldata вместе с передачей массивов через calldata дал экономию около 15% газа на вызове в одном из контрактов. Отдельно держу в голове stack для локальных переменных и стараюсь минимизировать переходы между областями.

• Чётко разграничены три области хранения
• Есть цифра экономии газа из личного опыта
• Показано понимание причин, а не только терминов

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Mapping — это, по сути, хеш-таблица в storage: значение лежит по слоту, вычисленному из ключа, поэтому поиск дешёвый, но сами ключи нигде не перечислены и длины у структуры нет. Отсюда и невозможность итерации: контракт не знает, какие ключи существуют, а перебор всех вариантов нереален. Обход — вести рядом массив ключей и счётчик, а для чтения списков использовать события и внешний индексер. В проекте реестра на 50 тысяч адресов массив ключей рядом с mapping плюс офчейн-индекс по событиям закрыли и вывод списка, и проверку статуса без дорогого перебора в цепи.

• Объяснена причина, а не только факт отсутствия итерации
• Даны два рабочих обхода: массив ключей и индексер
• Подтверждено примером на 50 тысячах записей

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Начинаю с профилирования: смотрю gas-отчёт и горячие операции, потом меняю то, что даёт эффект. Основное — упаковка переменных в один слот, кеширование чтений storage в локальных переменных, чтобы не платить за повторное чтение, immutable и constant для неизменяемых значений, custom errors вместо длинных строк, события вместо записи в storage, батчинг операций и отказ от циклов по растущим массивам. В одном контракте упаковка трёх полей в общий слот и кеш чтений снизили стоимость ключевой функции примерно на 30%.

• Виден системный подход: сначала профилирование, потом правки
• Перечислены конкретные приёмы оптимизации
• Есть измеримый результат — минус 30% газа

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

В моей практике был проект с обновляемыми контрактами. Моя задача — выбрать правильный тип вызова для прокси. Я объясняю так: call выполняет код в контексте целевого контракта, delegatecall — в контексте вызывающего, сохраняя storage, msg.sender и msg.value, а staticcall запрещает изменение состояния. Для прокси я использую delegatecall, для чтения — staticcall, для внешних взаимодействий — call. Это помогло избежать коллизий storage и сократить расход газа на 15% при тестировании. Главное — понимать, чей контекст и какие ограничения.

• Чётко разграничивает контексты выполнения и ограничения.
• Приводит конкретный пример из практики с измеримым результатом.
• Демонстрирует понимание применения в прокси и view-функциях.

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Перед деплоем выстраиваю несколько уровней проверки. Сначала юнит-тесты на Foundry или Hardhat: покрываю все ветки логики, включая отказы и граничные значения. Дальше fuzz- и инвариантные тесты — они хорошо ловят то, что не придумаешь руками. Отдельно форк-тесты на реальном состоянии сети, чтобы проверить интеграции с уже работающими протоколами. Затем статический анализ и сверка с типовыми уязвимостями. В одном проекте такой набор поднял покрытие примерно до 95% и позволил найти 4 серьёзных бага, включая ошибку в расчёте комиссии. Финальный шаг — тестнет, стресс-прогоны и постепенный вывод лимитов в прод.

• Показан процесс из нескольких уровней, а не один инструмент
• Есть конкретная цифра: покрытие и найденные баги
• Упомянут постепенный запуск и проверка интеграций

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Моя базовая схема — прокси, который хранит состояние, и логика в отдельном контракте, на который прокси делегирует вызовы. Из паттернов чаще всего использую прозрачный прокси и UUPS; когда обновлять нужно много однотипных экземпляров, удобен beacon, а для крупных систем — diamond. Ключевое — аккуратное хранение: новые переменные только добавляются в конец, конструктор заменяется инициализатором с защитой от повторного вызова, права на апгрейд уходят в мультисиг или таймлок. В проекте с восемью контрактами такая схема позволила выпускать обновления без миграции данных и без простоя для пользователей.

• Названы конкретные паттерны прокси и их назначение
• Отдельно проговорены риски хранения и прав апгрейда
• Есть пример с результатом: обновления без миграции

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Читаю данные через RPC-провайдера, транзакции отправляю через подключённый кошелёк. Обычно беру готовую связку — wagmi с viem или ethers в React: так меньше ручной работы с провайдером, сетью и подписями. ABI генерирую из артефактов сборки, чтобы типы и адреса методов не расходились с контрактом. Массовые чтения собираю в multicall, чтобы не спамить RPC, состояние кэширую и обновляю по событиям. Обязательно обрабатываю смену сети, отклонённые подписи и понятные статусы транзакции. В одном интерфейсе такая схема сократила число RPC-запросов примерно на 60% и ускорила загрузку данных с двух секунд до четырёхсот миллисекунд.

• Показано понимание чтения и записи через RPC и кошелёк
• Упомянуты multicall, кэш и обновление по событиям
• Есть измеримый результат по скорости и нагрузке

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Reentrancy — это когда контракт делает внешний вызов до того, как обновил своё состояние, и вызываемый контракт успевает зайти в ту же функцию снова, пока балансы ещё не изменились. Классический сценарий — многократный вывод средств за одну транзакцию. Защита строится на порядке операций: сначала проверки, потом изменение состояния и только затем внешние вызовы. Дополнительно ставлю мьютекс-флаг на функции с внешними вызовами, свожу выплаты к схеме, где получатель самостоятельно забирает средства, и разделяю доверенные и недоверенные вызовы. На учебном стенде такая атака выводила весь баланс контракта, а после правок — ноль.

• Сначала объяснена суть атаки, потом защита
• Названы конкретные приёмы: порядок операций и мьютекс
• Приведён наглядный результат проверки на стенде

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Подготовка к аудиту — это отдельный проект, а не пара дней. Сначала фиксирую объём: какие контракты проверяются и что вне границ. Дальше привожу код в читаемый вид, описываю инварианты и сценарии злоупотреблений, собираю тесты и отчёт о покрытии. Отдельно прохожу по известным классам уязвимостей и закрываю то, что находится, ещё до передачи. Во время аудита держу один канал связи и быстро отвечаю на вопросы, по замечаниям делаю триаж: критичное и высокое — в первую очередь. В одном проекте подготовка заняла две недели, из восемнадцати замечаний четыре оказались критическими, а правки по ним ушли в репозиторий за три дня вместе с повторной проверкой.

• Показан процесс подготовки, а не только ожидание аудита
• Упомянуты объём, документация и собственный ревью
• Есть цифры по срокам и найденным замечаниям

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Автоматический маркет-мейкер в DeFi — это механизм, где цена определяется формулой постоянного произведения: произведение резервов двух токенов в пуле остаётся неизменным. Поставщики ликвидности вносят активы, получая долю пула и комиссию с каждой сделки. Трейдеры обменивают токены против пула, и цена меняется по кривой, поэтому возникает проскальзывание. В моей практике мне приходилось интегрировать пулы с общей ликвидностью около 5 миллионов долларов и настраивать комиссии. Главные риски — непостоянные потери для поставщиков и атаки на оракулы. Я всегда проверяю, как контракт считает цену и защищён ли он от манипуляций.

• Показывает понимание формулы x*y=k и роли LP
• Приводит личный опыт с конкретной суммой ликвидности
• Упоминает риски: impermanent loss и манипуляции

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Смарт-контракты изолированы от внешнего мира, поэтому им нужны оракулы, чтобы получать цены, курсы, случайные числа и сигналы событий. Без оракулов DeFi-протоколы не могут корректно считать залоги и ликвидации. Я работаю с Chainlink: подключаю ценовые фиды, настраиваю проверку свежести данных и fallback-источники на случай сбоя. В одном проекте мне приходилось обслуживать пул с TVL около 10 миллионов долларов, и мы использовали несколько оракулов для устойчивости. Также применяю Chainlink VRF для честного розыгрыша NFT. Главное — всегда проверять, что контракт корректно обрабатывает устаревшие или аномальные данные.

• Объясняет необходимость оракулов для внешних данных
• Показывает практику с Chainlink: фиды, VRF, fallback
• Приводит конкретный TVL и подход к устойчивости

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Помимо Ethereum, мне приходилось работать с L2-решениями: Arbitrum, Optimism и Polygon, а также с TON и BSC. На L2 я оптимизирую газ и учитываю особенности мостов, а в TON — асинхронную модель и уникальный формат адресов. В одном проекте мы мигрировали контракты на L2 и снизили комиссии для пользователей примерно на 90%. Что касается российского регулирования, мы всегда привлекаем юристов для оценки рисков, следим за обновлениями и выстраиваем процессы так, чтобы продукт соответствовал применимым требованиям. Я лично отвечаю за техническую часть, а юридическую экспертизу обеспечивает команда.

• Перечисляет конкретные сети: L2, TON, BSC
• Показывает результат: снижение комиссий на 90%
• Аккуратно говорит о регулировании через юристов и процессы

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.