Ошибка найма или ретроградный Меркурий?

Дарья, здрвствуйте!
Очень здорово Вы написали в заголовке ) потому что иногда действительно хочется сослаться на ретроградный Меркурий (Венеру и кто там еще может быть).
Редко, но такие "попадания" случаются и, мне кажется, тут не обходится без очень сильного желания кандидата показать то, чего нет на самом деле.
У меня была ситуация с выходом кандидата на должность начальник отдела охраны труда. Он прошел "на ура" все этапы собеседований (от рекрутера до своего непосредственного руководителя, включая сбор рекомендаций). А когда вышел на работу начал "чудить": грубить, отказываться принимать решения и т.д. Пришлось расстаться.

Здравствуйте, Дарья!
+ Ваш кейс говорит о том, что комплекс причин было, которые привели к прекращению сотрудничества.
+ Ошибка рекрутера здесь в том, что не были должным образом оценены риски "несовпадений".
Я имею в виду: применение парного программирования, возможности самостоятельного выбора сотрудником способов решения технических задач.
+ Так как в посте указано что уровень позиции Tech Lead/Senior, то ДА, это ошибка рекрутера в основном.
Но не он один виноват, потому как его задача предоставить кандидатов на выбор.

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

Добрый день! В таких случаях я в первую очередь смотрю в ТЗ. Со своими клиентами всегда стараюсь составить максимально подробное техническое задание, включающее так называемые «красные флаги» для заказчика, а также стараюсь узнать «красный флаг» для соискателя.

Соглашусь с коллегами: в данном случае это совокупность факторов. Можно ли было избежать этой ситуации? Возможно, но без 100% гарантии.

Даже если бы вы спросили клиента, что он считает недопустимым в поведении сотрудника, обычно отвечают общими стандартными фразами. Редко кто вспоминает о реальных «красных флагах».

Можно было задать вопрос кандидату: что он считает неприемлемым в работе? Возможно, он бы рассказал о своём отношении к парному программированию.

Мне кажется, в этой ситуации, поскольку речь идёт об испытательном сроке, можно было попробовать сторонам договориться:

- работодатель рассказывает, что приемлемо и неприемлемо для компании и почему;
- сотрудник рассказывает, что приемлемо и неприемлемо для него и почему.

И при обоюдном желании стороны пытаются договориться и продолжить взаимовыгодное сотрудничество.

В описанной ситуации создаётся ощущение, что каждая из сторон подумала, будто их требования — это само собой разумеющаяся история, и не стали озвучивать свои ожидания. Теперь для нас это интересный кейс, который позволит дополнить ТЗ для заказчика при определении портрета кандидата.

Спасибо за полезную историю.

Добрый день.

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

Если компания работает в формате парного программирования и строго следует согласованной архитектуре, это не «деталь», а часть культуры. Значит, на этапе интервью нужно было глубже проверять отношение кандидата к таким форматам: как он работает в команде, как реагирует на ограничения, готов ли принимать коллективные решения.

И второй момент-погружение. Онбординг не только про процессы и инструменты. Это ещё и про управленческие принципы: как здесь принимаются решения, что считается нормой, где границы автономии.

Сильный Senior может быть отличным специалистом, но не подойти по стилю взаимодействия. И тогда это не про ретроградный Меркурий, а про несогласованные ожидания с обеих сторон.

Дарья, добрый день.
Согласна с предыдущими высказываниями про непопадание кандидата в культуру компании. С другой стороны, онбординг тоже должен быть индивидуальным, а не "всех под одну гребенку"

Дарья, коллеги, всем продуктивной среды!

Я в ретроградный Меркурий в найме не верю, а вот в несовпадение рабочих моделей вполне. По описанию это не столько ошибка рекрутера или онбординга, сколько недоговоренность на берегу: кандидат привык к автономии и своему способу писать код, а компания - к парному программированию и коллективным решениям. Технический скилл совпал, а способ работы - нет, и именно это в итоге «сломало» сотрудничество.

В отборе в первую очередь смотрю не только на опыт и навыки, а на поведенческую совместимость с процессами команды. Прямо проговариваю спорные моменты: как принимаются решения, есть ли код-ревью, насколько допустима «своя логика» против общей. Если на этом этапе человек морщится или начинает «я бы делал иначе», это уже сигнал. Скилы можно масштабировать, а вот привычки работы и отношение к правилам меняются сильно сложнее!

Дарья, коллеги, добрый день,

Согласна с Александром - нежно было запросить обратную связь с предыдущих мест работы. Узнать о стиле работы кандидата.
А дальше - управление этим сотрудников и что и как ты делаешь, у нас так можно, а так нельзя.

Дарья, добрый день!
Спасибо за вопрос!
Мне кажется, в вашем случае произошло "комбо": с одной стороны, недостаточно подробно рассказали о процессе на этапе интервью, с другой - на техническом собеседовании, возможно, не до конца уловили ход мышления кандидата.

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

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

У меня часто бывает такое: проводим лайвкодинг, кандидат задачу решает, но обратная связь от нанимающего менеджера - "не подходит". Задачу решил, но то, как он ее реализовал, не совпадает с тем, как это видит тимлид.

Я впервые слышу про увольнение с формулировкой "он писал программу иначе, как ему казалось более рационально". Это, наверное, как раз тот случай, когда техническое собеседование должно было выявить не только умение решить задачу, но и стиль мышления, подход к коду.