Недавно я искал работу Golang разработчиком в нескольких крупных российских ИТ компаниях. Как я готовился к собеседованиям и как они проходили — об этом можно почитать в статье моего блога. Одним решением алгоритмических задачек не обошлось. Для меня стало сюрпризом, что в некоторых компаниях нашего аналога MANGA появилась аналогичная практика проведения секции проектирования систем, известная за рубежом как system design interview.

Мотивация проведения

Все понимают, что большие системы не проектируются за час, но зачем тогда эти интервью проводят? За Google не скажу, но мне понравилось объяснение Александра Поломодова из Тинькофф. Он мотивировал потребность в этой секции тем, что при росте их компании в командах должны появляться люди с экспертизой дизайна новых систем, чтобы команды оставались самостоятельными. Эта мысль нашла во мне большой отклик. На прошлой работе была ровно такая проблема: компания увеличивала количество команд, нанимая джунов и мидлов, чтобы делать всё больше и больше, но когда какой-то команде прилетала задача дизайна новой подсистемы, то часто приходилось звать на помощь единственного «разработчика-архитектора», которому и без того задач хватало. Минусы такого подхода, думаю, всем очевидны.

Мой опыт

До прохождения этой секции у меня был опыт проектирования одной более-менее нескромной системы, дизайн документ которой писался месяц и занял пару десятков страниц. В свободное от работы время изучал чужие по статьям и докладам. Немного помогло то, что рекрутеры описали кратко план интервью и рекомендовали ознакомиться с моделью C4 для описания систем. Предстояло не только общаться с интервьюером, но и рисовать схемы в online редакторе. В этот раз обошлось без лагающих интерфейсов: было достаточно пошарить свой экран в Miro или Diagrams.net. Я заранее подготовил доску, разместив шаблоны архитектурных элементов и подготовил текстовые блоки для сбора требований и расчета нагрузки.

В назначенный час мы созвонились с интервьюером, он описал задачу, и я начал заполнять доску, параллельно рассказывая о принимаемых решениях и задавая вопросы. Мне попались классические кейсы, поэтому удалось выполнить план и ответить на вопросы по эксплуатации. Время прошло очень быстро. Отметил для себя, что NoSQL хранилища данных — это определённо вектор для моего развития :-)

Разбор полетов

Вернувшись с собеседований, я начал анализировать полученный опыт и пытался сравнить его с чужим. Среди знакомых не было людей, которые проходили подобное, поэтому за основу я взял видео публичных прохождений этой секции.

То, что я увидел, показалось мне достаточно естественным. В них я видел все те проблемы, которые ожидал от этого формата интервью или с которыми столкнулся сам. Далее я пройдусь прямо по этим моментам, а в качестве примеров дам ссылки на записи, которые лучше всего иллюстрируют неприятные ситуации.

Выражу своё уважение к участникам подобных видео-экспериментов: я на себе оценил насколько нервозная обстановка на таком интервью, что может подать людей не с лучшей стороны, а делиться записью произошедшего на большую аудиторию вообще сродни подвигу.

Битва телепатов

Самый часто встречающийся случай: интервьюер не заметил, как кандидата унесло не туда, куда надо было интервьюеру. Вот пример крайне запущенной ситуации.

Тут предлагалось спроектировать систему мониторинга. Но вместо дизайна убийцы prometheus и grafana получилась сессия «как всё собрать из готовых кубиков». Учитывая то, что Владимир даже активно обсуждал идеи кандидата, могло сложиться впечатление, что мы на собеседовании для позиции solution architect. Но по финалу стало понятно, что на самом деле ожидалось совсем другое. Жаль, что сам интервьюер не рассказал как бы он решал эту задачу.

В стрессовой ситуации человек склонен говорить больше о том, в чем хорошо разбирается и оттягивать переход к сложным темам. Если интервьюер вовремя не перенаправит внимание кандидата, то это закончится разочарованием для обоих. В этом примере Александр своевременно указал на ошибку и собеседуемый смог её исправить.

