Собеседования без кода: почему это сработает?
Всем привет! Меня зовут Меньшиков Илья, я тимлид в Бизнес-юните классифайдов в VK.
Вместе с командой мы работали над сервисом быстрого поиска вакансий и сотрудников на основе геолокации — VK Работа. Рост продукта сопровождался ростом команды, поэтому мне довелось провести достаточно много собеседований на позиции разработчиков и накопить немалый опыт. Несколько раз мы перестраивали процесс найма в команду, убирая излишние шаги. В этой статье я хочу поделиться тем, как мы в итоге выстроили процесс собеседований: что меняли, от чего отказывались и что получилось в итоге.
Важное замечание
Этот текст я хотел написать давно, но всё не доходили руки. Сейчас VK пересматривает приоритеты и сосредотачивает усилия на главных для пользователей сервисах и продуктах. Пришлось закрыть некоторые проекты. Одним из таких продуктов стала VK Работа. Несмотря на это, наш подход к собеседованиям я буду внедрять дальше — в работе в других направлениях. В итоге решил, что не стоит убирать готовую статью в стол и захотел поделиться ей с вами.
Нарушаем общепринятые правила IT-собеседований
Собеседования в нашу команду разработки достаточно сильно отличаются от тех, которые я видел лично или о которых знаю из своего окружения и коммьюнити. Более того, мы даже нарушали некоторые «общепринятые правила» IT-собеседований.
Три отличительные особенности наших собеседований:
Количество людей на собеседовании. На одной встрече с кандидатом присутствуют сразу 4–5 участников команды.
Нет кода на собеседовании. Мы не используем лайфкодинг, не даем алгоритмических задач прямо на встрече — то, что вы могли встречать почти на каждом инженерном собесе в другие компании.
Нет стандартного список вопросов. У нас нет списка вопросов с заранее известными правильными ответами, по которым мы собеседуем каждого кандидата.
Чтобы объяснить, почему наши собеседования построены так, я сделаю отступление и предлагаю для начала разобраться: А какая вообще цель собеседования?
Зачем вообще нужны люди в продукте?
Представим, что есть у нас вакансия «Разработчик Java». Мы хотим найти человека. Зачем нам нужно собеседование? Казалось бы, ответ на этот вопрос очевиден: собеседование нужно, чтобы найти java-разработчика.
Однако, джависта можно найти и без собеседования:
открываем работный сайт;
фильтруем резюме по критериям — необходимому опыту, ключевым словам;
находим нужные CV и контакты, а затем просто рассылаем офферы.
Звучит абсурдно, не так ли? Можно сказать, что цель собеседования — выбрать людей из потока кандидатов. Для этого, в общем-то, тоже есть и другие способы, кроме собеседования: от создания алгоритма скоринга резюме до боя подушками и взятия на работу победителя.
Получается, что цель собеседования — найти нового члена команды, а не просто человека, соответствующего формальным критериям.
Важно помнить, что мы ищем не функцию, мы ищем человека. Почему? Я рассуждаю так: можно набрать много людей, которые «работают работу», поставить над ними погонщика с кнутом, раздающего задания и контролировать их выполнение.
Однако это не эффективно — об этом уже написано немало книг и проведено немало исследований. Со мной согласны и Daniel Graziotin, который провёл много исследований продуктивности разработчиков, и Daniel Pink со своим бестселлером про мотивацию, да и эмпирический опыт подтверждает эту мысль. Кроме того, жёсткая, контролирующая обстановка гасит творческое мышление, как демонстрирует нам Sam Glucksberg в своих экспериментах. При этом работа в IT всё-таки творческая.
Вторая проблема — подобный подход к работе провоцирует «опухоли команд» — они появляются, когда резко начинают набирать сотни разработчиков, которые тратят своё время в основном на решение проблем этого гигантизма. Об этом уже вышло немало статей из серии «Как вырасти в три раза за квартал и перестроить процессы под этот рост», без объяснения –, а нафига такой рост вообще был нужен?.
Я сторонник идеи, что если каждый новый сотрудник — это мотивированный, хорошо работающий профессионал, то вам не надо набирать кучу людей, чтобы достичь тех же результатов, которые показывают большие команды. Вы постепенно набираете новых сотрудников, влияние каждого из которых значимо, а эффективность работы выше.
Скиллы, которые мы проверяем на собеседовании
«То, что надо! Отправляем ей или ему оффер!» — в чем нужно убедиться на собеседовании, чтобы тимлид написал эту фразу рекрутеру? Разумеется ответ зависит от компании и конкретной команды, но лично я выделяю для себя несколько основных моментов:
1. Умение думать.
Как ни странно, по этому скиллу срезается довольно много людей. Они способны выучить названия функций, способны заучить паттерны, способны перекладывать json из одного места в другое одинаковым способом. А вот рассуждать, думать, строить гипотезы, осмыслять то, что они делают — не всегда. Если взять такого человека в команду, вероятно он сможет успешно выполнять однотипные задания, которые ему показали как делать. А что-то за их пределами — как показывает мой опыт — вряд ли. Даже кажущаяся на поверхности типичной задача зачастую таит в себе подводные камни.
Как мы проверяем этот навык? Задаем вопросы «на подумать», дискутируем с кандидатом во время интервью на разные темы, слушаем, как он строит аргументацию. Вместо вопросов «Как?» чаще спрашиваем «Почему?» и «Зачем?». Например, на некоторых собесах я слышал, как просят расшифровать акроним SOLID, но мало кто спрашивал «А как ты думаешь, зачем оно вообще? Всем ли это нужно? Согласен ли ты с этими принципами, или может ты мог бы сформулировать свои?».
2. Любознательность и насмотренность. В идеале, чтобы человек укрепил и усилил вашу команду, ему должно быть искренне интересно то, чем он занимается. Как это проявляется? Увлеченные люди читают статьи, интересуются происходящем в мире технологий, пробуют применять эти знания. Человек, который не развивается за пределами вашей компании, вряд ли будет развиваться и у вас. Кстати, вопрос нацеленности на рост освещен в книге про Growth mindset — Mindset by Carol S. Dweck.
Чтобы проверить этот навык мы обсуждаем с кандидатом его взгляд на развитие технологий, говорим о новых трендах, интересуемся, что интересного он читал за последнее время.
3. Продуктовое мышление. Мы не нанимаем людей писать «абстрактный код в вакууме», мы берем людей, которые будут развивать наш продукт своей работой. Безусловно, чтобы влиять на продукт и определять путь его развития, есть продакт и продуктовые аналитики, но каждый разработчик также планирует и выполняет свою работу в соответствии с целями продукта. Люди, не погруженные в продукт, не могут дать конкретную и полезную обратную связь по фичам, предложить альтернативные решения тех же задач. Для разработчика важно понимать, как новая фича может повлиять на какие-то другие части продукта, замечать узкие места в своих решениях, не останавливаться на посредственных результатах.
Его наличие становится понятно исходя из того, как кандидат рассказывает о своём прошлом опыте — говорит ли он только о технологиях или нет? Понимает ли, «о чём» был его прошлый продукт, кто были его пользователи, какие проблемы он решал?
4. Адекватность.
Тут просто: базовая адекватность — это способность работать в команде. Я сразу откажу, если человек хамит, считает, что «всю проприетарщину надо срочно сжечь», или раздаёт оценки в стиле «продакты и продажники — тупые люди, которые только и ждут излияния мудрости от разработчика». Если у вас в компании есть место, куда можно посадить очень умного, скилового социопата, так чтобы он работал, но не пересекался с другими людьми — смело берите его на работу. В противном случае — один такой человек может стоить вам целой команды.
Пункт со звездочкой.
Для сеньоров есть ещё один важный критерий, который я называю «повидал дерьма» :) Человек, который поработал в разных продуктах, решал разные проблемы, сталкивался с разными сложностями. Одним словом, человек, который получил и структурировал у себя в голове разносторонний опыт, принесёт гораздо больше пользы, чем человек, всю карьеру делавший примерно одно и то же.
Как можно заметить, базовый фильтр в найме — что-то из серии core-skills или даже черт характера. Среди критериев отбора кандидатов нет пунктов «знание последних фич фреймворка», «умение вращать деревья» или ещё чего-то подобного.
Гипотеза в том, что если человек соответствует критериям из списка выше, то он будет способен разобраться в технических вопросах и использовать знания на практике, если это будет полезно для продукта.
Мой опыт показал, что лучше взять обучаемого человека и обучить, чем взять необучаемого, который знает то, что вы используете сегодня, а завтра не сможет освоить новые вещи и начнет сопротивляться изменениям.
Как раз о практике собеседований в нашу команду разработки, я расскажу дальше.
Готовим собеседование в команду разработки
Собеседование у нас — это встреча, которую можно условно поделить на несколько частей.
Сначала — знакомство. Мы знакомим кандидата в команду с продуктом и компанией, кандидат нас — с собой, рассказывая о своем опыте. Пока ничего необычного? Есть нюанс: на собеседование с кандидатом приходит обычно сразу четыре-пять человек, представителей разных команд. Один из них будет вести встречу. В начале он рассказывает немного о компании, после чего просит кандидата рассказать о себе. Из рассказа об опыте кандидата чаще всего можно получить стартовые темы для обсуждения: что и как делал наш собеседник на прошлом месте, почему он делал что-то именно так, как работал продукт и т.д. Часто уже на этом этапе получается поговорить на важные темы и получить оценку по критериям выше.
Если за время обсуждения опыта кандидата не удалось составить представление о нём, то мы обычно переходим к стандартным областям: говорим немного про язык, про архитектуру кода и приложения, про базы данных, тестирование.
В каждой теме есть пара стартовых «заходов», от них можно отталкиваться и развивать разговор. Но зачастую этого не приходиться делать. Вопросы задаём не наперебой, по какой-то теме больше говорит один из нас, остальные задают уточняющие вопросы или вносят полезные комментарии. Мы стараемся придерживаться непринужденной обстановки на встрече, чтобы кандидату было комфортно и спокойно.
Формат собеседования — не «вопрос-ответ», а беседа, в которой мы говорим и узнаём мнение и слушаем рассуждения кандидата, дискутируем с ним. Что важно: мнение кандидата не обязано совпадать с мнением собеседующего. Мы принимали решение пригласить в нашу команду и людей, у которых абсолютно другие взгляды на предметную область. Главное, чтобы у кандидата были мысли и понимание, аргументированная точка зрения. За время этого разговора мы получаем возможность оценить кандидата на соответствие вышеперечисленным критериям, а также понять — может ли он подойти в одну из наших команд.
В конце собеседования обязательно оставляем достаточно времени для ответа на вопросы кандидата, если они у него появились. Вопросы — это интерес к продукту и к нам, а значит их наличие — это хороший знак. Да и просто это уважительно по отношению к кандидату, ведь он тоже выбирает себе команду.
А как же код, спросите вы?
Он отсуствует во время собеседования. Да, мы можем попросить показать пример кода после. Но такое случается редко, в основном если рассматриваем кандидатов на миддл или джуниор грейд, и только если после интервью остались какие-то сомнения. Это может быть open source или pet, который человек делал, что-то из рабочего проекта, откуда можно легко вычистить всё важное — без нарушения NDA. Если у кандидата ну совсем ничего нет, можем предложить ему сделать супер мелкое тестовое, на час-два работы. Код в процессе собеседования, на мой взгляд, показывает не очень много, но кое-что показывает: например, как человек проектирует интерфейсы, как тестирует, как оформляет код. И все же от практики тестовых заданий или проверки кода мы стараемся уйти. Я расцениваю это так: если нам потребовалось просить кандидата сделать тестовое, то это наша недоработка на встрече, а не какие-то проблемы в кандидате.
Почему на собеседовании с нашей стороны сразу так много людей?
Во-первых, это возможность посмотреть кандидата сразу в несколько команд. Как уже пояснял, мы нацелены получить не человека-функцию, а человека-члена-команды. Поэтому наш кандидат может вполне подходить в одну команду, и не так хорошо — в другую.
Во-вторых, кандидат может посмотреть на всех нас, и понять, к кому в команду он готов, а к кому не готов идти, чьи взгляды, манера общения или что-то ещё — ближе.
Ну и в третьих, у нас внутри тоже нет единого мнения по всем вопросам. Кандидат может получить более разностороннюю картину того, как обстоят дела у нас.
Каждый новый рекрутер приходя к нам ужасается количеству людей на собеседовании. Но потом, послушав отзывы кандидатов, меняет свое мнение о командном интервью. Мы стараемся создать атмосферу непринужденной беседы, и почти всегда это получается.
Как нам удаётся достигать этой ламповой атмосферы? Я выделил несколько факторов:
1) Культура ценности сотрудника. Мы создали эту культуру еще на первых этапах создания продукта и смогли пронести её сквозь года. Мы прожили активную фазу роста, но атмосфера в команде осталась неизменной. Мы нанимали людей, руководствуясь принципом culture match, многие приходили в команду именно из-за культуры. Так мы прожили расширение, не утратив наш культурный код.
2) Внимание тимлидов. Все наши лиды понимают, что их результат — это результат работы их команд. Как бы они не были перегружены, все согласны, что на собеседования нужно выделять время и силы, поскольку это важнейшая часть работы лида. Наберёшь не тех людей или отпугнёшь кандидата на собеседовании своей раздражительностью — твой «корабль» никуда дальше не поплывёт.
Конклюжн
Что нам даёт такой подход к собеседованиям?
Во-первых, мы получаем классный матч.
За последние 3 года у нас было 0 людей, не прошедших испытательный срок, и всего один человек, который решил во время первых 3 месяцев перейти в другую компанию. Те, кто приходил, оставались с нами надолго — за эти же три года команду продукта VK Работа покинуло меньше 10 человек, а мы наняли плюс 25 разработчиков в проект.
Во-вторых, кандидатам нравятся наши собесы.
Даже если мы друг другу не подошли: и наша команда, и кандидаты уходят с интервью с новыми мыслями и идеями. Не бывает бесполезных собеседований: мы узнаем, как иначе можно смотреть на вопросы, на которые мы уже по-своему ответили, налаживаем полезные связи с ИТ-комьюнити, поддерживаем общение. Здорово, что и кандидаты рассказывают своим знакомым, что у нас интересно, рекомендуют попробовать пойти к нам.
Если мне удалось показать вам плюсы нашего подхода, и вы задумались о внедрении похожих принципов у вас, возможно прямо сейчас вы задаете себе вопрос:
А как сделать так, чтобы собеседования в нашу команду были такими? Для этого прежде всего нужно вложить силы в развитие командной культуры. Первая и главная часть такой культуры — утверждение «Люди важны». Если вы уже живете так, то осмелюсь предположить, что вам давно не нужны две стадии алгоритмических сессий, лайвкод и озвучивание вопросов из «списка вопросов для собеседования language name».
Ну и последнее. Я люблю и горжусь своей командой. Возможно, это именно тот ингредиент, которого не хватает многим компаниям. Добавьте себе в культуру любви, и вы сможете построить именно ту команду, которую хотите.
