Техническое собеседование инженеров мобильной разработки в RuStore
Проводим и проходим собеседование по системному дизайну
Привет Хабр, меня зовут Вячеслав Таранников, я старший Android-разработчик в команде монетизации RuStore, и сегодня хочу поделиться взглядом, из каких ингредиентов можно собрать полезное и эффективное техническое интервью.
В предыдущей статье я рассказал, как мы пришли к системному дизайну как основному этапу собеседования в RuStore.
А сейчас мы рассмотрим, как организовать интервью по системному дизайну в своей компании, как подготовиться со стороны интервьюера и кандидата, на что обращать внимание во время интервью и как подать правильный сигнал
Введение
В тени скрытых программных разработок миром правит синдикат Codefather Inc., а во главе этого организованного мира стоит сам Дон Кодлеоне — хитроумный и расчётливый Крёстный отец кода. Однажды, в таинственный лунный вечер, Дон созвал своих наиболее доверенных капореджиме, среди которых была и проницательная Карла Рекрутелли. Стопка резюме перед ними говорила о необходимости найма старшего программиста, однако Дон предупредил, что стандартные методы отбора не подходят.
Карла кивнула, соглашаясь с его словами. Вместе они решили исследовать секретные архивы Codefather Inc. в поисках новых подходов. Именно там, в глубинах базы данных, они наткнулись на загадочный документ под названием «Интервью по системному дизайну». Его содержание обещало выявить настоящих профессионалов, способных создать и разработать программные системы, выдерживающие самые жёсткие испытания.
Вооружившись новым знанием, Дон и Карла разработали инновационный план. Они решили не прибегать к традиционным методам интервью, а предоставить кандидатам реальные сценарии, требующие разработки систем для управления самыми сокровенными операциями синдиката. Этот подход привлёк внимание потенциальных кандидатов, для которых стандартные задачи алгоритмов и кодинга уже не представляют интереса.
На секретном собрании, проведённом в сердце тайного логова Codefather Inc., кандидатам предоставили сложные задачи, связанные с разработкой систем безопасности, шифрованием данных и оптимизацией архитектуры программного обеспечения. Блеснув своими навыками и находчивостью, кандидаты подтвердили свою способность взращивать кодовые империи в самых тёмных уголках цифрового мира.
Благодаря новому подходу к найму, синдикат смог найти трёх идеальных кандидатов. Один из них разработал безопасную систему хранения секретных данных, второй — инновационную платёжную систему, а третий — перепроектировал архитектуру, существенно снизив затраты на инфраструктуру.
Успешно завершив свою миссию, Дон Кодлеоне и его команда приветствовали новых старших инженеров внутри Codefather Inc. Они знали, что благодаря силе интервью по системному дизайну им удалось найти настоящих профессионалов, способных строить и поддерживать кодовые империи, процветающие в тени.
Вспоминаем, что такое системный дизайн
В прошлой статье мы рассмотрели разные форматы технических собеседований. Давайте вспомним особенности системного дизайна
Секция целиком посвящена проектированию. Кандидату даются картинки user-flow и очень абстрактная задача, например, «спроектируй поиск в музыкальном приложении», а интервьюеры выступают в роли всех возможных коллег — от проджект менеджера до бэкэнд разработчиков и дата аналитиков. Кандидат должен собрать требования и нарисовать диаграмму классов решения.
Плюсы подхода:
Позволяет довольно точно определить уровень навыков кандидата за счёт свободы в подходе к решению.
Максимально приближен к реальным рабочим условиям: кандидату не нужно отдельно готовиться или что-то повторять — достаточно просто продемонстрировать свои повседневные навыки.
Позволяет интервьюеру попутно задавать смежные вопросы, привнося элемент «опросника».
Хорошо показывает софт-скилы кандидата.
Минусы:
Не подходит для джунов: у них ещё нет достаточного опыта в сборе требований и проектировании.
Каждая задача требует предварительной проработки интервьюером, чтобы он мог учесть неочевидные кейсы.
Показывает навыки кодинга лишь косвенно.
Формат непривычен для кандидатов в РФ.
Итог:
Хороший вариант для стабильных проектов, где у кандидата ожидается большая зона ответственности и возможность участвовать в принятии архитектурных решений.
Упор на масштабируемость и чистоту архитектуры, подойдёт для оценки старших грейдов (мид+ и выше).
Интегрируем системный дизайн в свой процесс интервью
Предположим, вы решили, что вашей компании подойдёт системный дизайн, но не знаете, с чего начать. Вот основные шаги, которые могут вам помочь:
Выбор инструмента
Для начала стоит выбрать инструмент для проведения интервью. Он должен отвечать следующим требованиям:
Поддерживает рисование диаграмм.
Позволяет проводить коллаборативный рекрутинг (т. е. привлекать несколько сотрудников к процессу отбора).
Для оффлайн собеседований чаще всего используют белую доску, но подойдет и лист бумаги.
Для онлайна выбор чуть побольше. Чаще всего используют:
Miro — наиболее популярный вариант, но требует подписки. Удобно рисовать диаграммы за счёт существующих компонентов.
Excalidraw — бесплатный инструмент, но нет поддержки облачного хранения(все результаты придётся хранить локально или на сторонних ресурсах).
Подготовка
Стоит подготовить хотя бы 2 — 3 задачи.
Нарисуйте диаграмму классов самостоятельно.
Подумайте, что можно было бы спроектировать иначе и при каких условиях: например, что бы вы сделали иначе, если бы целевым рынком были страны с нестабильным интернетом.
Разделите задачу на основные требования и дополнительные.
Основные требования рассказываем в самом начале. Это то, что нужно для базовой реализации фичи. Например, если у вас экран поиска, то основными требованиями могут быть: поле ввода, отображение подсказок под полем ввода, отображение списка результатов поиска.
Дополнительные требования можно выдавать не сразу, чтобы посмотреть, как предложенное решение кандидата адаптируется под изменение. Например, для экрана поиска таким требованием может быть предварительный поиск в кэше или дебаунс на поле ввода.
Виды требований
Функциональные
Описывают, как пользователь будет взаимодействовать с приложением. Например, возможность проскроллить приложения в каталоге или загрузить их.
Нефункциональные
Незаметны пользователю, но влияют на его опыт взаимодействия с приложением. Например, кэширование или подгрузка превью в низком разрешении для экономии трафика.
За скоупом
Помните, что временные рамки интервью ограничены, и нужно фокусироваться на наиболее важных для вас аспектах проектирования. Например, если вы ищете только мобильного разработчика, основной фокус при проектировании может быть на клиентской части, при этом бэкэндеры готовы обсудить и структуру API. Или, например, авторизацию можно оставить за скоупом, так как она уже есть в приложении.
Тайминги для часового интервью
Час - наиболее оптимальная продолжительность для собеседования. У вас будет достаточно времени, чтобы познакомиться и обсудить интересующие темы, при этом сохраняя высокий уровень концентрации кандидата.
5 мин — знакомство с кандидатом и процессом.
5 мин — сбор требований. Кратко опишите задачу и предоставьте кандидату время для сбора требований.
40-45 мин — основной процесс интервью.
5-10 мин — вопросы от кандидата о компании.
Если вы только начинаете проводить системный дизайн, на интервью стоит выделять полтора часа, но с оговоркой для кандидата, что полчаса — это про запас, на случай, если попадётся какая-то очень интересная тема. Вы получите небольшой буфер времени, пока не освоитесь с тем, как эффективнее направлять кандидата в интересующее вас направление беседы.
Знакомство с кандидатом
Для интервьюера
Цель этого этапа — растопить лёд, чтобы кандидат почувствовал себя немного комфортнее, поэтому не надо еще раз пересказывать всё интро о компании. Если вы дошли до этого этапа, то скорее всего кандидату уже знакома компания. Лучше потратить это время на короткое интро: «Меня зовут Слава, я старший разработчик из команды монетизации, со мной интервью проводит Саша — лид команды SDK. Расскажи, пожалуйста, немного о себе». На этом вопросе иногда даже опытные разработчики могут растеряться, старайтесь ненавязчиво модерировать, чтобы кандидат не начал десятиминутный рассказ — это забирает его же время.
Для кандидата
На этом этапе вам надо дать базовую информацию о себе, чтобы интервьюеры могли примерно оценить ваш стартовый уровень и определили, с каких вопросов стоит начать. Тут можно кратко рассказать о каких-то сторонних достижениях. Например: «Я Слава, работаю Android-разработчиком больше пяти лет, сейчас в компании RuStore занимаюсь монетизацией. Интересуюсь Jetpack Compose, выступал на Mobius».
Знакомство с процессом
Для интервьюера
Расскажите кандидату, как будет проходить собеседование: формат, тайминги и что кандидат должен сделать. Например: «У нас сегодня системный дизайн, мы дадим очень размытую задачу, тебе нужно будет собрать требования и нарисовать UML-диаграмму. Мы будем выступать в роли всех возможных коллег — мобильные разработчики, бэкэндеры, менеджеры, поэтому задавай нам любые возникающие вопросы. На задачу отводится 45 минут, в конце оставим 5 — 10 минут на твои вопросы для нас».
Для кандидата
Обратите внимание на тайминги (а лучше запишите их). Это позволит вам лучше спланировать ход интервью и заранее понять, что есть риск не успеть что-то рассказать.
Собеседование
Для интервьюера
Всё зависит от ваших ожиданий от кандидата и его навыков. Можно выделить общие рекомендации.
Будьте агностичны к технологиям. Кандидат мог не использовать какой-то привычный для вас фреймворк, старайтесь обсуждать на уровне абстракций.
Поговорить о технологиях всё же стоит, особенно если они относятся к стеку вашего проекта. Например, если кандидат упомянул про асинхронную работу, можно спросить его, какой бы фреймворк он для этого выбрал и почему.
При разговоре о технологиях может быть несколько целей, наиболее популярные — посмотреть на то, как кандидат принимает решения, какой у него кругозор и насколько глубоко он знает какую-то технологию. Выберите, что в каждом конкретном случае вам хотелось бы понять о знаниях кандидата, и на основе этого задавайте вопросы.
Если вы категорически не согласны с решением кандидата, не нужно «давить авторитетом». Опишите ситуацию, при которой решение будет работать некорректно и посмотрите, как кандидат сможет адаптировать решение под проблему.
Не бросайте кандидата один на один с проблемой. Если видите, что кандидат где-то застрял, помогите ему разобраться — чаще всего помогает декомпозиция на небольшие элементы («Давай подумаем, на какие шаги это можно разбить?») и их постепенная интеграция. В крайнем случае можно перевести на какую-то другую проблему, предложив вернуться к изначальной, если по ходу интервью появится решение.
Старайтесь понять ход мыслей кандидата. Слушайте, что он говорит, а вопросы с принятием решения старайтесь возвращать обратно, чтобы кандидат сам предложил какие-то варианты. Например, если кандидат спрашивает, нужно ли нам кэширование, спросите, что это даст приложению, и что мы можем закэшировать. И уже после предложенных вариантов можно выбрать один из них или подвести кандидата к какой-то другой опции, которую вы бы хотели обсудить.
Постарайтесь, чтобы собеседование больше было похоже на обсуждение задачи между коллегами, но при этом задачу всё равно должен делать кандидат. Можно пошутить что-то на платформенную тему.
Для кандидата
Старайтесь задавать как можно больше вопросов. Начните с «обхода в ширину» по фичам и спрашивайте, что интервьюеру было бы интересно обсудить подробнее.
Будьте агностичны к технологиям. Секция посвящена проектированию архитектуры, которая должна быть независимой от фреймворков. Думайте, что проектируете интерфейсы.
Вы можете при этом поговорить о технологиях. Если интервьюер спросит, что бы вы использовали для решения проблемы, предложите несколько вариантов, обозначьте их плюсы и минусы, и выберите наиболее оптимальный.
Внимательно слушайте, что говорит интервьюер. Часто интервьюер будет подсказывать, что стоит обсудить подробнее или что у решения могут быть проблемы.
Если вы застряли с какой-то проблемой, попробуйте разбить её на подзадачи и решить их. Вы получите готовое решение.
Проговаривайте ход своих мыслей, даже если они кажутся вам очевидными. Непосредственно во время проектирования вы говорите 90% времени, интервьюер только направляет вас в интересное ему русло.
Маркеры, сигналы и темы для обсуждения
В этом разделе мы рассмотрим положительные и негативные маркеры кандидата.
Навыки кандидата можно разделить на два типа — хардовые (т. е. всё, что связано с написанием кода) и софтовые — связанные с межличностными коммуникациями.
Пожалуйста, не воспринимайте раздел как какой-то список обязательных тем или чеклист. Это, скорее, общий набор топиков, на основе которого вы можете сформулировать наиболее важные для вас критерии.
Начнём с хард скиллов.
Хард скиллы
«Чтобы что?»
Самый универсальный маркер — это вопрос «чтобы что?». Он позволяет определить, понимает ли человек, о чём говорит, или просто делает как привык/научили?
Знание Clean Architecture
Тут всё очевидно. Если человек ходит из экрана сразу в сеть, вряд ли он готов писать энтерпрайз приложения.
Представления о деталях клина могут отличаться в зависимости от инженерной культуры, в которой живёт разработчик. При оценке смотрите на общее понимание идеи, а не на соответствие вашим инженерным практикам. Особое внимание стоит обратить на умение выделить domain-слой и отделить его от data и presentation.
Отдельные модели для слоёв
Domain-модели должны быть наименее подвержены изменениям, так как от них зависит наибольшая часть приложений. Поэтому для data слоя создаются свои модели, чтобы защитить бизнес-логику от изменений структуры модели ответа с бэкэнда — изменение нужно будет поддержать только в конвертере. Не обязательно это рисовать, достаточно просто проговорить.
Проектирование от domain
Предположим, что перед нами стоит задача спроектировать музыкальный плеер. Кандидат может сразу начать рисовать всё подряд, от логики до UI, и через 10 минут получить неподдерживаемую схему.
А можно начать проектировать от domain, выделив основные сущности и бизнес сценарии, и уже вокруг них добавлять платформенную логику, как UI или работа с сетью/БД. При таком подходе мы получим более структурированный код с очевидными зависимостями даже без «правильных» UML-элементов и стрелочек.
Presentation-паттерны
Наиболее популярные варианты
MVVM;
MVI;
MVP/VIPER.
Более экзотические
BLoC;
RIBS.
Dependency Injection
DI-фреймворки уже стали стандартом для индустрии, и их используют даже джуны в петпроектах. Можно поговорить о том, что такое инверсия зависимостей, зачем она нужна, что такое связность и сцепление или об отличиях Service Locator от Dependency Injection.
Работа с сетью
Протоколы (REST/GraphQL/WebSocket);
Пуши;
Пагинация;
Аутентификация.
Производительность
Время запуска
Многие компании в какой-то момент начинают задумываться о том, что нужно ускорить время запуска приложений. Можно заранее обсудить какие-то техники, например, уменьшить количество запрашиваемой с бэкэнда информации, необходимой для показа первого экрана.
Кеширование
Влияет на многие факторы: время запуска, возможность пользоваться приложением оффлайн и количество походов в сеть. При использовании стоит помнить, что данные в кэше могут потерять актуальность.
Префетч
Бывают случаи, когда мы хотим ускорить показ какой-то информации даже ценой лишней загрузки из сети. В таком случае можно сделать предзагрузку данных, что визуально сделает приложение быстрее для пользователя.
Хранение данных
Key-Value
Database
Безопасность хранения данных на устройстве пользователя
Невозможность откатить релиз
Релизы мобильных приложений — как мясорубка: прокрутить корову обратно не получится. Поэтому проектируем с пониманием того, что релиз нельзя откатить, и с довольно высокой вероятностью у пользователей будут разные версии приложений. Есть механизмы, позволяющие это косвенно решить (поэтапная раскатка, force update), но их цена использования очень высока.
(Uh)happy path
В программе всегда что-то может пойти не так из-за внешних факторов. В мобильных приложениях из-за особенности сценариев использования вероятность этого стремится к единице. Вспомните, как часто в метро вы видели надпись «нет интернета» в приложении.
Это надо учитывать и проектировать с учётом возможных ошибок — от неправильно введённого пароля до упавшего бэкэнда.
Обработка ошибок сети
Первый этап обработки любых ошибок. В большинстве случаев достаточно на схеме указать возможный стейт экрана «Что-то пошло не так», но можно обсудить это подробнее, и подумать, какие ошибки пользователь может исправить сам.
Работа в оффлайне
Если можно предоставить пользователю какой-то сценарий использования без сети — можно подумать об этом вместо того, чтобы просто показывать ошибку.
Graceful degradation
Проектировать приложения стоит так, чтобы у них всегда сохранялась минимальная функциональность. В мобильной разработке это часто встречается при работе с пермишенами. При проектировании стоит подумать, какую функциональность можно предложить пользователю, если он не предоставит какие-то пермишены. Например, если пользователь не выдал разрешение на геолокацию, вместо карты можно предложить ему ввести адрес в поле для ввода текста.
Софт скиллы
Для подробной оценки софт-скилов существуют отдельные виды интервью — поведенческие (behavioral interview), которые фокусируются на командной работе и лидерских навыках. Но в рамках системного дизайна можно заметить какие-то тенденции разработчика. Рассмотрим, что не надо делать на интервью.
Длинное вступление
Как уже обсуждали раньше, цель вступления — сломать лёд и дать какие-то начальные точки для разговора. Чем дольше вступление, тем больше времени кандидат ворует у самого себя.
Игнорирует сигналы интервьюера
Одно из собеседований я провалил из-за того, что слишком сильно хотел показать свой уровень знаний и проигнорировал попытки интервьюера сменить тему. Лучше переключиться на тему интервьюера, чем пытаться закончить мысль: пытаясь закончить, вы не расскажете новую информацию, к этому моменту он, скорее всего, уже сделал вывод о ваших знаниях в этой области.
Часто меняет темы
Тяжело следить за повествованием, если рассказчик часто меняет тему. Вы, как кандидат, наиболее заинтересованы в том, чтобы у интервьюера сложилось ясное и четкое впечатление о вас.
Много молчит
Около трёх лет назад я впервые столкнулся с системным дизайном в роли кандидата, и не был уверен, как подходить к такому этапу, о чём сказал рекрутеру. Я хорошо запомнил его совет, и это моя первая рекомендация, когда рассказываю кому-нибудь о подготовке к системному дизайну: «Как можно подробнее проговаривайте, как и что вы делаете, даже если это кажется очевидным». Если интервьюеру покажется, что вы слишком подробно объясняете, он вам это скажет, но если вы объясняете недостаточно, то у интервьюера могут возникнуть вопросы. Поэтому старайтесь проговаривать ход своих мыслей: зачем вы что-то добавили, какие у вас были опасения и какие трейдоффы вы учли.
Ждёт, пока интервьюер сам начнёт задавать вопросы
Косвенно связано с предыдущим пунктом, но также если кандидат не объясняет свои решения, а ждёт вопросов, то это может указывать на проблемы с принятием решения.
Евангелизм
Давайте будем откровенны: никто не любит евангелистов и их уверенность в превосходстве какой-то технологии. На интервью их любят ещё меньше, это практически гарантированный красный флаг, что с человеком будет сложно коммуницировать.
Токсичность
Токсичность может повлиять на всю команду. Каким бы классным разработчиком ни казался кандидат, если с ним некомфортно работать, лучше отказать.
"Контрольная закупка"
Вы даёте какое-то некорректное или излишне усложнённое требование, и ожидаете, что кандидат это обсудит и либо убедит вас, что оно некорректно, либо предложит альтернативу.
Например, вы запускаете приложение заметок как можно быстрее, и вдруг одно из условий — это полноценный markdown со стилями текста и т. д. В качестве альтернативы кандидат может предложить сделать урезанную версию разметки, которая покроет подавляющее большинство пользовательских сценариев.
Стоит заметить, что этот подход работает, только если вы по ходу интервью показали, что готовы к переговорам и требования можно обсуждать. Если на протяжении всего интервью вы требовали от разработчика, чтобы он делал как в ТЗ, то контрольная закупка не сработает.
Может возникнуть ситуация, когда кандидат не поймёт контрольную закупку. Подготовьте чуть более очевидное требование. Например: «Мы хотим убедиться, что телефон не был украден. Давай при запуске оплаты добавим незаметное фото пользователя с фронталки и будем отправлять на наш бэкенд, где сравним с оригинальным портретом владельца».
Пишем фидбэк
Фидбэк для внутреннего пользования
Описываем:
Сильные и слабые стороны
Насколько хорошо впишется в вашу команду и инженерную культуру
Хард и софт скиллы
Общие впечатления о кандидате
На основе этого пишем рекомендацию, стоит ли продолжать общение, или уже понятно, что кандидат на текущий момент не подходит компании.
Фидбэк для кандидата
Что стоит указать в отзыве:
Сильные стороны кандидата
Зоны развития — именно зоны развития, не «недостатки»
Через сколько кандидат может снова податься на вакансию. Зависит от того, насколько ему не хватило знаний, обычно от трех месяцев до года.
Приучаем команду писать фидбэк
Фидбэк позволяет кандидату развиваться, а компании — улучшить имидж и повысить поток кандидатов. Даже если кандидат не пройдёт с первой попытки, он может вспомнить, что ему понравилось собеседование, и податься снова через какое-то время.
Чем проще какое-то новое действие, тем больше вероятность, что оно приживётся. Поэтому мы оформили таблицу с наиболее популярными зонами роста, готовой формулировкой для отзыва и рекомендациями для улучшения. Это позволяет интервьюерам собирать отзыв как конструктор, а не писать каждый раз с нуля.
Итог
В двух статьях мы рассмотрели, как выстроить своё технических интервью, чем системный дизайн может помочь в найме, как его интегрировать в свой процесс рекрутинга и на что обратить внимание при подготовке. В следующей статье мы рассмотрим, как написать хорошее резюме, чтобы получить больше приглашений на собеседования.
Материалы для самостоятельной подготовки
[EN] https://github.com/weeeBox/mobile-system-design/
[EN] Gergely Orosz - Mobile Apps at Scale: 39 Engineering Challenges
[RU] Боб Мартин - Чистая Архитектура
