Собеседование — это не экзамен

Я всё чаще думаю, что мы иногда неправильно проводим собеседования.

Обычно всё выглядит примерно так: берём список вопросов по soft skills, отдельно — по hard skills, добавляем немного теории, пару вопросов про процессы.

Как проводишь code review? Как декомпозируешь задачи? Чем модульный монолит отличается от микросервисов? Как работает REST?

А иногда ещё и live coding.

В итоге можно получить человека, который очень хорошо прошёл собеседование, но совершенно не подходит именно вам.

Потому что мы проверяли знания.

А нанимаем человека обычно совсем для другого — чтобы он закрыл конкретные проблемы.

Сейчас, например, я ищу технического лидера.

В нашей модели это человек минус 1 от CTO, за которым закрепляется довольно большое техническое направление.

Пока этого человека нет, часть его работы делаю я.

Я могу посмотреть на свой календарь и довольно быстро понять, кого на самом деле ищу.

Мне приходится заходить в code review по Java и Swift.

Смотреть утром мониторинг.

Разбираться с архитектурными вопросами.

Проводить one-to-one.

Разруливать сложные ситуации между командами.

Обсуждать технические решения с бизнесом.

Вот это и есть требования к вакансии.

Не абстрактное «знает микросервисы», а: сможет ли человек забрать у меня вот этот кусок работы и сделать так, чтобы организации стало легче?

Мне кажется, это вообще хороший вопрос для любого найма.

Если завтра этот человек выйдет на работу — что конкретно перестану делать я, команда или кто-то ещё? Какие проблемы должны исчезнуть?

И уже из этого надо строить интервью.

Не составлять сто вопросов, а собирать реальные кейсы, максимально похожие на будущую работу.

Например: «У тебя пять команд. У одного сервиса растёт error rate, бизнес уже пишет в чат, разработчики говорят, что проблема во внешней системе. Что будешь делать?»

И дальше интересно не услышать правильный термин.

Интересно посмотреть, как человек думает.

Какие вопросы задаёт.

С чего начинает.

Как отделяет факты от предположений.

Когда идёт смотреть код, когда — метрики, когда — разговаривать с людьми.

Берёт ли ответственность. Умеет ли сказать: «Я пока не знаю».

Причём один и тот же технический лидер может отлично подходить одной компании и совершенно не подходить другой.

Организационные модели разные.

Где-то TL почти не занимается людьми. Где-то у него половина работы — people management. Где-то PO ждёт еженедельной личной синхронизации. Где-то архитектуру принимает отдельный комитет. Где-то технический лидер сам должен всё протащить от идеи до прода.

Поэтому универсального «хорошего кандидата» практически не существует.

Есть человек, который подходит или не подходит под конкретную систему.

Ещё две вещи, которые мне сильно помогают на онлайн-собеседованиях.

Первая — давать небольшую задачу прямо во время разговора.

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

Я стараюсь немного менять такие задачи от кандидата к кандидату.

Тут гораздо сложнее подготовить заранее красивый ответ. И очень хорошо видно ход мысли.

Вторая вещь оказалась ещё полезнее — пересматривать запись собеседования.

Не сразу. Например, следующим утром.

Очень часто первое впечатление меняется.

Начинаешь замечать паузы, реакции, то, как человек отвечал на неудобные вопросы, где уходил от ответа, где, наоборот, спокойно признавал, что чего-то не знает.

Но есть ещё один неожиданный бонус.

На записи ты видишь не только кандидата.

Ты видишь себя.

Какие вопросы задавал. Перебивал ли. Давал ли человеку договорить. Не подсказывал ли ответ формулировкой вопроса. Действительно ли проверил то, ради чего вообще открыта вакансия.

Получается практически бесплатная обратная связь самому себе.

Поэтому сейчас я стараюсь смотреть на найм довольно просто:

Собеседование должно отвечать не на вопрос «насколько много человек знает?», а на вопрос «станет ли нам с этим человеком лучше?»