Найти за 60 минут. Советы по найму в IT, подводные камни и истории из практики

Наверное, если посчитать, окажется что задачам поиска сотрудников я отдал не менее 10% от своего рабочего стажа. Уж точно, нанял более 300 специалистов самых разных специальностей — от офис-менеджеров до программистов и руководителей подразделений.

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

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

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

В активе:

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

2. Наём идет на конкретную позицию с ограниченными обязанностями. То есть задачка чуть попроще, чем поиск друга.

Список факторов, которые могут привести к провалу, чуть длиннее:

1. Интервьюер не обладает специальными навыками проведения собеседования. Не всегда это фатально, но чаще всего интервьюер либо забывает важные аспекты, либо, наоборот, пускается во все тяжкие и «валит» так, как будто отбирает в отряд космонавтов.

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

Можно сказать, что на всех кандидатах, что были в первые две недели, я просто учился. Я не мог сделать выбор, потому что одних я спрашивал одно, других — другое, третьи перетягивали инициативу на себя, и я большую часть времени рассказывал про задачи, ничего не выясняя про кандидата. Хорошо, что в то время рынок труда позволял сказать «через 2 недели мы завершим 1-й этап отбора и пригласим лидеров на 2-й раунд собеседований».

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

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

3. Мы все находимся в иллюзии, что «чувствуем ложь» и «читаем между строк». Скажете, я преувеличиваю и вы то уж точно объективны в своих оценках? нобелевский лауреат Даниэль Канеман в своей книге «Думай медленно… решай быстро» несколько глав посвятил разбору подобных когнитивных искажений.

Это и эффекты эмоциональной когерентности (человеку, который вам эмоционально понравился, вы склонны приписывать и другие положительные качества), и явление «что ты видишь, то и есть» (получив первичную информацию о предмете, мозг с неохотой принимает во внимание новые данные) — и многие другие ловушки для мозга.

4. Сам формат собеседования заставляет обе стороны украшать реальность или скрывать неприятные детали. Кто из нас признается, что как-то провел половину рабочего дня в общении с друзьями или залип на ленте в соцсети?

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

И уж точно вам никто не скажет правду, если перед тем же вопросом вы расскажете, что у вас внедрена система ежедневной отчётности о потраченном времени.

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

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

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

Каков будет результат? Он либо пропустит всех либо «зарубит» всех до единого. Причина в том, что для него они все одинаково некомпетентны. Чтобы исключить такие ситуации, стоит на берегу детально обсудить с каждым участником что именно он будет спрашивать и как будет это оценивать.

6. Перекос айтишного рынка труда в сторону работника заставляет существенно сокращать длительность и количество собеседований с одним кандидатом. Если 15 лет назад 4-часовые собеседования и тестовое задание на пару дней были нормой для программистов, то сейчас такое могут позволить себе только топовые компании (те, что имеют достаточно маркетинговых ресурсов, чтобы привлечь к себе внимание школьников и студентов. Именно для этого Сбер, «Яндекс», Google, Microsoft чуть ли не с начальной школы спонсируют олимпиады, стажировки и конференции, открывают школы имени себя и постоянно рассказывают о своих достижениях в области IT и AI.

Не буду рассказывать, какие трансформации претерпел процесс найма в моей компании, но на сегодня это выглядит так:

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

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

• Основной стек — .Net.

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

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

• Большая часть команды — в часовом поясе зауралья.

• …

Основные правила при составлении списка: максимальная подробность и конкретность.

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

Из всех собранных на первом этапе требований выделяется 5-6 наиболее значимых факторов успешного найма. Список хотелок жёстоко урезается.

Например, остаётся:

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

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

Список вопросов фиксируется в виде памятки для интервьюеров.

Вопросы тестируются на существующих специалистах.

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

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

Все собеседование мы всегда стремимся уложить в 1 час.

Каждый вопрос оценивается по шкале от 1 до 3:

• 1 — плохо
• 2 — нормально
• 3 — хорошо

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

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

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

Балльная оценка вообще многое проясняет: порой по ней заметно, что кто-то из команды просто «выключился» на каком-то этапе интервью и поставил баллы «от балды».

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

Ну и раз мы говорим про IT, то никак нельзя пройти мимо пункта 0. Всегда помните, что оцениваете не только вы, но и вас. Поэтому потратьте время с командой и найдите аргументы, которые «драйвят» именно вас — вы же ищете тех, кто будет на одной волне с вами!

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

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