Найм под конкретную перегруженную роль, а не чтобы «рук стало больше». Решение опирается на рубрику, а не на ощущение «вроде нормальный чувак» – ощущение ловит предвзятость, рубрика ловит кандидата.

Что проверяем (по грейду)

КомпетенцияДжунМидлСеньор
Код / инженерияБазовые структуры, чистый кодДекомпозиция, edge-кейсыАрхитектура, чужие домены под давлением
Система и контекстУчит свой модульВидит сервис целикомДержит систему + параллельные миграции
СамостоятельностьПод присмотромДоводит до продаСтавит направление
КоммуникацияПонятно излагаетАргументирует выборВлияет через аргументы, а не саботаж

Структура интервью (60–90 минут)

  • Знакомство (5 мин) – о роли и команде, честно.
  • Опыт / контекст (10 мин) – реальный кейс из прошлого: какую проблему решал, как.
  • Практика (40–60 мин) – задача близкая к реальной, а не алгоритм в вакууме.
  • Культура / поведение (10 мин) – конфликты, ошибки, работа в неопределённости.
  • Вопросы кандидату (5–10 мин).

Поведенческие вопросы (STAR)

  • Расскажи про случай, когда ты ошибся в проде. Что делал? Чему научился?
  • Спорил ли ты с тимлидом/заказчиком о решении? Как разрешал?
  • Был ли момент, когда не хватало контекста? Как доставал?

Красные флаги

  • Сваливает все провалы на коллег и «токсичную атмосферу».
  • Технологии выбирает по хайпу, не по задаче.
  • Не может объяснить «почему» за своими прошлыми решениями.
  • Уничижительно о бывших командах.

Чек-лист решения

  • Нанимаем под конкретную роль/компетенцию (какую именно?)?
  • Есть дублёр/онбординг на ключевые знания (бас-фактор)?
  • Все интервьюеры сошлись по рубрике, не только по «общему впечатлению»?
  • Что будет через 3 и 6 месяцев – как оценим успех найма?