Заезженные кейсы

«Задизайните нам VK/Google Drive/Bitly»: говорит интервьюер, надеясь удивить кандидата масштабом задачи. Но проблема в том, что большинство из них уже подробно разобраны, в том числе на Youtube. Давая такие задания, вы вряд ли проверяете что-то, кроме способности выучить наизусть готовые кейсы.

Тупняк с цифрами

На этапе оценок RPS и объема хранилищ нужно уметь быстро умножать и делить большие числа, переводить единицы измерения. Вот показательный пример того, что бывает, когда кандидату достался задача об очень «прожорливом сервисе» и он оказался к этому не готов. В результате полное решение так и не было представлено.

Задачи «со звёздочкой»

Даже в этом типе интервью можно придумать задачи повышенной сложности. Например, когда добавляется нестандартная алгоритмическая подзадача: дизайн сервиса заказа такси и подзадача быстрого поиска водителей для клиента. Или как в примере выше: движок для работы с time series данными. Давая такой «гроб», велик риск ввести человека в ступор на раннем этапе. И как потом его оценивать?

Приручаем разбушевавшегося пёсика

Провести осмысленный System Design Interview — это высший пилотаж для интервьюера и большой стресс для кандидата.

Первый должен, не раскрывая всех карт, удержать кандидата в нужном русле, чтобы комплексно оценить навыки. Для второго одновременно думать, рисовать и говорить — тоже тот ещё челлендж. Добавим сюда ещё ограничение по времени, нечеткие требования и постоянные попытки угадать чужие мысли, и получим настоящую олимпиадную задачу для архитекторов.

Такое интервью — это обоюдоострый инструмент. Если в алгоритмической секции интервьюер в принципе может расслабиться, т.к. критерий решения задачи объективный (работает ли решение корректно и с нужной скоростью), то тут причиной провала может быть и он сам. Негативный фидбэк от известного кандидата высокой квалификации может принести существенный урон репутации компании.

Можно ли с этим что-то сделать? Если навыки дизайна систем для вас всё-таки важны, но у интервьюера нет большого опыта собеседований и вы вообще ни разу не Google, то можно понизить градус гиковости интервью следующими способами.

Ведущий или ведомый

Найдите баланс между слушанием и ведением интервью. Стоит отталкиваться от ваших ожиданий от кандидата, его уровня, реальных условий дизайна систем в вашей компании.

Дом, милый дом

Вместо дизайна больших систем, которые изнутри никогда не видели, предложите реализовать то, с чем реально работали или что есть у вас. Интервьюер будет лучше себе представлять то, что предлагается построить, и снизит вероятность того, что предложенный кейс будет известен кандидату. Кандидат же получит лучшее понимание о масштабе будущих задач.

Детали важнее

Вместо дизайна абстрактных систем можно предложить реализовать какой-то узкий, но максимально конкретный кейс, который можно полностью покрыть за час: интеграция систем, надежная коммуникация, вопросы консистентности, выполнение периодических операций. Умение решать часто встречающиеся задачи подчас показательнее рисования однотипных схем и абстрактных размышлений.

«У нас лапки»

Вместо проверки того, как можно дорого и богато растянуть банальный кейс до хайлоада, можно попросить оптимизировать стоимость владения, адаптировать решение под текущий ИТ ландшафт компании и навыки имеющихся людей, пусть и жертвуя какими-то характеристиками.

Все всё понимают

Стоит ли требовать всех расчётов по нагрузке, давая только бизнес-метрики, или можно дать кандидату сразу финальные цифры? Есть ли вообще смысл их обсуждать, если вы готовы транслировать кандидату, что ожидаете достаточно стандартное для хайлоада решение: всё должно скейлится в очевидных пределах? Логически развивая тему цифр, вы точно хотите потребовать еще и оценку необходимого количества серверов, баз данных и очередей от человека, который прямо на глазах начинает резко дорожать после каждого следующего вопроса, требующего большого опыта?

