Возможно, вы знаете про Vivid, где-то слышали или же видите впервые. Мы делаем один из самых быстрорастущих и многообещающих финансовых сервисов в Европе. Чтобы не быть голословным, вот некоторые из наших показателей:
Одной из причин достижения таких результатов является наша команда. В этой статье я расскажу, по каким принципам мы формировали команду, как менялось наше техническое интервью и что для нас самое важное в кандидате.
Дисклеймер
Я ни в коем случае не хочу осудить или дискредитировать процессы собеседований в других компаниях. Все, что вы сочтете таковым, лишь наш взгляд и не более того.
Немного вводных
На старте нас было 2 человека. Нам предстояла сложная задача – найти ведущих разработчиков на каждый из продуктов, входящих в состав нашего приложения. Искать сеньоров и так нелегкая миссия, а когда ты их ищешь в компанию без названия и без возможности рассказать про продукт хоть что-то из-за строгого NDA, миссия становится невыполнимой. Но, как мы знаем, дорогу осилит идущий, поэтому надо было набраться терпения и делать все возможное, чтобы кандидат выбрал именно нас.
Что зависит от интервьюеров? – они же просто задают вопросы. На самом деле – почти все, так как хорошие специалисты серьезнее относятся к техническому интервью и обращают внимание на разные мелочи. Вряд ли сеньор будет в восторге от интервьюеров, которые не разбираются в темах, ведут себя неуверенно или задают странные вопросы. Кроме того, чтобы банально не иметь таких явных недостатков, нужно чтобы были какие-то достоинства.
Наши особенности
Кроме основных обязанностей интервьюеров мы старались делать следующее:
Располагать к себе кандидата и создавать friendly атмосферу
Задавать вопросы по ситуации, а не по заготовленному сценарию
Для первого пункта мы использовали смолтолки перед собеседованием (это не вопросы про опыт или резюме, а то, что помогает лучше узнать кандидата), иногда шутили для разрядки, подстраивались под особенности кандидата.
Случай на собеседовании
Однажды нам не хватило времени на собеседование, время в переговорке закончилось, а свободных не было. Пришлось заканчивать собеседование в кафе. Кажется, кандидату это понравилось – теперь он работает с нами.
Для собеседования мы не готовили список вопросов – мы готовили темы на которые хотим поговорить. Такими темами были: Swift (куда же без знания языка), UI (так как у нас его очень много, он на 95% кастомный и иногда нетривиальный) и архитектура (для ведущего разработчика это очень важно). По каждой теме мы старались спрашивать только то, что в основном используется в повседневной разработке и то, что связано с нашим приложением. Конечно, иногда мы углублялись в какой-то вопрос, чтобы понять насколько хорошо кандидат знает тему, но тут есть тонкость – если вдруг человек не отвечает или отвечает неправильно, мы не делаем на этом сильный акцент, так как это опциональные вопросы и ответы на них не обязан знать каждый.
Также для нас была очень важна практика, так как это то, что раскрывает способности разработчика лучше всяких вопросов. У нас были заготовлены различные задачи, которые мы выбирали в зависимости от ситуации. Среди них не было вопросов по алгоритмам, потому что мы не считаем их показательными – они показывают умение находить решения (или вспоминать их), а не умение писать код. Наши задачи показывали то, как кандидат обычно пишет свой код, какие конструкции использует, насколько оптимальны его решения и как он размышляет.
Самая сложная задача
Однажды задача родилась прямо на собеседовании. Пока я общался по своей теме, мой коллега набросал код и требования. Кому интересно, переходите по ссылке. Скажу сразу, мы немного переборщили со сложностью, но кандидат настолько хотел решить задачу, что взял ее "на дом" и прислал решение на следующий день.
Формат собеседования
Экспериментировать и меняться – это то, что свойственно нашей компании. Собеседования не исключение. Мы попробовали разные форматы: одно собеседование на 1.5 часа с вопросами "по ситуации", теоретическое собеседование на 1 час и практическое на 1.5 часа, теоретическое собеседование на 1 час и тестовое задание. В конце-концов мы пришли к следующему:
Скрининг перед собеседованием из 6 вопросов.
Одно собеседование на 1.5-2 часа. Из них 10-20 минут на общение с кандидатом не на технические темы, 30-40 минут на кодинг и остальное время на теорию.
Интервью всегда проводят 2 человека – это дает более объективную оценку кандидата после собеседования.
Каждый интервьюер ведет свою тему. Это позволяет более логично выстроить общение, так как другой собеседующий не будет задавать свои вопросы, уводя беседу в другую сторону или прерывая текущую мысль.
Скрининг
Наш скрининг состоит из 3 простых вопросов и 3 средней сложности. На каждый вопрос есть варианты ответа, но не для каждого вопроса они озвучиваются. HR-у леко проводить такой скрининг, так как он практически не требует специальных знаний и подготовки.
В скрининге содержатся такие вопросы, ответ на которые не приходится искать долго. В то же время это не избитые вопросы, что нравится кандидатам (судя по опросам).
Циферки:
Средняя длительность скрининга – 4 минуты
Процент кандидатов, прошедших скрининг – 75%
Техническая часть
Основной проблемой наших предыдущих собеседований было отсутствие четкого плана. Как я уже сказал, мы старались выбирать наиболее подходящий путь прямо во время собеседования. Иногда это приводило к тому, что в какой-то момент мы не знали что лучше спросить дальше и кандидат чувствовал некую неподготовленность с нашей стороны. К тому же такому способу ведения собеседования сложно научить новых интервьюеров.
Поняв наши проблемы, мы переработали техническую часть. Теперь у собеседования есть "сценарий", представляющий собой древовидную схему в Miro.
Общение по определенной теме мы начинаем с открытого вопроса, который предполагает обширный ответ. Далее, в зависимости от ответа, идут разветвления, затрагивающие различные области темы. Чем дальше мы продвигаемся по одной ветви, тем сложнее становятся вопросы.
Есть одна особенная ветка – Swift. Для движения по ней мы проводим лайвкодинг, в рамках которого кандидат решает поставленную задачу, у которой добавляются или меняются требования (прям как в реальной жизни). Задача затрагивает практически весь синтаксис языка при ее небольшом объеме. По ходу решения мы задаем вопросы. Например: "Почему использовал class, а не struct?", "Можно ли задачу решить по-другому?" и так далее.
Таким образом, мы получили "фреймворк" для собеседования. Он позволил нам:
быстро понимать во время собеседования что спрашивать
вести собеседование более структурировано
быстро обучать новых интервьюеров
Как оцениваем кандидатов
Нельзя не затронуть столь субъективную тему как оценка уровня кандидата. Мы разделяем уровни разработчика как и многие другие: Junior, Middle, Senior. К каждому уровню еще можем добавлять + или - чтобы оценка была немного более точной.
Для определения уровня используем следующие маркеры:
Предыдущий опыт. Чем больше в нем сложных и разнообразных задач, тем выше уровень.
Решение задачи. Чем быстрее и правильнее решена задача, чем чище код и чем лучше обоснованы решения, тем выше уровень.
Ответы на теоретические вопросы. Тут нам важно понять, подкреплено ли знание теории практикой. Если кандидат отвечает на вопрос – это хорошо, но если еще и приводит примеры из опыта или объясняет своими словами, то еще лучше. Короче говоря, для нас понимание важнее знания.
Умеренный перфекционизм. Это когда кандидат достаточно хорошо продумывает решение, но не тратит кучу времени на незначительные мелочи.
После выхода на работу
Каждый новый разработчик проходит онбординг, а также получает ментора. Менторство существует не только в нашей команде, но и по всему проекту. Это настроенный процесс в рамках которого ментор помогает быстро влиться в проект, познакомиться с коллегами, а также помогает решать задачи на первых порах.
Напоследок
Надеюсь, вам понравилась статья и вы нашли в ней что-то полезное. Будем рады ответить на комментарии – пишите, не стесняйтесь. Также вы можете почитать еще одну нашу статью про найм. Если же вам интересно пройти собеседование, следите за вакансиями здесь.
На этом все. Всем удачи на собеседованиях!
