Почему карьерная матрица не работает на собеседованиях и как это исправить

Пятеро опытных интервьюеров провели с кандидатом четыре часа. Двое сказали «да» — он им понравился, разговор шёл легко, «схватывает на лету». Двое сказали «нет» — смутное ощущение, что глубина ответов не та. Пятый пытался вспомнить, какие моменты были с этим кандидатом, а какие — с позавчерашним. На столе — ни одной бумажки, которая подтверждала бы хоть что-то, кроме личных симпатий. Знакомая картина? Мы в группе компаний «Алмаз» наблюдаем её регулярно, когда помогаем выстраивать процессы найма.

Проблема не в том, что компания не потрудилась написать карьерную матрицу. Как раз наоборот: матрица есть, грейды расписаны, компетенции разложены по ячейкам. Беда в том, что матрица писалась для performance review, а не для собеседований. Она фиксирует результаты, которые видны за два года совместной работы, но молчит о поведении, которое можно заметить за 45 минут разговора с незнакомцем. Итог: решение о найме принимается не по матрице, а по усреднённому образу «последнего хорошего сеньора», который сложился в голове у интервьюера.

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

Почему карьерная матрица не помогает на собеседовании

Типичная матрица для Senior-разработчика содержит строки вроде: «Самостоятельно работает над сложными задачами», «Драйвит улучшения процессов и инструментов команды», «Влияет на техническое направление смежных команд». Всё верно. Но попробуйте с ходу придумать вопрос, который за 20 минут вскроет, способен ли на это человек, которого вы видите впервые. Получится либо слишком общее «Расскажите о вашем самом сложном проекте», либо уход в личные предпочтения интервьюера.

Матрица написана для комитетов по повышениям и калибровок performance review. Она оперирует итогами, а не наблюдаемыми действиями. Когда интервьюер получает такую формулировку, он невольно подменяет её собственной эвристикой. Один начнёт гонять кандидата по системному дизайну, потому что последний успешный сеньор был силён именно в этом. Другой устроит допрос по поведенческим кейсам, потому что предыдущий сеньор провалился на софт-скиллах. Оба тестируют не матрицу, а свой личный опыт. Результат — лотерея, где исход зависит от того, кто именно попал в расписание собеседований.

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

От формулировки к поведению, от поведения к вопросу

Метод, который мы используем в ГК «Алмаз» при разработке моделей компетенций, укладывается в три шага:

1. Выберите одну строку из матрицы для целевого грейда.
2. Спросите себя: как это выглядит в виде наблюдаемого поведения в повседневной работе на конкретной позиции?
3. Сформулируйте вопрос, который вытащит именно это поведение.

Звучит очевидно. На практике почти никто не делает. Возьмём ту же строку: «Драйвит улучшения процессов и инструментов команды». Что значит «драйвит улучшения» для бэкенд-разработчика на платформенной команде? Это не абстрактная инициативность. Это цепочка действий: заметил, что деплой стал занимать больше времени, чем должен; не ограничился тикетом в бэклоге; раскопал причину; написал короткое предложение; договорился с командой попробовать в ближайшем спринте; замерил разницу; поделился выводами. Вот это уже поведение, которое можно зацепить вопросом.

И вопрос тогда рождается почти механически: «Расскажите о случае, когда вы изменили то, как работает ваша команда или смежная. С чего всё началось и чем закончилось?» Он открытый, чтобы кандидат мог рассказать свою историю, и достаточно конкретный, чтобы отсечь гипотетические рассуждения и лозунги. Сравните с типичным «Приведите пример, когда вы проявили лидерство». Кандидат выдаст историю. Возможно, о лидерстве. А возможно, о проекте, где лидером был кто-то другой, а он просто был рядом. Вы не узнаете, потому что вопрос не был привязан к ячейке матрицы.

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

Впечатления — не доказательства

Допустим, все интервьюеры зашли в комнату с правильными вопросами. Это половина дела. Вторая половина — что они вынесут из комнаты. Поднимите записи с трёх последних собеседований. Сколько там того, что кандидат реально сказал или сделал? А сколько — вашей интерпретации?

Практика показывает: даже вдумчивые интервьюеры приносят на обсуждение заметки, которые на 80% состоят из впечатлений. «Казался неуверенным на системном дизайне». «Реально шарит в PostgreSQL». «Жёсткая позиция по тестированию». Это не доказательства. Это summary ощущений. Другой интервьюер в той же комнате мог бы написать прямо противоположное и быть столь же уверенным в своей правоте.