Дорогу осилит идущий

Если вам понравилась идея, но есть вопросики к деталям реализации, то никто не мешает поступить с секцией проектирования систем так, как поступают у нас со scrum-ом: взять оригинальную идею – проверка навыков дизайна распределенных системам, – и адаптировать её под свои потребности. С развитием технологий даже в небольших компаниях появляется запрос на людей с пониманием как работают системы целиком. Если кандидат не справился с подобным интервью, проектирование может стать направлением для его роста, делая разработку более стабильным процессом. В общем, расставляя собственные акценты, можно получить от этого инструмента пользы больше, чем от следования чужим канонам.

Конечно, остаётся вопрос к софт-скилам интервьюера. В первую очередь он должен справиться со своим эго: оставаться максимально объективным и уметь слушать собеседника. Давая настолько объёмную задачу, спрашивающий должен определиться: о чем он хочет услышать в деталях, а что можно оставить за скобками. Без хороших навыков общения он не сможет передать свои акценты или корректно указать на проблемы, но умение доносить свои мысли полезно и в повседневной работе.

О подготовке к собеседованию

В первую очередь, пройти это интервью поможет опыт построения систем. Если под сеньористостью кандидата подразумевать его способность брать на себя ответственность за масштабные проекты и справляться с ними, то эта секция — хороший способ её оценить. Если такого опыта нет — начинайте учить матчасть и «тренируйтесь на кошечках».

Для начала можно посмотреть на Youtube канале физтеховского ФПМИ курс «Highload» от автора одноименной конференции. Выделяются лекции тем, что лектор мотивирует студентов находить самые простые рабочие решения и подробно разбирает типичные задачи типа инвалидации кэшей и шардирования реляционных баз.

У меня лично есть пунктик на тему корректности работы распределенных систем. Поэтому  нахожу для себя интересным чтение статей об устройстве инструментов, на которые все полагаются: например, различные базы данных и очереди. Идеи оттуда иногда приходится заимствовать для создания собственных протоколов. Последним таким увлекательным чтивом для меня стала статья об устройстве транзакций в Kafka.

За более фундаментальными знаниями по дизайну систем и просто советами по прохождению интервью можно обратиться к другому докладу того же Александра Поломодова.

Чтобы лучше понимать атмосферу мероприятия, можно посмотреть записи публичных собеседований, которые я упоминал ранее. Если у вас есть знакомый с опытом проведения таких интервью — обратитесь к нему. Существуют сервисы, готовые найти вам практикующих интервьюеров, чтобы провести тестовую сессию.

Быстро закрепить знания, и просто собрать мозг в кучку непосредственно перед интервью поможет книга «System Design Interview: An Insider's Guide». Еще в ней много ссылок на статьи из технических блогов крупных компаний. Изучение реальных кейсов помогает пополнять набор рабочих приемов и просто будет постоянным источником вдохновения.

Разогрев

Как уже стало понятно, на собеседовании у вас будут рутинные операции, которые вы должны делать быстро, чтобы осталось время для важного. Потренируйтесь:

• Быстро рисовать схемы и делать подписи в выбранном редакторе. Бороться с ним на самом интервью вы вряд ли захотите.

• Делать расчеты нагрузки и объемы хранилищ, конвертировать одни единицы в другие. Волнуясь, легко начать опечатываться в калькуляторе и забыть сколько байт в петабайте.

Подводя итоги

Верю, что system design interview — это ещё один инструмент для развития ИТ индустрии: чем шире в массах разойдутся знания о распределённых системах, тем лучше будут сервисы для наших пользователей. Да, изучение потребует усилий. Но самосовершенствование и создание чего-то большого — это то, за что многие и любят программирование.

Остаётся только надеяться, что несмотря на новую прогрессивную игрушку, компании смогут разумно ею воспользоваться: помогут с обучением и сохранят для кандидатов баланс между требованиями к ним и получаемой компенсацией :-)