Собеседования на аутстаф, которые бесят: истории неудач при найме разработчиков
Собеседование в аутстафе можно сравнить с тестом на IQ, по итогам которого хотят понять насколько ты хорошо сыграешь в постановке Гамлета. Неочевидные задания, созвоны на английском в 2 часа ночи, открытые вопросы, на которые у интервьюера есть свой идеальный ответ — это неполный список того, с чем в реале сталкивались наши разработчики. Опросили их и получили несколько тру-стори о том, как провалить собеседование с любым, даже самым матерым сеньором.
Наш опыт аутстаффинга
У нас в CosySoft много инженеров, которые на проектах заказчиков заняты в качестве аутстаф-специалистов: техническая экспертиза — у нас, менеджмент — у клиента. Проект (или его часть) передают на аутстаффинг, и уже мы ищем подходящих разработчиков из команды.
Для быстрорастущих продуктов это выгоднее, чем найм в штат: можно быстро масштабировать инженерную команду, меньше административной и налоговой нагрузки, гибче строятся управленческие процессы и т.д.
При этом аутстафферы так же проходят технические интервью, но они отличаются от типовых собеседований программистов в штат.
Что от аутстаф-собеседования ждет заказчик: удостовериться, что, запрашивая middle java developer, он получит именно его знания и коммерческий опыт, а не junior'а после курсов c опытом прохождения собеседований.
Что ждет программист: понять, будет ли на проекте новый профессиональный опыт, за которым он как увлеченный программированием человек гонится. Современный стек, задачи, ценность продукта. От проекта к проекту может меняться многое, но от этого и растет крутость его как инженера, и ценность, и цена в виде зарплаты.
По сути в компанию приходит готовый специалист (давно прошедший у нас первичные фильтры по хард и софт-скиллам), которому нужно рассказать о проекте и проверить, насколько он подходит под определенный пул задач в нужной предметной области.
Но не всегда собеседования проходят именно так. Интервьюеры могут превращать проверку навыков в настоящий экзамен, который не несёт пользы ни одной из сторон. За примером далеко ходить не нужно, многие разработчики рассказывают, как Яндекс строго отсеивает соискателей через «олимпиадные» задачи, чтобы потом победителям предложить… верстать формочки.
За время работы у наших программистов накопилось некоторое количество историй с трешовых собеседований — ниже расскажем о самых ярких из них.
1. Поди туда — не знаю куда, принеси то — не знаю что
Вместо подробного описания проблемы, которую придется решать, получаете размытые формулировки. Что за проект, что нужно делать, какая роль в нем отведена лично вам — не озвучивается. А вдруг придется выполнять не только свои обязанности, но и еще за соседа пахать? Поэтому велик риск, что самому аутстафферу проект перестанет быть интересен уже на этом этапе и до выхода не дойдет.
Совет: подробно рассказывайте о проекте, освещайте проблемы, чтобы специалист мог уже на собеседовании понять, с чем ему придется работать. Распишите должностные обязанности. Расскажите, чем предстоит пользоваться в работе.
2. Сдаем экзамен
Вместо уточнения, какие навыки и кейсы есть у разработчика, на собеседовании проводится допрос с пристрастием. Нужно рассказать теорию, вспомнить даже самые мелкие правила и объяснить основные понятия. При этом подобное знание терминологии может совсем не пригодиться на проекте.
Еще один вариант — тест по теории с вариантами ответов. Тут вообще трудно будет оценить практические навыки соискателя. Только за долговременную память похвалить или умение угадывать правильные ответы.
Совет:
для поиска подходящего мидла или сеньора подойдут вопросы с фокусом на конкретный опыт. В идеале получить от кандидата кейсы, с которыми он работал. Например, если специалист переводил проект с JS на TS, спросить, какие были трудности, что получилось и почему и т.д.
Если хотите добавить технические вопросы, спрашивайте только о том, что точно пригодится сотруднику в дальнейшей работе, а не о содержании 37 страницы 7 строки спецификации языка (смеётесь, а зря, и такое бывает).
Совет 2: если на проекте нужно просто «перекрашивать кнопочки, фиксить мелкие баги» и больше ничего, то нет смысла даже лезть в темы паттернов. На такие задачи достаточно просто нанять джуна и сэкономить IT-бюджет любимой компании 🙂
3. Ой, у вас ночь?
Не указывать в вакансии, что вам нужен сотрудник под определенный график работы — не корректно. Весь IT & Digital работает удаленно из разных уголков мира, с разными часовыми поясами.
Совет: уточняйте, в каком часовом поясе работает команда проекта. Хотите, чтобы разработчик был онлайн с 21:00 до 06:00 по МСК? Пропишите, это важно для обеих сторон.
4. Открытые вопросы, закрытые ответы
Некоторые компании задают открытые вопросы, заведомо ожидая на них определенный ответ. Например, на вопрос «с какой самой большой проблемой вы сталкивались на работе?» ждут ответ в стиле «у меня не было серьезных проблем», а не рассуждения соискателя. Если оценивать уровень пригодности только по таким вопросам, можно упустить хорошего специалиста.
Совет: открытые вопросы требуют размышлений и обязывают соискателя раскрыть свое отношение или мнение. С помощью них вы можете посмотреть, как реагирует соискатель, как рассуждает и строит логические цепочки. Правильных ответов на них не существует, если это не прописная истина. Хард скиллы играют для вас решающее значение? Смело сокращайте количество таких вопросов либо полностью убирайте их.
5. Интервьюер не знает, кто ему нужен
Иногда компании указывают в требованиях к вакансии одно, а хотят получить другое. К примеру, ищут еще одного разработчика, а команде для роста производительности больше поможет проджект. В итоге на проект попадает совершенно не тот, кто нужен, дедлайны срываются, тратятся лишние деньги и человекочасы.
Совет: четко продумайте реальную потребность производства, а только потом прописывайте роль того, кто вам нужен и с какими технологиями предстоит работать.
6. Нам нужен только идеальный кандидат
Некоторые компании не готовы рассматривать кандидата при малейшем отклонении от списка скиллов и технического стэка. Это может надолго затянуть поиск кандидата.
Совет: приоритезируйте требования, распределите, что будет главным при оценке кандидата, а что можно проигнорировать. Здесь хорошо работает армейский принцип «не знаешь — научим»... Не путайте с «не хочешь — заставим», он не работает...
Найти сразу идеальное совпадение — большая удача, обычно нужно погружение в проект, а на полное включение могут уйти недели. За это время можно научить основам любой используемой технологии. Идеально может подходить только сеньор с вашего же проекта. Остальных так или иначе учить, смиритесь с этим.
7. Одинаковый список вопросов для всех специалистов... в Google Forms
Для новой позиции создается гугл-форма с вопросами, которые не подлежат редактуре. И все проходящие специалисты оцениваются строго по ней. Иногда доходит до смешного: форма без всякого внешнего контроля и ограничения по времени, так ещё и с вариантами ответов. Как ЕГЭ проходить :)
Совет: подходить к каждому собеседованию в индивидуальном порядке. Не хотите придумывать для каждого новый список вопросов, хотя бы частично меняйте их, перемежая кейсами и практическими заданиями.
Вместо вывода
Не стремитесь сделать собеседование подобием игрового уровня битвы с боссом. Это не экзамен, а способ убедиться, что пришел специалист нужного уровня. И проверить, насколько сотрудник подойдет команде.
Если собеседование в разы сложнее реальной работы, ожидания соискателя могут не оправдаться, и вы получите демотивированного сотрудника. А чем ближе тестовые задания будут приближены к реальным задачам, тем выше шанс получить подходящего вам разраба.
Все совпадения не случайны, а истории не вымышлены.
