Собеседование в аутстафе можно сравнить с тестом на IQ, по итогам которого хотят понять насколько ты хорошо сыграешь в постановке Гамлета. Неочевидные задания, созвоны на английском в 2 часа ночи, открытые вопросы, на которые у интервьюера есть свой идеальный ответ — это неполный список того, с чем в реале сталкивались наши разработчики. Опросили их и получили несколько тру-стори о том, как провалить собеседование с любым, даже самым матерым сеньором.
Наш опыт аутстаффинга
У нас в CosySoft много инженеров, которые на проектах заказчиков заняты в качестве аутстаф-специалистов: техническая экспертиза — у нас, менеджмент — у клиента. Проект (или его часть) передают на аутстаффинг, и уже мы ищем подходящих разработчиков из команды.
Для быстрорастущих продуктов это выгоднее, чем найм в штат: можно быстро масштабировать инженерную команду, меньше административной и налоговой нагрузки, гибче строятся управленческие процессы и т.д.
При этом аутстафферы так же проходят технические интервью, но они отличаются от типовых собеседований программистов в штат.
Что от аутстаф-собеседования ждет заказчик: удостовериться, что, запрашивая middle java developer, он получит именно его знания и коммерческий опыт, а не junior'а после курсов c опытом прохождения собеседований.
Что ждет программист: понять, будет ли на проекте новый профессиональный опыт, за которым он как увлеченный программированием человек гонится. Современный стек, задачи, ценность продукта. От проекта к проекту может меняться многое, но от этого и растет крутость его как инженера, и ценность, и цена в виде зарплаты.
По сути в компанию приходит готовый специалист (давно прошедший у нас первичные фильтры по хард и софт-скиллам), которому нужно рассказать о проекте и проверить, насколько он подходит под определенный пул задач в нужной предметной области.
Но не всегда собеседования проходят именно так. Интервьюеры могут превращать проверку навыков в настоящий экзамен, который не несёт пользы ни одной из сторон. За примером далеко ходить не нужно, многие разработчики рассказывают, как Яндекс строго отсеивает соискателей через «олимпиадные» задачи, чтобы потом победителям предложить… верстать формочки.
За время работы у наших программистов накопилось некоторое количество историй с трешовых собеседований — ниже расскажем о самых ярких из них.
1. Поди туда — не знаю куда, принеси то — не знаю что
Вместо подробного описания проблемы, которую придется решать, получаете размытые формулировки. Что за проект, что нужно делать, какая роль в нем отведена лично вам — не озвучивается. А вдруг придется выполнять не только свои обязанности, но и еще за соседа пахать? Поэтому велик риск, что самому аутстафферу проект перестанет быть интересен уже на этом этапе и до выхода не дойдет.
Заказчик искал бизнес-аналитика. На собеседовании мельком обговорили обязанности, про конкретные задачи подробно не рассказали. Я решила, что разберусь со всем на месте: проект по описанию интересный, сложные бизнес-задачи, много внешних интеграций. По факту часть задач была связана... с клиентским аккаунтингом, а почему их решили погрузить на аналитика?
Ну, просто…
Совет: подробно рассказывайте о проекте, освещайте проблемы, чтобы специалист мог уже на собеседовании понять, с чем ему придется работать. Распишите должностные обязанности. Расскажите, чем предстоит пользоваться в работе.
2. Сдаем экзамен
Вместо уточнения, какие навыки и кейсы есть у разработчика, на собеседовании проводится допрос с пристрастием. Нужно рассказать теорию, вспомнить даже самые мелкие правила и объяснить основные понятия. При этом подобное знание терминологии может совсем не пригодиться на проекте.
Еще один вариант — тест по теории с вариантами ответов. Тут вообще трудно будет оценить практические навыки соискателя. Только за долговременную память похвалить или умение угадывать правильные ответы.
На собесе в крупную промышленную компанию гоняли по теории на протяжении 45 минут: просили вспомнить принципы SOLID, рассказать про паттерн «декоратор», ответить, как работает сортировка пузырьком и еще много подобного.
Проект оказался полной противоположностью собеседования — пришлось перекрашивать цвет кнопочек и вносить другие несущественные изменения.
Совет: для поиска подходящего мидла или сеньора подойдут вопросы с фокусом на конкретный опыт. В идеале получить от кандидата кейсы, с которыми он работал. Например, если специалист переводил проект с JS на TS, спросить, какие были трудности, что получилось и почему и т.д.
Если хотите добавить технические вопросы, спрашивайте только о том, что точно пригодится сотруднику в дальнейшей работе, а не о содержании 37 страницы 7 строки спецификации языка (смеётесь, а зря, и такое бывает).
Совет 2: если на проекте нужно просто «перекрашивать кнопочки, фиксить мелкие баги» и больше ничего, то нет смысла даже лезть в темы паттернов. На такие задачи достаточно просто нанять джуна и сэкономить IT-бюджет любимой компании 🙂
3. Ой, у вас ночь?
Не указывать в вакансии, что вам нужен сотрудник под определенный график работы — не корректно. Весь IT & Digital работает удаленно из разных уголков мира, с разными часовыми поясами.
Прошел собеседование на англоязычный проект. Тимлида заказчика я полностью устраивал как специалист, да и проект интересный для портфолио. Когда стали обсуждать график работы, оказалось, что быть на связи нужно будет с 18:00. В требованиях к позиции это, увы, изначально не было прописано. Заказчику пришлось проводить интервью с другими ребятами, которым такой график не был проблемой.
Совет: уточняйте, в каком часовом поясе работает команда проекта. Хотите, чтобы разработчик был онлайн с 21:00 до 06:00 по МСК? Пропишите, это важно для обеих сторон.
4. Открытые вопросы, закрытые ответы
Некоторые компании задают открытые вопросы, заведомо ожидая на них определенный ответ. Например, на вопрос «с какой самой большой проблемой вы сталкивались на работе?» ждут ответ в стиле «у меня не было серьезных проблем», а не рассуждения соискателя. Если оценивать уровень пригодности только по таким вопросам, можно упустить хорошего специалиста.
Я прошел технический собес, но завалился на интервью с менеджером. А все потому, что, кажется, неправильно ответил на вопрос «Почему вы хотите именно в нашу команду?».
Менеджер проводил собеседование в привычном ему стиле (как при обычном найме в инхаус-команду) и ждал ответ в стиле «потому что вы классные», а получил другой.
Совет: открытые вопросы требуют размышлений и обязывают соискателя раскрыть свое отношение или мнение. С помощью них вы можете посмотреть, как реагирует соискатель, как рассуждает и строит логические цепочки. Правильных ответов на них не существует, если это не прописная истина. Хард скиллы играют для вас решающее значение? Смело сокращайте количество таких вопросов либо полностью убирайте их.
5. Интервьюер не знает, кто ему нужен
Иногда компании указывают в требованиях к вакансии одно, а хотят получить другое. К примеру, ищут еще одного разработчика, а команде для роста производительности больше поможет проджект. В итоге на проект попадает совершенно не тот, кто нужен, дедлайны срываются, тратятся лишние деньги и человекочасы.
В одно из направлений банка требовался DevOps-инженер. Но в ходе собеседования выяснилось, что знания DevOps-практики соискателю не нужны. Искали сотрудника на вторую линию поддержки. А DevOps в вакансию добавили для пущей важности. Самое забавное, что наш специалист не получил должность из-за нехватки квалификации, как прокомментировали заказчики.
Совет: четко продумайте реальную потребность производства, а только потом прописывайте роль того, кто вам нужен и с какими технологиями предстоит работать.
6. Нам нужен только идеальный кандидат
Некоторые компании не готовы рассматривать кандидата при малейшем отклонении от списка скиллов и технического стэка. Это может надолго затянуть поиск кандидата.
На одном из собеседований меня завернули за то, что не работал с Axios — мелкой библиотекой для упрощения отправки запросов. Хотя сказал, что успешно работал с самописной альтернативой. Заказчики оценили джуном, раз с Axios не сталкивался никогда.
Совет: приоритезируйте требования, распределите, что будет главным при оценке кандидата, а что можно проигнорировать. Здесь хорошо работает армейский принцип «не знаешь — научим»... Не путайте с «не хочешь — заставим», он не работает...
Найти сразу идеальное совпадение — большая удача, обычно нужно погружение в проект, а на полное включение могут уйти недели. За это время можно научить основам любой используемой технологии. Идеально может подходить только сеньор с вашего же проекта. Остальных так или иначе учить, смиритесь с этим.
7. Одинаковый список вопросов для всех специалистов... в Google Forms
Для новой позиции создается гугл-форма с вопросами, которые не подлежат редактуре. И все проходящие специалисты оцениваются строго по ней. Иногда доходит до смешного: форма без всякого внешнего контроля и ограничения по времени, так ещё и с вариантами ответов. Как ЕГЭ проходить :)
Несколько специалистов проходили первичный отбор. Нужно было заполнить блиц-опрос, по результатам которого будет выбран человек для интервью. Тестирование проходило в разные дни. Что мешало запомнить вопросы и передать следующему? Правильно, ничего)
Совет: подходить к каждому собеседованию в индивидуальном порядке. Не хотите придумывать для каждого новый список вопросов, хотя бы частично меняйте их, перемежая кейсами и практическими заданиями.
Вместо вывода
Не стремитесь сделать собеседование подобием игрового уровня битвы с боссом. Это не экзамен, а способ убедиться, что пришел специалист нужного уровня. И проверить, насколько сотрудник подойдет команде.
Если собеседование в разы сложнее реальной работы, ожидания соискателя могут не оправдаться, и вы получите демотивированного сотрудника. А чем ближе тестовые задания будут приближены к реальным задачам, тем выше шанс получить подходящего вам разраба.
Все совпадения не случайны, а истории не вымышлены.
Ммм… не. Программист ждёт адекватную зарплату и не менее адекватный коллектив. Работа интересной бывает крайне редко, с этим все уже смирились. Для интересов есть pet проекты, stackoverflow и т.д.
Ну, видимо, Вам просто не везло...
Да большинству не везёт. На собесах чего только не спрашивают, а по итогу обычно сидишь json'ы собираешь )
Не поверите, но случаи когда вообще приходилось с ними работать можно по пальцам пересчитать.
А вот разрабатывать распределенную гетерогенную систему обработки информации с нуля (т.е. сначала архитектура и классификации, потом разработка протоколов и БД, а потом реализация всего этого в коде) - приходилось.
Или заниматься тонкой оптимизацией высоконагруженных модулей, заниматься задачами обработки больших объемов данных с распараллеливанием процесса.
Низкоуровневые сервисы, когда приходится вникать в тонкости системных API конкретной платформы и делать интегрированные решения для их удобного использования на верхнем уровне.
Да, иногда попадаются рутинные задачки, но в целом это какие-то разовые вещи, которые надо сделать быстро (или которые идет как сопровождение к основной задаче) и прям сейчас больше некому.
Но вообще типовая рутина - это удел джунов на начальном этапе. Если джун растет в мидла, ему начинают давать что-то более сложное и интересное.
Скорее всего вы в какие-то небольшие коллективы попадали. Мне то, на самом деле, повезло в большой компании попасть на необычный проект и поднимать всё с нуля. Сейчас в статусе самозанятого интересными задачами занимаюсь. Но большинство знакомых, как-то из рутины не вылезают будучи middle / senior.
Ага. Особенно сейчас. Очень небольшой коллектив. Управление разработки центральных банковских систем Альфа-Банка (это там, где разрабатывается то, что непосредственно на серверах крутится).
Просто я всегда избегал мест, где сеньоров считают возможным грузить рутиной, а не давать им реально сложные задачи (возможно потому, что там просто не таких задач).
Ну нет, совсем не обязательно
Да, извиняюсь, забыл, что есть поколение миллениалов, которых можно завлечь красивым офисом и смузи.
Ну это работает первые 2-3 года, потом люди умнеют и начинают лезть на стенку от скуки
О чём и речь.
Вот на это вообще по барабану.
Если Вашей фантазии хватает только на такие ассоциации - то не стоит проецировать эти мысли на всех.
Ребзя, а в чем подводные камни аутстафа для спеца?
Зачем условному мне идти в компанию через аутстаф, а не напрямую к ним инхаус?
Тут будет уместна аналогия с женой (инхаус), любовницей (аутсорс) и домработницей (аутстафф).
Конечным работодателям, потребителям услуг аутстаффинга/аутсорсинга, часто не нужен человек в штат на постоянку (жена). Нужен на несколько месяцев разработчик, чтобы потестировать гипотезы, отрефакторить технический долг, подменить инхаус-разработчика на длительном больничном и т.д.
Из плюсов для спеца - более экстенсивное развитие. Через пару лет у вас будет резюме из крупных проектов, типа Сбера, Яндекса, ВТБ и т.д. Если идти этот путь самостоятельно, первые пару лет в резюме будет ИП Пупкин и ООО Вектор)
Не будет у Вас крупных проектов в крупных компаниях. Крупный проект - это и длительное время и потом поддержка и сопровождение. На такие берут инхаус. А аутстафф - это быстро заткнуть дыру "подай-принеси", разгрузить своих разработчиков от рутинной мелочевки и т.п.
И ещё дешёвой мелочевкоф
Лучшей аналогии и быть не может
Проще сменить проект если текущий не нравится или перестал нравится, больше упора на теоретические знания, т.к. нужно готовиться к собесам. Больше вариантов попасть в свежий проект а не работать с легаси. Но это в идеальном варианте. Такое можно получить и в продуктовой компании. И в аустафе можно наткнуться на лютое легаси и закидывание в хреновые проекты без возможности смены. Вообще не плохо разбирается тут - https://www.youtube.com/watch?v=NJQe6bWQa6o
Иногда не хочется напрямую
Я вижу главную проблему в том что клиент не всегда понимает что собеседование в штат и на аутстафф это немного разные вещи. В штат нужно искать спецов которые будут подходить вашей команде в долгосрочной перспективе. На аутстафф можно смелее экспериментировать и легче расставаться с людьми.
Ага. Одни долбоёбы ищут по объявлению других долбоёбов. И потом недоумевают увидев друг друга: "это что за долбоёбы?".
Ребята, ни в одной стране мира ни по одной серьезной специальности по объявлению не набирают и не идут работать. Те объявления каких-то уважаемых в своих сферах компаний, что вы, возможно, где-то видели - это не более, чем сбор статистики для поддержания некоторого "контрольного уровня" долбоебизма и анализа ситуации в целом на рынке труда. НИКОГО по этим объявлениям они не возьмут круче уборщицы. Все остальные объявления это 100% "долбоёбы ищут долбоёбов".
Трудоустройство происходит ИСКЛЮЧИТЕЛЬНО через профессиональные связи и знакомства. И именно на "обрастании" такими связями и необходимо сосредоточится. А не вот это всё..
Ещё через кумовство, да?
И постель
Нет. В международных компаниях прекрасно набирают по объявлениям, особенно, через LinkedIn. И менеджмент тоже.
LinkedIn - это не доска объявлений "ищу работу/работника". Там очень много профессиональных сообществ (где обсуждаются профессиональные темы) и поиск сотрудника там это ближе как раз к "по профессиональным связям и знакомствам".
Жизненно, подтверждаю
Спасибо за статью. Я думаю, что описанные модели приема на работу характерны не только для аутстаффа. Некоторые конторы прям зациклены на своих требованиях к сотруднику, складывается впечатление,что поиск ради поиска
Херовые у вас советы.
Если я как заказчик ищу человека перекрашивать кнопочки - почему я должен искать именно тупого сотрудника с узким кругозором?
Я хочу сотрудника с логикой, бекграундом и мозгами даже кнопочки перекрашивать.
И вопрос "что такое метод пузырька" вполне себе норм (подразумевающий ответ "дремучий метод сортировки, хоть и простой в реализации")
И кейсы какие-то скучные, собесы бывали и повеселее. Например:
-Ты же понимаешь, что ты шеришь экран, как ты гуглишь ответ на вопрос?
-Да, конечно (сворачивая при этом экран и показывая телегу, где телочка присылала нюдесы)
Орнул с примера
Вопрос скорее риторический: а какой в этом случае будет интерес к подобным задачам у человека?)
Если кто-то долгое время сможет заставлять мидла перекрашивать кнопочки, то с радостью заплюсуем статью про борьбу с выгоранием от него 😉
Хорошая статья
Есть правда места с немного токсичными формулировками. Думаю, лучше смягчать тон и в целом быть более вежливыми с читателями, которые (весьма вероятно) могут оказаться бывшими, настоящими или будущими партнерами.
Спасибо за коммент! Старались делать без купюр, чтобы сохранить эмоции парней от некоторых интервью и вызвать резонанс в головах читателей)
На самом деле это все скорее исключения из правил, но лучше подсветить их и уберечь коллег от хождения по чужим граблям...
Комментарий недоступен
Есть часто обратная проблема, когда вы искали с аустаффа 2 разрабов с ценником выше среднего по рынку : 1 senior backend engineer и 1 middle frontend.
В итоге вам дали 1 senior backend, который все быстро и качественно запилил и 1 Junior frontend (за которого ручался менеджер), который нифига не понимал и затянул сроки сдачи проекта в 2 раза.
SOLID это же мгновенный выигрыш в буллшит бинго за один ход, потому что он заполняет сразу одну строку в поле пять на пять клеток.
Посмотрел кейсы на вашем сайте.
Цитата: Backend-код legacy-системы был написан на языке программирования PHP. Для нового кода использовали Java — гораздо более безопасное решение с повышенной защитой от ошибок, уязвимостей и атак
Это, простите, как? Чем Java безопасней?
В 99% случаях ни в чём он не хочет удостовериваться, он хочет, чтобы его фича была быстро сделана в срок, и нормально работала. Как - уже другой разговор
Совет: подробно рассказывайте о проекте, освещайте проблемы, чтобы специалист мог уже на собеседовании понять, с чем ему придется работать. Распишите должностные обязанности. Расскажите, чем предстоит пользоваться в работе.Это если компания нормальная. Как раз таки подобная практика и используется с целью нанять себе дурачка, который по джуновской цене будет деплоить, тестить, разрабатывать, дизайнить и т.д.
Я бы сказал, что если этот компонент отсутствует, надо сразу искать себе какое-нибудь другое место.
2. Сдаем экзаменСоветы очень противоречивые. Можно согласиться с тем, что нужно спрашивать только конкретику и только то, чем предстоит реально заниматься. Но разработка - она на то и разработка, что неизвестно, что предстоит делать завтра. Тем более во всяких аутсорсах. Неоднократно был опыт собеседования на senior разработчика и тимлида, и в следующие пары месяцев приходилось верстать формочки, потому что один заболел, второй в отпуске, у третьего ещё что-то, а задачи делать надо.
Я бы сформулировал совет так - нет смысла спрашивать выше той сложности, какая потенциально может быть, как нет смысла у высококвалифицированного специалиста спрашивать, знает ли он flex-box. Если приходишь верстать формы - нет смысла спрашивать про паттерны. Но если ты условный скилловый middle/senior в нормальный проект, будь добр, рассказывай про SOLID. При любом отклонении возникает вопрос - а зачем? И этот вопрос стоит задавать интервьюеру.
4. Открытые вопросы, закрытые ответыТут люто плюсую, и в принципе, изначально со стороны интервьера хорошо задавать рамки - тут да/нет, а вот тут развёрнуто. Считаю это правилом хорошего тона. Особенно раздражает отдельный вид чертей, когда в практических заданиях они ожидают какое-то конкретное решение, а на все остальные безосновательно ругаются. Даже когда ты им проговариваешь полностью алгоритм, просят, чтобы ты его написал, потом докапываются до каких-то мелочей. Вот такое - сразу в самое далёкое путешествие.
А так, статья хорошая, но считаю, что темы раскрыты недостаточно хорошо. Большинство описанных проблем - уровня стартапов, в больших компаниях их, как правило, нет.
Комментарий недоступен
Я бы не был так категоричен)
Для людей, которые уже что-то умеют, но ещё ничего не знают, работать в таких конторах - самое то. Много разнообразных задач, куча проектов на любой вкус, это очень полезный опыт
Но потом, конечно же, устаёшь от этого и хочется спокойно, долго и уверенно работать над продуктом
разве что опыт, в остальном не очень удобно
Комментарий недоступен
Прям плохой совет. В компанию берут просто с минимальным уровнем, что бы джун не кивал головой на митинге - де все ясно, а на деле три дня судорожно гуглит. Зачем жечь время МП/лида для слежения за джуном, если можно нанять чуть дороже, но с хорошим бэкграундом ? И про "мелкие баги" с кнопочками, особенно в реакте ну такое, без знания паттернов/SOLID можно неплохо там испоганить производительность.
Всеобщее помешательство на SOLID тоже иногда поганит производительность.
До боли знакомый шрифт на обложке :) одно время использовал его у себя на сайте
А сколько времени ваш специалист вникает в документацию проекта?
" Заказчики оценили джуном, раз с Axios не сталкивался никогда"
Просто интересно, а а кого претендовали?
Блин, но не сталкиваться с axios и идти на сеньёра....