Решение — перестать фиксировать впечатления и начать фиксировать доказательства. То, что кандидат сказал дословно. Какое решение принял вслух. Какие цифры назвал. Какие компромиссы обозначил. Какие вопросы задал вам. «Казался неуверенным» — не доказательство. «Замолчал секунд на двадцать, потом сказал, что не уверен, как подступиться» — доказательство. Первое — ваша оценка. Второе — то, что зафиксировала бы видеокамера. Именно «видеокамерная» версия должна оказаться в заметках.

Когда вы начинаете вести записи так, происходит две вещи. Обсуждение после интервью ускоряется, потому что все оперируют одним типом материала. И — что важнее — становится видно, кто из интервьюеров на самом деле слушал, а кто вежливо кивал 45 минут, а потом записал общее впечатление. Немалая часть кадровых решений сегодня принимается именно по «вайбу». Пора это менять.

Четыре типа доказательств

В интервью можно собрать четыре вида доказательств. У каждого — свой вес и своя зона применения. Расположим их по убыванию ценности для найма.

• Опытные доказательства (experiential). То, что кандидат реально делал. «Расскажите о случае, когда…», «Приведите пример…», «А что было дальше?». Самый ценный вид. Настоящие истории содержат детали, противоречия, нестыковки — и выдерживают несколько уточняющих вопросов. Отполированные рассказы, которые не рассыпаются при детализации, обычно правдивы.
• Гипотетические доказательства (hypothetical). Что кандидат думает, что сделал бы. «Что бы вы предприняли, если бы…», «Если бы пришлось переделывать тот проект, что бы изменили?». Гипотезу не докажешь, зато видно, как человек рассуждает: как раскладывает проблему, что спрашивает, какие компромиссы называет без подсказки. Особенно полезно для кандидатов без богатого опыта.
• Мнения (opinion). Что кандидат думает по тому или иному поводу. «Ваше отношение к TDD?», «Что делает код-ревью хорошим?». Интересно на двух уровнях: само мнение говорит о вкусе и насмотренности; реакция на возражение — о гибкости и аргументации. Я не раз узнавал о кандидате больше из того, как он держал удар в споре, чем из самого мнения.
• Формальные подтверждения (credential). Дипломы, сертификаты, знание инструментов. Иногда критичны (например, в регулируемых отраслях), но для большинства позиций — самый лёгкий по весу вид доказательств.

Большинство провальных интервью, которые я наблюдал, были перегружены мнениями и формальными подтверждениями, бедны опытными доказательствами и почти не содержали гипотетических. Ровно обратное соотношение. Мнение и корочку подделать легче всего. Опыт — труднее всего, особенно если продолжать спрашивать «а что вы сделали потом?», пока история либо сойдётся, либо нет.

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

Калиброванное интервью: соединяем матрицу и доказательства

Теперь склеим две половинки. Калиброванное интервью — это когда каждый вопрос делает две работы одновременно: он привязан к конкретной ячейке матрицы и нацелен на сбор одного из четырёх типов доказательств.

Вернёмся к строке для Senior: «Влияет на техническое направление нескольких команд». Под неё можно собрать небольшой пул вопросов:

• Опытный: «Расскажите о техническом решении, которое вы приняли или на которое повлияли, и которое затронуло хотя бы одну команду за пределами вашей. Как всё развивалось на практике?»
• Гипотетический: «Представьте, что вы пришли к нам на платформенную команду и обнаружили, что две продуктовые команды независимо друг от друга построили разные решения одной и той же проблемы. Ваши действия?»
• Мнение: «Что, по-вашему, отличает хорошее кросс-командное техническое решение от плохого?»

Заметьте: каждый вопрос бьёт в одну точку матрицы, но разными инструментами. На обсуждении после интервью вы сможете сопоставить не просто «понравился / не понравился», а конкретные доказательства по каждой компетенции. Именно такой подход мы закладываем в основу оценки персонала при построении систем найма.

Когда все интервьюеры работают по такой схеме, debrief перестаёт быть гаданием. Вы обсуждаете не «сильный кандидат или нет», а «какие доказательства мы собрали по ячейке