Как проверить реальный опыт кандидата в Blockchain, когда рынок полон hackathon-проектов, forks и громких названий? Нужна система доказательств: публичный код, mainnet-контекст, contracts, личный вклад, incidents, audits и references.
Ни один источник не является достаточным сам по себе. GitHub можно интерпретировать неверно, адрес контракта не подтверждает authorship, а закрытый repository не означает слабый опыт.
Карта заявленного опыта
Разделите проекты по типу: protocol, smart contracts, dApp, wallet, infrastructure, exchange, indexing или security. Для каждого уточните сеть, стадию, роль и production-статус.
Такой список помогает не смешивать участие в hackathon, тестовый deployment и долгосрочную ответственность за mainnet.
Публичный код и GitHub
GitHub полезен, если смотреть не на зелёные квадраты, а на commits, pull requests, review, issues и ownership. Отсутствие публичного профиля не доказывает отсутствие опыта.
Попросите выбрать один repository и объяснить architecture, собственный вклад, компромиссы и дальнейшую судьбу кода.
Mainnet и on-chain evidence
Deploy в testnet и ответственность за mainnet различаются по риску, monitoring, incident response и стоимости ошибки.
Contract address, verified source, deployment transactions и governance proposals могут подтверждать часть опыта, но не доказывают authorship без дополнительных источников.
- Сеть и contract address.
- Repository и commits.
- Deployment history.
- Monitoring и support.
- Командное подтверждение.
Ownership, incidents и audit
Фраза «работал над protocol» может означать architecture, один модуль, integration или research. Просите назвать решения, которые кандидат принимал лично.
Наличие exploit не делает кандидата слабым автоматически. Важно, что он делал до, во время и после инцидента, как проходила remediation и какие controls появились.
оценка Blockchain-кандидатов помогает искать кандидатов по реальному контексту продукта, уровню ответственности и доказательствам опыта, а не по одному знакомому title.
Forks, open source и contributions
Использование forks и libraries нормально, если кандидат понимает изменения, risks и поддержку. Копирование шаблона без понимания не является production-экспертизой.
Для core engineers полезны proposals, standards, libraries, docs и ecosystem tooling. Оценивайте качество и adoption, а не только публичность.
NDA, references и case
Закрытый repository или неанонсированный продукт ограничивает публичные доказательства. Кандидат может описать architecture, масштаб, process и обезличенный результат.
Используйте references, live case и согласованные артефакты, не провоцируя нарушение NDA.
Как оценивать масштаб и личный вклад
Для роли Blockchain-кандидат важно отделить участие от ownership. Уточняйте размер команды, стадию продукта, географии, бюджет или технический scope, а также решения, которые кандидат принимал лично. Общие формулировки «мы запустили» и «мы выросли» нужно переводить в конкретные действия, ограничения и результат.
Сильный кандидат спокойно обозначает границы собственной ответственности, объясняет trade-offs и может связать решение с данными, риском или изменением продукта. Уровень определяется не громкостью проекта, а сложностью контекста и влиянием на него.
- Production stage.
- Личный ownership.
- Код и on-chain evidence.
- Security incidents.
- Audit и ecosystem contribution.
Практический кейс на интервью
Используйте короткий кейс, похожий по типу на вашу задачу, но не содержащий коммерчески чувствительных данных. Дайте неполные вводные и посмотрите, какие вопросы кандидат задаёт, как расставляет приоритеты, где видит риски и какие доказательства результата предлагает.
Не просите бесплатно создать готовую стратегию, провести аудит действующего продукта или выполнить production-задачу. Для senior и lead-уровня содержательная дискуссия, portfolio review, code review или план первых шагов обычно информативнее большого домашнего задания.
Типичные ошибки работодателя
Ошибки начинаются, когда вакансия собирается из нескольких соседних функций, а критерии появляются уже после первых интервью. В результате разные участники ищут разных людей, кандидат получает противоречивые сигналы, а рынок объявляется «пустым», хотя профиль изначально был невозможным.
Также опасно оценивать только известность проекта, количество подписчиков, размер токена, название сети или конкретный инструмент. Эти признаки дают контекст, но не заменяют проверку ownership, качества решений и переносимости опыта.
- Не различать testnet и mainnet.
- Приписывать кандидату результат команды.
- Считать fork полностью собственной разработкой.
- Игнорировать incidents.
- Отказывать из-за отсутствия публичного GitHub.
Практический алгоритм найма
Сначала согласуйте результат роли на первые 6–12 месяцев и отделите обязательный Web3-опыт от компетенций, которые можно перенести из fintech, security, developer platforms или международных digital-продуктов. Затем постройте карту компаний-доноров и только после этого запускайте sourcing.
- Зафиксировать продукт, стадию, географию и главный риск найма.
- Выбрать три обязательные компетенции и допустимые пробелы.
- Определить компании, протоколы и смежные рынки для поиска.
- Проводить скрининг по ownership и production-контексту.
- Использовать один содержательный профессиональный кейс.
- Давать обратную связь без недельных пауз.
Если внутренней команде не хватает ресурсов на direct search и первичную проверку рынка,
подбор Blockchain и Web3-специалистов помогает расширить воронку без массовой выдачи случайных профилей.
Как калибровать профиль по первым интервью
После первых трёх-пяти разговоров сравните ожидания с реальным рынком. Если сильные кандидаты системно не совпадают по одному второстепенному инструменту, требование может быть переоценено. Если люди отказываются из-за полномочий, юридического формата или непрозрачности проекта, менять нужно предложение, а не только outreach.
Калибровка не означает снижать планку после каждого отказа. Она нужна, чтобы отделить критичные компетенции от привычек команды и сократить пустые интервью. Решения стоит принимать по повторяющимся данным, а не по одному особенно убедительному кандидату.
Для поиска по нескольким странам используйте
международный подбор IT-персонала, когда нужно учитывать географию, языки, часовые пояса, типы договоров и ограничения международного найма.
Чек-лист перед запуском
До публикации вакансии проверьте, что роль можно объяснить одним предложением, обязательные требования связаны с реальными задачами, участники интервью используют единые критерии, а условия и ограничения раскрываются до финала.
- Тип проекта и сеть.
- Production status.
- Ownership.
- Code и on-chain evidence.
- Security и incidents.
- References или NDA-proof.
Частые вопросы
Обязателен ли публичный GitHub?
Нет. Многие сильные специалисты работают в закрытых repositories. Нужны альтернативные доказательства.
Как подтвердить authorship контракта?
Связать on-chain address с repository, deployment history, объяснением кандидата и references.
Нужно ли отказывать после exploit?
Нет автоматически. Важно понять роль, действия, выводы и изменения после инцидента.
Что считать production-опытом?
Код или система, используемые реальными пользователями и требующие monitoring, support и ответственности.
Как проверять NDA-проекты?
Через обезличенный разбор, согласованные артефакты, кейс и references.
Вывод
Реальный Blockchain-опыт проверяется через совокупность доказательств: код, mainnet, ownership, incidents, audits и references.
Передайте вакансию на
подбор Blockchain и Web3-специалистов, если нужен первичный отбор кандидатов с подтверждённым production-контекстом.