Глубокий анализ рынка найма Web3: спрос на технические таланты от помощника по маркетингу до инженера по надежности сайтов

Манифест рекрутера в 3 часа ночи

Ого, только что при отладке фронтенда DeFi-протокола я внезапно осознал, что рынок найма в Web3 похож на бесконечно компилируемый смарт-контракт. Подбор помощника по маркетингу и Подбор инженера по надежности сайтов отличаются друг от друга сильнее, чем синтаксис Solidity и Rust.

Честно говоря, как бывший разработчик, ставший хедхантером, я обнаружил, что понимание большинством людей ролей в Web3 все еще застряло на этапе «просто нужно писать смарт-контракты». Мне вспомнился кандидат, которого я интервьюировал на прошлой неделе: в резюме он заявлял о своем опыте в Подборе специалистов по работе с разработчиками, но даже не смог объяснить основы моделей распределения токенов управления сообществом.

Помощник по маркетингу: инженер по входящему трафику в Web3

Начнем с, казалось бы, наименее технической роли — Подбор помощника по маркетингу. С точки зрения кода эта позиция похожа на фронтенд DApp — хотя она не затрагивает напрямую основную логику, она формирует первое впечатление пользователя.

Современные специалисты по маркетингу в Web3 должны:

• Владеть операциями в сообществах Discord/TG (как управление децентрализованной автономной организацией)
• Уметь писать технические блоги (как минимум столь же детальные, как комментарии к смарт-контрактам)
• Разбираться в анализе данных в блокчейне (хотя бы использовать Dune Analytics)

Честно говоря, я видел слишком много резюме на MyJob.one, где напрямую применяют опыт работы в традиционных 4A-компаниях к Web3. Это все равно что пытаться использовать опыт работы с MySQL для подачи заявки на позицию в блокчейн-базе данных.

Работа с разработчиками: жесткое руководство по выживанию для технических евангелистов

В 3 часа ночи, просматривая описание вакансии Подбор специалистов по работе с разработчиками, я понял, что мой кофе уже давно остыл. Требования к этой должности читаются как неоптимизированный смарт-контракт:

1. Умение писать техническую документацию (Markdown — это только база)
2. Опыт проведения живых демонстраций кода (решение внезапных багов как инцидентов в продакшене)
3. Владение как минимум тремя языками программирования (Solidity+JavaScript+Rust — стандарт)

Честно говоря, найти квалифицированного специалиста по DevRel сложнее, чем опытного разработчика смарт-контрактов. Боже, на прошлой неделе я собеседовал человека, который пытался объяснять язык Move с помощью паттернов React — это все равно что готовить суши по технологиям сычуаньской кухни.

Тестирование: стражи мира Web3

Говоря о Подборе инженеров по тестированию, я вдруг вспомнил инцидент прошлого года, когда DeFi-протокол потерял $8 млн из-за недостаточного покрытия тестами. С этой точки зрения тестировщики действительно находятся на передовой контроля рисков.

Современные роли в тестировании Web3 требуют:

• Владение фаззинг-тестированием (например, использование Echidna для поиска уязвимостей в смарт-контрактах)
• Умение писать скрипты автоматизированного тестирования (одного Python недостаточно — нужно знать и Foundry)
• Понимание паттернов MEV-атак (должен уметь моделировать сэндвич-атаки)

Подождите, не слишком ли я усложнил требования? Возможно, но именно это и нужно топовым проектам на MyJob.one.

Продуктовая аналитика: баланс между кодом и пользователями

Позиция Подбора специалистов по продуктовой аналитике особенно интересна — она похожа на интерфейс ABI, переводящий технический язык в удобные для пользователя руководства. Мне вспомнился классический случай: команда продуктовой аналитики DEX фактически изобрела концепцию «майнинга ликвидности».

Современные продуктовые аналитики Web3 должны освоить:

1. Умение читать логи событий смарт-контрактов (хотя бы понимать, что означает событие Transfer)
2. Разработку предложений по управлению (в десять раз сложнее, чем написание PRD-документов)
3. Понимание принципов оптимизации комиссий gas (пользователи не захотят переплачивать за ваш плохой UI)

Аналитик стратегий контроля рисков: оракулы мира блокчейна

Боже мой, когда речь заходит о Подборе аналитиков стратегий контроля рисков, разве это не реальная версия оракулов Chainlink? Они должны отслеживать данные в блокчейне в реальном времени и соответствующим образом реагировать.

На прошлой неделе во время собеседования я спросил: «Как вы определяете, разумно ли установлен порог ликвидации в кредитном протоколе?» Девять из десяти кандидатов начали зачитывать учебные ответы. Честно говоря, эта роль требует:

• Глубокого понимания механизмов DeFi-протоколов (как минимум личный опыт ликвидации)
• Умения писать скрипты мониторинга (Python+Web3.py — основа)
• Понимания теории игр (поскольку атакующие всегда умнее вас)

SRE: мастера, поддерживающие блокчейн в рабочем состоянии

В 4 утра, читая описание вакансии Подбора инженеров по надежности сайтов, я вдруг рассмеялся — «требуется 99,99% доступности ноды» — этот человек вообще в курсе, что блокчейны иногда форкаются?

Настоящие SRE в Web3 должны:

1. Владеть оркестрацией контейнеров (Kubernetes уже недостаточно — нужно управлять кластерами нод)
2. Уметь настраивать алерты мониторинга (Prometheus+Grafana — стандарт)
3. Разбираться в топологиях блокчейн-сетей (например, оптимизировать peer-соединения нод geth)

Выводы: несколько внезапных советов

Честно говоря, после написания всего этого я понял, что главная проблема найма в Web3 — асимметрия информации. Работодатели на MyJob.one постоянно жалуются на нехватку кандидатов, а соискатели говорят, что требования слишком высоки.

В заключение три совета для соискателей:

• Изучайте реальные репозитории проектов вместо учебников (как изучение исходного кода стандартной библиотеки при обучении программированию)
• Участвуйте в хакатонах для получения практического опыта (в Web3 быстро погибнешь от 纸上谈兵)
• Регулярно обновляйте свой стек технологий (инструменты прошлого года могут устареть к этому году)