Техническое собеседование инженеров мобильной разработки в RuStore
Привет Хабр, меня зовут Вячеслав Таранников, я старший Android-разработчик в команде монетизации RuStore, и сегодня хочу поделиться взглядом, из каких ингредиентов можно собрать полезное и эффективное техническое интервью.
Это первая статья, в которой я рассматриваю разные форматы технических собеседований и рассказываю, как (и почему!) мы меняли процесс собеседований в RuStore. В ней не будет большого количества технических деталей, и статья будет полезна как практикующим инженерам, которые уже собеседуют, так и людям, не участвующим в технических собеседованиях.
Часть 1: как мы выбрали формат собеседования
Проблема «правильных» этапов и форматов технического собеседования — вечный камень преткновения, о который спотыкаются все: и большие компании, и маленькие стартапы. Не существует универсальной «серебряной пули» в собеседованиях разработчиков. При создании своего процесса найма стоит не бездумно копировать другие компании или использовать привычные практики. Нужно думать, кто вам нужен, и строить процессы уже от своих потребностей. Вполне нормальная ситуация, что ваши запросы (а с ними и процесс собеседования) будут меняться вслед за изменениями в продукте и в команде.
Стартапер Петя
Есть стартапер Петя. Его инновационная идея приложения собрала раунд инвестиций, и он задумался о том, чтобы набрать команду разработчиков. Но как это сделать, Петя не знает, поэтому решил не изобретать велосипед, а позаимствовать подход у компании Google, которой всегда вдохновлялся.
Петя организовал интервью в пять этапов, и каждый проводил лично. К сожалению, за три месяца не нашли ни одного разработчика: часть кандидатов проваливалась на одном из этапов интервью, часть посреди процесса согласилась на оффер из другой компании, а единственный кандидат Настя, успешно прошедшая все этапы, озвучила такую минимальную зарплату, что Петя сначала решил, что это сумма за год.
Это первая ошибка Пети. Он не учёл состояние продукта и размер компании.
Петя обратился за помощью к Насте, которая согласилась помочь набрать команду в обмен на долю в проекте. Настя решила, что для запуска стартапа нужны люди, которые могут быстро писать относительно качественный код, поэтому её процесс собеседований состоял больше из проверки навыков кодинга и современных фреймворков: кандидат должен был написать простенький класс на пару функций для похода в сеть и кэширования результата в базу данных. С таким подходом Настя за неделю нашла двух толковых инженеров, которые принялись активно работать над запуском продукта.
По доброте душевной (и чтобы её больше не доставали просьбами), Настя даже написала документацию со своими советами, как проводить такое собеседование, на случай, если компании понадобится ещё один-два разработчика.
Шло время, продукт оказался успешным и популярным у пользователей, команда из двух разработчиков сначала выросла до пяти человек, а со временем — до пятнадцати. Но новые фичи занимали удивительно долго времени, а количество багов неотвратимо росло из спринта в спринт, и никто не мог понять, в чём причина.
Петя снова обратился к Насте, которая провела аудит, и была в шоке, увидев, что на проект такого размера людей всё ещё нанимают по той же методике, что и в самом начале — небольшим тестовым заданием. В коде творился бардак, который только усложнялся из-за того, что один участок кода одновременно могли изменять несколько человек, затягивая и без того не быстрый процесс код ревью. Вся команда состояла из людей, которые не понимали чистой архитектуры и не умели работать в команде такого размера.
Это была вторая ошибка Пети. Он не адаптировал процесс найма под размер команды и ближайшие планы продукта.
Давайте рассмотрим, из каких «кубиков» можно собрать техническое интервью, которое подойдет разным командам.
Основные факторы, которые стоит учесть при формировании процессов:
Текущий размер команды. Чем больше растёт ваша команда, тем больше должен быть упор на навыки командной работы у кандидата. Какую «рок-звезду» вы бы ни нашли, если кандидат не умеет работать в команде, а у вас 50 разработчиков на проекте, то пользы он не принесёт.
Состояние продукта. Нужно понимать, что вы хотите: максимально быстро запустить проект, проверить гипотезу и собрать первый раунд инвестиций, чтобы потом переписать нормально, или вы крупный энтерпрайз, который готов полгода разрабатывать продукт, но чтобы до пользователей дошла отполированная версия, которую можно будет легко масштабировать с предсказуемыми сроками. В зависимости от этого вы будете подбирать или людей с широкими знаниями в наиболее популярных областях, или искать узкопрофильных специалистов, которые закроют какую-то точечную потребность типа навигации или UI в приложении.
Специфика продукта. Если у вас уникальный продукт, требующий специфических знаний от разработчиков — например, работа с Bluetooth Low Energy, — то стоит выстраивать процесс вокруг этих знаний, а менее приоритетные навыки компенсировать силами команды.
Планы на будущее. Что будет с продуктом через пару лет? Какой вы видите команду? Не придётся ли ради этих изменений уволить половину инженеров, потому что они не смогут адаптироваться к таким изменениям?
К сожалению, даже при помощи такой «анкеты» не получится выделить какой-то идеально подходящий под ваш случай процесс. Но можно рассмотреть наиболее популярные форматы и оценить, какой из них вам подойдёт.
Виды технических собеседований
Алгоритмическое
Пример: грабитель планирует обчистить дома на улице. В каждом доме на этой улице спрятана определенная сумма денег. Также в соседних домах есть сигнализация, и она автоматически сработает, если в одну ночь взломают два соседним дома. Зная сумму денег в каждом доме, вам необходимо обчистить дома с максимальным уловом, при этом сигнализация не должна сработать. Входные данные: arr — массив положительных целых чисел, представляющих сумму денег в i-м доме.
Представляет из себя лайв решение какой-то сферической задачи в вакууме. Задачи и их сложность варьируются от компании к компании и от грейда, где-то достаточно знаний базовых структур данных, как связанный список, а где-то потребуются более сложные алгоритмы, теория графов и так далее. Задача из примера считается «средней».
Плюсы:
Сильный фильтр базовых знаний computer science. Кандидат с курсов «мидл разработчик за три месяца» не пройдёт.
Повышает вероятность того, что кандидат будет иметь представления об оптимизации кода.
Большая вариативность сложности, можно подобрать задачу почти на любой уровень, от студента-стажёра до сеньора.
Минусы:
Требует подготовки. Если кандидат не сталкивается с такими задачами в повседневной работе (как большинство мобильных разработчиков), то он не пройдёт такое интервью.
Подготовка очень затратна по времени и силам.
Большой фактор лотереи, примерно как с билетами на экзамене. Кандидату может попасться тема, в которой он хорошо разбирается, а может та, которую он давно не повторял.
Сама по себе секция не отображает реальные навыки кандидата, только знания в алго и структурах данных.
Требует долгой подготовки от интервьюера, так как часто задачи имеют несколько вариантов решения, и интервьюер должен знать все.
Итог:
Хороший вариант, если вы ищете специалиста со знаниями в оптимизации кода. Например, если у вас много тяжёлых вычислений на клиентских устройствах или вы целитесь в развивающиеся рынки, где важно бороться за каждый килобайт памяти.
Для оценки кандидата нужно комбинировать с другими типами интервью.
Если для выполнения своих рабочих задач кандидату не нужно детальное знание алгоритмов — не проводите этот этап. С огромной вероятностью вы получите false-negative результат и упустите действительно хорошего кандидата.
Опросник
Пример: «Расскажи, что ты знаешь про Garbage Collector в JVM»
Плюсы:
Тоже большая вариативность сложности. Можно начать с общего вопроса и проверить знания кандидата «вглубь».
Можно проверить знания по актуальному для вас стеку — позволит найти кандидата с минимальным временем адаптации.
Минусы:
Из-за ограничений по времени не получится копать вглубь по всем темам, надо выделять наиболее приоритетные для вашего проекта.
Проверяет теоретические знания с упором на конкретные технологии. Качество кода и софт скилы проверить не получится, а архитектура обычно затрагивается весьма поверхностно.
Итог:
Хороший вариант, когда вам нужен человек, который придёт на проект и сразу начнёт что-то перформить.
Можно использовать как отсевочное собеседование для грубой оценки уровня кандидата: если есть впечатление, что кандидат не справится с основным этапом, можно с ним попрощаться после этого этапа.
Лайв-кодинг
Написание кода вживую. Имеет много вариаций — от написания классов на листочке до «вот тебе участок кода, найди проблемы и исправь их». Но все задачи преследуют одну цель: посмотреть, как кандидат пишет код.
Плюсы:
Приближено к тому, чем кандидат будет заниматься большую часть времени
Проверяет, как хорошо кандидат знаком с особенностями языка
Минусы:
Довольно стрессовый вид интервью для кандидатов. Велика вероятность, что результат будет сильно отличаться от того, что получилось бы в спокойной рабочей обстановке.
Небольшая вариативность. Если кандидат застрял на каком-то участке кода, его будет тяжело направить.
Не получится проверить действительно крутых кандидатов — их реальные навыки написания кода видны в масштабе, который не уместить на интервью.
Итог:
Подходит для наймов джунов и ранних мидлов: можно посмотреть, какой примерно код будет писать кандидат.
Не требует от кандидата какой-то подготовки.
Системный дизайн
Секция целиком посвящена проектированию. Кандидату даются картинки юзерфлоу и очень абстрактная задача, например «спроектируй поиск в музыкальном приложении», а интервьюеры выступают в роли всех возможных коллег — от проджект менеджера до бэкэнд разработчиков и дата аналитиков. Кандидат должен собрать требования и нарисовать диаграмму классов решения.
Плюсы:
Позволяет довольно точно определить уровень навыков кандидата за счёт свободы в подходе к решению.
Максимально приближено к реальным рабочим условиям: кандидату не надо отдельно готовиться или что-то повторять. Просто демонстрация его повседневных навыков.
Попутно можно задавать смежные вопросы, привнося элемент «опросника».
Минусы:
Не подходит для джунов, у них ещё нет достаточного опыта в сборе требований и проектировании.
Каждая задача требует предварительной проработки интервьюером, чтобы он мог учесть неочевидные кейсы.
Показывает навыки кодинга лишь косвенно.
Формат непривычен для кандидатов в РФ.
Итог:
Хороший вариант для стабильных проектов, где у кандидата ожидается большая зона ответственности и возможность участвовать в принятии архитектурных решений.
Упор на масштабируемость и чистоту архитектуры, подойдёт для оценки старших грейдов (мид+ и выше).
Системный дизайн и системная аналитика
Может возникнуть вопрос:, а зачем инженеру в принципе уметь собирать требования, если у нас есть системные аналитики? Вроде бы идеальное разделение обязанностей: аналитик собирает и формулирует требования, разработчик просто пишет код по этим требованиям. Но тут есть важный фактор: разработчик обладает бОльшей компетенцией в своей платформе, и поэтому может улучшить качество требований, предложив более оптимальный вариант или указав на неучтенные эджкейсы. Наиболее популярные зоны сбора требований, в которых разработчик может участвовать, это:
Валидация требований: насколько корректно сформулированы требования и реализуемы ли они в разумные сроки.
Верификация: есть ли всё необходимое для разработки — дизайн, юзерфлоу, внешние библиотеки, граничные случаи.
Переговоры: возможно, реализация каких-то требований потребует непомерно много ресурсов относительно своей пользе или ожидаемые сроки задачи нереалистичны. В таком случае разработчик может предложить альтернативные варианты и в ходе переговоров прийти к решению, которое устраивает всех.
Сравнительная таблица видов интервью
Подходит для джунов | Подходит для сеньоров | Можно пройти без подготовки | Особенности | |
Алгоритмическое | Да | Да | Нет | Показывает навыки в оптимизации |
Опросник | Да | Да* | Да | Наиболее гибкий формат |
Лайв-кодинг | Да | Нет | Да | Подходит для джунов или ранних мидлов |
Системный дизайн | Нет | Да | Да** | Наиболее точно показывает повседневные рабочие навыки кандидата, включая софт-скилы |
*Если сделать упор на опыт кандидата, а не только на теорию
**Если заранее познакомить с форматом
Выбор нового формата собеседования в RuStore
Как собеседовали раньше
RuStore создавался в атмосфере стартапа силами чуть больше десятка инженеров, которые ранее уже работали вместе и успели выработать свою инженерную культуру. Основной целью был запуск продукта как можно раньше, соблюдая высокие стандарты качества разработки, поэтому в качестве собеседования выбрали опросник: он позволял проверить, знаком ли человек с используемыми технологиями, и получится ли быстро интегрировать его в процесс разработки, не выключая другого инженера из разработки на время онбординга.
Как мы поняли, что надо менять процесс собеседований
В начале 2023-го к работе над RuStore подключилась ещё одна команда из 13 человек, что увеличило количество инженеров мобильной разработки почти в 2 раза. Такой рост команды повлёк за собой изменения во многих процессах — от архитектуры проекта до code review, и собеседования не стали исключением. У команды появилось чуть больше времени на онбординг новичков, а фокус при поиске инженеров сместился со знания технологии на их архитектурные и софтовые навыки: знание каких-то фреймворков можно подтянуть на испытательном сроке, тогда как развитие архитектурных и софтовых навыков занимает гораздо больше времени.
Новые ожидания от собеседований
Начали с того, что попытались сформулировать ответ на вопрос »а что мы хотим от собеседований? ».
Кандидаты от мид+ и выше. Новый человек должен прийти и импактить в проект с достаточно высокой сложностью кода.
Знаком с актуальными практиками или показывает яркие маркеры обучаемости. Мы используем свежий стек технологий, если кандидат пишет код как в 2015-м — он просто не сможет импактить или (что хуже) занесёт плохие практики в проект.
Команда из 20+ мобильных разработчиков, что накладывает дополнительные требования по модуляризации кода и навыкам проектирования. Если человек привык писать монолиты с непредсказуемым API, то пользы от него будет не много.
Проект стабилен, понятны планы развития, есть стабильное финансирование. Поэтому фокус на чистоте и масштабируемости кода, а не на скорости его написания.
Не хотим растягивать собеседования на несколько месяцев.
Какие варианты рассмотрели и почему они не подошли
Алгоритмическое: наш скоуп задач не требует знания каких-то специфических алгоритмов.
Кодинг: не даёт достаточного понимания уровня кандидата с большим опытом.
Опросник: сложно проверить навыки в проектировании.
Что выбрали
Учитывая эти требования, мы выбрали системный дизайн как наш основной этап технического интервью. Главными факторами для нас были:
Возможность оценки кандидатов с большим опытом.
Упор на архитектурные навыки.
Возможность проверить знания по каким-то областям по ходу интервью, если думаем, что кандидат круто разбирается в теме, или, наоборот, что у кандидата есть пробелы.
Смотрим на то, как человек будет работать в целом: как собирает требования, общается с заказчиком, как учитывает риски и какие предположения высказывает.
Как перешли на новый формат
Не все разработчики имели опыт собеседований по системному дизайну даже в качестве кандидатов. Мы выделили «инициативную группу» из тех, у кого уже был опыт проведения интервью по системному дизайну, и первые собеседования проводили в парах: один интервьюер с опытом проведения собеседования по системному дизайну, и один — без опыта. За счёт того, что пул интервьюеров формировали из инженеров уже с опытом собеседований, часто хватало одного-двух собеседований, чтобы инженер понял суть и мог его провести самостоятельно, обучая другого коллегу. Так мы смогли перевести команду на новый формат собеседований за месяц.
Как мы поняли, что формат работает
Поиск метрик для определения успешности собеседований — известная проблема. Мы отметили следующие важные пункты:
Минимизация false-positive — когда на испытательном сроке понимаем, что кандидат не справляется с задачами. False-positive наймы обходятся очень дорого для компании: помимо затрат на зарплату сотрудника приходится снова запускать процесс найма. Такой случай был всего один, и тогда мы заменили системный дизайн на опросник.
Точность в определении грейда. Смотрели на первом performance review, как совпадает перформанс нового сотрудника и матрица компетенций для его грейда.
Удержание сотрудника. Смотрели, сколько людей уходят по собственному желанию вскоре после принятия на работу.
По этим метрикам мы поняли, что системный дизайн идеально подходит для нашего формата собеседований.
Какую структуру получили
Первый контакт с рекрутером. Рекрутер рассказывает о компании и продукте, базово фильтрует кандидатов.
(Опционально)Скрининг. Назначаем, если по резюме есть сомнения в опыте кандидата. Проводим в виде получасового опросника с упором на платформу и фреймворки. Цель этого этапа — понять, стоит ли звать кандидата на основное техническое интервью.
Техническое интервью по системному дизайну с двумя инженерами, один из которых обязательно лид уровня. Проверяем технические навыки кандидата, пытаемся определить грейд.
Финальное интервью с менеджером и руководителем направления. Проверяем софт-скилы, определяем грейд, подбираем подходящее направление и презентуем оффер.
С какими проблемами столкнулись и как их решали
Однако, хоть системный дизайн и подошёл в целом, нам пришлось дорабатывать этап.
Долго прорабатываются задачи для собеседований
Самостоятельная проработка новой задачи перед собеседований занимала довольно много инженеро-часов, а компетенция была только у составителя задачи, второму интервьюеру приходилось руководствоваться небольшими заметками, которые прислал автор. Поэтому мы сформировали пул задач и документацию к ним: формулировка базового запроса, что сразу рассказать кандидату, что он должен собрать сам, распространённые граничные случаи, дополнительные задания и наводящие вопросы.
Собеседование длится слишком долго
Собеседование длится полтора часа, но впечатление о кандидате можно составить за 30–40 минут, если понимать, какие маркеры ищете и как создать ситуацию для их проверки. Мы проанализировали процесс интервью, и поняли, что много времени тратится на знакомство и на объяснение процесса собеседования. Мы поменяли подход к знакомству, сделав его ближе к формату smalltalk, чтобы сломать лёд и кандидат почувствовал себя спокойнее. А подробнее о структуре команды и процессах рассказывали менеджер и руководитель направления на финальном собеседовании.
Формат непривычен для кандидатов
Не все кандидаты знакомы с интервью по системному дизайну, уточнение деталей по формату интервью отнимало у кандидата время, которое он мог бы потратить на решение, это ставило кандидатов в неравные условия. Мы скооперировались с рекрутером и деврелом, и сделали для кандидата памятку о процессе интервью, которую рекрутер отправляет вместе с приглашением на техническую часть. Памятка содержит краткое описание интервью, наши ценности, на которые мы обращаем внимание по ходу собеседования, и рекомендации по подготовке.
Отсутствие фидбэка для кандидатов
Интервьюеры формировали отзыв «для внутреннего использования», который был полезен компании, но не кандидатам, которым приходил отказ со стандартной формулировкой, что немного портило впечатление от интервью. Мы договорились, что в случае отказа всё равно предоставляем кандидату фидбэк с рекомендациями по зонам роста и материалами для них. А для экономии времени инженеров создали документацию с наиболее популярными проблемами в хард и софт навыках, способами их решения и готовыми формулировками для фидбэка. Таким образом, даже если кандидат не проходил собеседование, он понимал, что именно было не так, какие у него зоны роста и какие материалы могут помочь.
Этим мы смогли сократить время интервью на полчаса, суммарно экономя один инженеро-час, а подготовка редко превышает 15 минут: просмотреть резюме, склонировать доску в Miro, перечитать документацию по задаче и после собеседования написать отзыв.
Вместо заключения
Мы выбрали системный дизайн как основной этап технического интервью, так как он позволяет более точно оценить навыки кандидата уровня senior и выше, его подход к проектированию систем и принятию архитектурных решений, эффективно выстроить процесс обратной связи с кандидатами и существенно сэкономить время инженеров.
В следующей статье я подробнее рассмотрю системный дизайн с обеих сторон: интервьюера и кандидата, и поделюсь советами для них.
