Вредные советы: как завалить интервью и гарантированно получить отказ от кандидата

Многие проводят собеседования, не особо вникая в информацию, которую прислал кандидат. Однако это путь в никуда: для начала нужно внимательно прочитать резюме, узнать, на какую позицию претендует человек, какой уровень скиллов от него требуется. Только после такой подготовительной работы можно смело встречаться с кандидатом, задавать вопросы и проводить сеансы live coding.

Собрал восемь классных советов — они помогут навсегда отвадить кандидата и запороть интервью на стороне работодателя: 100%, без регистрации и смс.

Задавать вопросы для галочки

Допустим, компания разрабатывает базы данных. И вы могли бы задать на собеседовании несколько глубоких вопросов про алгоритмы и деревья. Но если соискателю в работе не нужны эти знания, то зачем спрашивать? Перебирать сотню кандидатов и искать лучшего — не самая выгодная стратегия. Гораздо эффективнее взять первого подходящего — того, кто, на ваш взгляд, справится с проектом. По моему опыту, человек быстро въедет в тему и будет нормально работать, даже если это не лучший в мире кандидат и вы отсмотрели всего пять человек, а не тысячу.

Бывает, что компания по полгода не может найти человека — так она теряет время и деньги на хантинг идеального сотрудника. А на деле для проекта вовсе не нужен весь набор скиллов, которые перечислены в тексте вакансии. Лично мне на большинство позиций не требуются сверхлюди, которые могут сходу придумать какое-то гениальное решение. Если человек понятно формулирует мысли, мне с ним комфортно и мы друг друга понимаем — я его возьму. И без лишних вопросов на собеседовании.

Создавать напряжение во время интервью

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

Сам я проходил разные собеседования: где-то сходу спрашивали, как я решу ту или иную задачу или рабочую проблему, а где-то наоборот — затягивали вступление и 40 минут рассказывали о компании. Это тоже ни к чему.

Врать о компании и проекте, скрывать недостатки

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

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

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

Сам я на собеседованиях могу открыто сказать, что в проекте много legacy. И обязательно поясняю, чем придётся заниматься. Чего мы ожидаем от соискателя.

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

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

Растягивать техническое собеседование

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

Задавать джунам сложные вопросы

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

1. В стартапы брать джунов обычно бессмысленно — чтобы в них работать, надо уже что-то уметь.
2. А для найма в корпорацию такие вопросы и не нужны — джуна все равно придётся обучать почти с нуля. Некоторые представители энтерпрайза даже поставили это на поток: создают инкубаторы стажёров, дают им синтетические проекты и учат на них.

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

Джуны востребованы не потому, что очень нужны. Я даже как-то шутил — мол, джуны вообще-то должны сами доплачивать за работу. Совсем начинающие джуны больше тормозят процесс, чем приносят пользу. За ними обязательно кто-то должен следить — и часто это тимлид.

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

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

Не спрашивать мидлов о предыдущем опыте

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

А вот задавать мидлам теоретические вопросы — например, что такое ООП, — по моему опыту, бесполезно. Ответы на такие вопросы легко нагуглить и запомнить, а зубрёжка не показывает реальных навыков и знаний. Хорошие вопросы — те, над которыми нужно подумать. Что бы ты сделал в конкретной ситуации, считаешь ли ты правильным такой подход, опиши, как бы ты реализовал такой алгоритм. Такие вопросы отлично показывают, как человек принимает решения. И очень хорошо, если человек задаёт встречные вопросы: например, уточняет бюджет и другие ограничения — и только потом даёт ответ.

Если же вы собеседуете сеньоров, то фокусироваться надо не на хард-, а на софт-скиллах. Ключевое — насколько человек способен брать на себя ответственность, принимать решения и аргументировать их.

Не интересоваться уровнем английского

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

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

Кстати, в Украине и Беларуси больше разработчиков со знанием английского: локальные рынки разработки там маленькие, поэтому специалистам приходится конкурировать на международной арене. А ещё в эти страны американским и европейским компаниям зайти легче, поэтому разработчики нередко устраиваются в аутсорсинговые компании или напрямую в Европу и Штаты. Результат — специалисты, лучше адаптированные к международным реалиям, и более высокие зарплаты.

Запрещать гугление во время собеседования

Мы живём в мире огромных объёмов информации. И запомнить всё — просто нереально. Гораздо важнее научиться быстро находить нужное и сразу применять это в работе. Мне не принципиально, чтобы человек помнил все 50 видов алгоритмов, — достаточно, если он способен быстро найти верное решение.

То же самое с методами и библиотеками — не обязательно помнить их все. Если соискатель на собеседовании говорит, что чего-то не помнит, я не считаю это проблемой: предлагаю погуглить и объяснить мне прочитанное простыми словами. И на этом многие срезаются, ведь объяснить что-то — это уже совсем другой уровень понимания.

Выводы

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

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