Метод Devsmatcher

Как мы оцениваем AI-специалистов.

Это реальная система, которой мы пользуемся, — опубликованная полностью, чтобы вы могли оценить наше суждение до того, как на него полагаться. Если вы прочитали и не согласны — мы сэкономили друг другу звонок.

Почему метод публичный

Каждый рекрутер заявляет, что «тщательно проверяет». Заявления ничего не стоят. Метод, который можно прочитать, оспорить и спросить с нас, — стоит.

Публичность держит нас честными: если кандидат прошёл наш процесс, мы можем показать, что именно он прошёл. Если не прошёл — можем показать почему.

Что мы оцениваем и в каком порядке

Порядок важен. Большинство провалов найма происходит на первом шаге — до того, как связались хоть с одним кандидатом.

1.1

Определение роли — до любого кандидата

Поиск под неверную роль даёт уверенный неверный найм. Мы начинаем с проверки самой роли на прочность.

Что именно строится и на какой это стадии?
Что означает «production» в этой компании — трафик, пользователи, деньги на кону?
Кому подчиняется этот человек и кто снимает его блокеры?
Что должно быть сделано за первые 90 дней, чтобы найм считался успешным?
Нужен ли вообще full-time найм — или это advisory, fractional или «позже»?

1.2

Production-доказательства

Проверяем, что заявленный опыт пережил контакт с реальными пользователями. Ключевые слова не считаются; считаются последствия.

Системы под реальным трафиком — и фактическая роль кандидата в них
Что ломалось в production и что он лично с этим делал
Evaluation и мониторинг: как он понимал, что система работает — и продолжает работать
Понимание стоимости инференса и latency как инженерных ограничений
Что стало с системой после запуска — деградация, итерации, вывод из эксплуатации

1.3

Техническая глубина

Глубина за пределами вызовов API. Копаем, пока ответы не перестанут быть отрепетированными.

Понимание стека ниже фреймворка, который кандидат называет
Реальность данных: качество, пайплайны и негламурное большинство работы
Режимы отказа: галлюцинации, дрейф, тихая деградация — и защита от них
Устойчивость к уточнениям: даёт ли третий «почему?» всё ещё настоящий ответ?

1.4

Суждение в условиях trade-offs

Сильные инженеры знают, чего не строить. Проверяем принятие решений там, где чистого ответа нет.

Когда не использовать LLM — и что использовать вместо
Build против buy, fine-tune против промпта, качество против стоимости и latency
Что он срежет под жёсткий дедлайн — и что откажется срезать

1.5

Коммуникация с бизнесом

AI-команды чаще ломаются на переводе, чем на коде. Этому человеку работать с людьми, которые не читают papers.

Может ли объяснить техническое решение founder'у за две минуты?
Возражает ли, когда план неверен, — аргументами, а не интонацией?
Пишет ли ясно? Большая часть production-координации — письменная.

Production AI против demo AI

Самая дорогая путаница в AI-найме. Вот сигналы, которыми мы реально пользуемся, чтобы их различать:

Сигналы production-опыта

Говорит про evaluation-пайплайны и регрессии, а не только про промпты
Называет цифры стоимости и latency без наводящего вопроса
Есть истории провалов — и своя роль в них не спрятана
Знает, что происходило с системой через месяцы после запуска
Описывает работу с данными как большую часть работы — потому что так и было

Сигналы demo-опыта

Портфолио впечатляющих demo, за которыми нет трафика
Перечисление фреймворков без глубины ни в одном
«Prompt engineering» как заявленный ключевой навык
Нет настоящего ответа на вопрос «что ломалось?»
Метрики модели — и никогда метрики бизнеса

Что валит кандидата

Мы отказываем по конкретным причинам — и фиксируем их письменно:

F1Production-заявления без проверяемого production за ними
F2Не может разобрать ни одного своего технического решения и объяснить почему
F3Глубина, которая есть в портфолио, но рассыпается под уточняющими вопросами
F4Считает evaluation, мониторинг или качество данных чужой работой
F5Командное достижение, поданное как личное, — проверяется через референсы

Как мы думаем об архитектуре AI-команды

У вопроса «кого нанимать первым?» нет универсального ответа — но есть структурный. Первый найм зависит от того, что вы строите и что уже есть, и он задаёт потолок для всего, что после.

Типовая логика первого найма

AI-фича внутри существующего продукта → AI product engineer, а не исследователь
ML-ядро, где данные — это moat → ML-инженер плюс фундамент данных, сначала
Ещё выясняете, нужен ли AI вообще → advisory или fractional-лидер, а не full-time найм

Что вы получаете

Результат метода — решение, которое можно защитить, а не папка резюме:

1Короткий список из 3–5 человек, которых мы наняли бы сами
2Письменное суждение о каждом: сильные стороны, риски, что проверить дальше
3Контекст рынка: компенсации, доступность, реалистичные сроки
4Наша честная рекомендация — включая «пока не нанимать», если это правда

Не согласны с чем-то из этого?

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

Обсудить задачу Отправить задачу