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

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

В этом есть определённая ирония. Компания может месяцами искать самостоятельного Senior, жаловаться на нехватку сильных инженеров, а потом отказаться от человека именно за те качества, ради которых открывала вакансию.

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

И попробуй потом разобраться, чего именно не хватило, знаний Java, опыта проектирования или готовности соглашаться с будущим руководителем.

Когда сильный специалист становится неудобным

Представим команду, в которой технические решения годами принимает один руководитель. Он хорошо знает продукт, привык контролировать архитектуру и распределять задачи.

Компания открывает позицию Senior Backend Developer, чтобы разгрузить его и усилить команду. На интервью приходит инженер с опытом проектирования высоконагруженных систем. Он интересуется архитектурой, задаёт вопросы о техническом долге, предлагает альтернативные решения. Причём делает это вполне корректно, без попыток доказать всем окружающим, что они ничего не понимают.

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

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

Это не только мои наблюдения. В исследовании Not your average candidate: overqualified job applicants in the eyes of hiring practitioners специалисты, участвующие в найме, описывали опасения руководителей перед кандидатами, чья квалификация может угрожать их положению или авторитету.nКонечно, из этого нельзя сделать вывод, что каждый Team Lead намеренно избавляется от сильных инженеров. Но сам механизм существует, и закрывать на него глаза было бы странно.

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

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

Особенно если в вакансии написано «инициативность, самостоятельность и готовность влиять на технические решения».

Возможно, влиять можно. Но только в пределах уже согласованного мнения руководителя.

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

Другая ситуация, которая часто вызывает недоумение у кандидатов.

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

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

Компания выбирает второго.

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

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

Но есть и обратная сторона.

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

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

«Он у нас заскучает». Когда за кандидата уже всё решили

Одна из самых любопытных причин сомнений — предположения о будущей мотивации человека. Например, разработчик несколько лет руководил командой, а теперь хочет вернуться к индивидуальной разработке. На интервью объясняет, что устал от менеджерских задач и хочет больше заниматься технической частью.

Но руководитель всё равно сомневается: вдруг через полгода ему станет скучно, он снова захочет управлять или найдёт позицию с большей ответственностью?

Опасения понятны. Нанимать человека, который уйдёт через три месяца, никому не хочется. Только между оценкой рисков и попыткой предсказать за кандидата всю его карьеру есть разница. Я встречала ситуации, когда решение строилось скорее на представлениях работодателя о том, чего «должен хотеть» специалист с определённым опытом, чем на его реальных ответах.

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

• Руководил людьми? Обязательно захочет снова.

• Проектировал сложные системы? Значит, обычная разработка его не заинтересует.

При таком подходе можно отказать практически любому опытному специалисту. Главное достаточно хорошо пофантазировать о его будущем.

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

А что скрывается за «не подошёл по soft skills»?

Ещё одна формулировка, которую я всегда предпочитаю уточнять. Потому что под ней могут скрываться совершенно разные вещи. Кандидат действительно не умеет слушать, агрессивно реагирует на обратную связь и не способен объяснить собственное решение? Это проблема, особенно если предстоит много работать с командой.

Или человек просто не согласился с интервьюером?

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

В обоих случаях поведение кандидата одинаковое. Отличается восприятие.

Это не означает, что все субъективные оценки неправильные. Но если компания не определила, что конкретно понимает под коммуникацией, самостоятельностью и командной работой, критерий «подойдёт коллективу» легко превращается в обычное «понравился или нет».

Особенно интересно, когда руководитель ищет специалиста, способного принимать решения самостоятельно, но при этом любое несогласие воспринимает как спор с начальством.

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

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

Что можно выяснить о руководителе ещё на интервью

Я часто рекомендую кандидатам оценивать не только вакансию и технологии, но и человека, с которым предстоит работать. Особенно если вы рассматриваете Senior- или Lead-позицию.

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

Здесь важны не столько сами ответы, сколько конкретика. Если руководитель способен объяснить ограничения, привести примеры решений и спокойно обсудить альтернативы, это уже полезная информация о будущей работе. При этом один неудачный ответ ещё ничего не доказывает. У компании могут быть объективные причины сохранять существующую архитектуру или централизовать принятие решений. Но если любой вопрос вызывает раздражение, стоит задуматься, насколько вам будет комфортно работать в этой среде.

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

Так почему оффер получил другой?

Вернёмся к исходному вопросу.

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

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

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

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

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

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

Разработчики, бывало ли у вас, что после удачного технического интервью вы получали отказ без понятного объяснения?

А Team Lead и CTO случалось ли вам отказывать технически сильному кандидату, потому что его самостоятельность или подход к работе могли создать сложности в команде? Где для вас проходит граница между сильным инженером и неудобным сотрудником?