Собеседования на аутстаф, которые бесят: истории неудач при найме разработчиков

Собеседование в аутстафе можно сравнить с тестом на IQ, по итогам которого хотят понять насколько ты хорошо сыграешь в постановке Гамлета. Неочевидные задания, созвоны на английском в 2 часа ночи, открытые вопросы, на которые у интервьюера есть свой идеальный ответ — это неполный список того, с чем в реале сталкивались наши разработчики. Опросили их и получили несколько тру-стори о том, как провалить собеседование с любым, даже самым матерым сеньором.

Наш опыт аутстаффинга

У нас в CosySoft много инженеров, которые на проектах заказчиков заняты в качестве аутстаф-специалистов: техническая экспертиза — у нас, менеджмент — у клиента. Проект (или его часть) передают на аутстаффинг, и уже мы ищем подходящих разработчиков из команды.

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

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

Собеседования на аутстаф, которые бесят: истории неудач при найме разработчиков

Что от аутстаф-собеседования ждет заказчик: удостовериться, что, запрашивая middle java developer, он получит именно его знания и коммерческий опыт, а не junior'а после курсов c опытом прохождения собеседований.

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

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

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

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

1. Поди туда — не знаю куда, принеси то — не знаю что

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

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

Ну, просто…

Леся, системный аналитик CosySoft

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

2. Сдаем экзамен

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

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

На собесе в крупную промышленную компанию гоняли по теории на протяжении 45 минут: просили вспомнить принципы SOLID, рассказать про паттерн «декоратор», ответить, как работает сортировка пузырьком и еще много подобного.

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

Сергей, Front-end разработчик

Совет: для поиска подходящего мидла или сеньора подойдут вопросы с фокусом на конкретный опыт. В идеале получить от кандидата кейсы, с которыми он работал. Например, если специалист переводил проект с JS на TS, спросить, какие были трудности, что получилось и почему и т.д.

Если хотите добавить технические вопросы, спрашивайте только о том, что точно пригодится сотруднику в дальнейшей работе, а не о содержании 37 страницы 7 строки спецификации языка (смеётесь, а зря, и такое бывает).

Совет 2: если на проекте нужно просто «перекрашивать кнопочки, фиксить мелкие баги» и больше ничего, то нет смысла даже лезть в темы паттернов. На такие задачи достаточно просто нанять джуна и сэкономить IT-бюджет любимой компании 🙂

3. Ой, у вас ночь?

Не указывать в вакансии, что вам нужен сотрудник под определенный график работы — не корректно. Весь IT & Digital работает удаленно из разных уголков мира, с разными часовыми поясами.

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

Андрей, Flutter-разработчик

Совет: уточняйте, в каком часовом поясе работает команда проекта. Хотите, чтобы разработчик был онлайн с 21:00 до 06:00 по МСК? Пропишите, это важно для обеих сторон.

4. Открытые вопросы, закрытые ответы

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

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

Менеджер проводил собеседование в привычном ему стиле (как при обычном найме в инхаус-команду) и ждал ответ в стиле «потому что вы классные», а получил другой.

Иван, Front-end разработчик

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

5. Интервьюер не знает, кто ему нужен

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

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

Наталья, аккаунт-менеджер

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

6. Нам нужен только идеальный кандидат

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

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

Марк, Front-end разработчик

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

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

7. Одинаковый список вопросов для всех специалистов... в Google Forms

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

Несколько специалистов проходили первичный отбор. Нужно было заполнить блиц-опрос, по результатам которого будет выбран человек для интервью. Тестирование проходило в разные дни. Что мешало запомнить вопросы и передать следующему? Правильно, ничего)

Сергей, Front-end разработчик

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

Вместо вывода

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

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

Все совпадения не случайны, а истории не вымышлены.

3939
47 комментариев

Что ждет программист: понять, будет ли на проекте новый профессиональный опыт, за которым он как увлеченный программированием человек гонитсяМмм… не. Программист ждёт адекватную зарплату и не менее адекватный коллектив. Работа интересной бывает крайне редко, с этим все уже смирились. Для интересов есть pet проекты, stackoverflow и т.д.

15
Ответить

Ну, видимо, Вам просто не везло...

2
Ответить

Ну нет, совсем не обязательно

1
Ответить

Ребзя, а в чем подводные камни аутстафа для спеца?
Зачем условному мне идти в компанию через аутстаф, а не напрямую к ним инхаус?

4
Ответить

Тут будет уместна аналогия с женой (инхаус), любовницей (аутсорс) и домработницей (аутстафф).

Конечным работодателям, потребителям услуг аутстаффинга/аутсорсинга, часто не нужен человек в штат на постоянку (жена). Нужен на несколько месяцев разработчик, чтобы потестировать гипотезы, отрефакторить технический долг, подменить инхаус-разработчика на длительном больничном и т.д.

Из плюсов для спеца - более экстенсивное развитие. Через пару лет у вас будет резюме из крупных проектов, типа Сбера, Яндекса, ВТБ и т.д. Если идти этот путь самостоятельно, первые пару лет в резюме будет ИП Пупкин и ООО Вектор)

9
Ответить

Проще сменить проект если текущий не нравится или перестал нравится, больше упора на теоретические знания, т.к. нужно готовиться к собесам. Больше вариантов попасть в свежий проект а не работать с легаси. Но это в идеальном варианте. Такое можно получить и в продуктовой компании. И в аустафе можно наткнуться на лютое легаси и закидывание в хреновые проекты без возможности смены. Вообще не плохо разбирается тут - https://www.youtube.com/watch?v=NJQe6bWQa6o

2
Ответить

Иногда не хочется напрямую

Ответить