Практически каждый бэкенд разработчик, начиная с определенного уровня, на интервью сталкивается с необходимостью продемонстрировать свои навыки проектирования распределенных приложений. Под это может быть выделено 15 минут во время единственной встречи с тимлидом, а может, предложат пройти две независимые секции по 45-60 минут, если вы претендуете на относительно высокую позицию в западной интернет-компании.
В этом посте я расскажу зачем вообще проводятся эти секции, ответы на какие вопросы надеется услышать интервьюер и как лучше готовиться к этому типу собеседований. Если интересно, поехали под кат.
Disclaimer: Эта статья не научит вас проектировать (распределенные) системы, для этого есть другие материалы, курсы, работа, наконец. Цель данного материала - помочь людям, которые уже умеют проектировать и делали это не один раз, успешно пройти собеседование.
Зачем вообще проводятся архитектурные секции? По большому счету, для собеседующего это единственный способ оценить какой сложности систему сможет спроектировать, реализовать и поддерживать сидящий напротив кандидат. Обычно, кандидату дается типовая задача, например, спроектировать Инстаграмм, Твиттер или что-то поменьше типа веб-краулера или подсистемы комментариев. Основными преимуществами типовых задач являются легкость калибровки (сравнения) кандидатов между собой и пониженные требования к интервьюерам. Достаточно написать подробную инструкцию как оценивать кандидатов и можно откинуться в кресле и ждать результатов. Альтернативным способом проведения архитектурных секций является так называемая техническая ретроспектива. На такой секции кандидат рассказывает собеседующему об одном из наиболее крутых своих проектов, а интервьюер задает разные вопросы, позволяющие понять какими соображениями руководствовался кандидат, когда создавал эту систему. Минусы этого подхода очевидны: слабая масштабируемость, отсев потенциально сильных кандидатов, которые не могут рассказать о недавних проектах из-за NDA. Поэтому дальше я буду рассказывать о первом варианте проведения архитектурных секций.
Интервьюеры обычно ищут сигналы в следующих областях: техническая компетентность и кругозор, планирование и коммуникация. И если с первыми двумя пунктами все более-менее понятно, то два последних стоят дополнительного объяснения. От разработчика, особенно высокого уровня, ожидается, что он может, во-первых, структурировано объяснить, как и что он собирается делать, а во-вторых, услышать обратную связь и ответить на возникающие вопросы. Чтобы дать интервьюеру эти сигналы, я рекомендую придерживаться нижеследующей структуры интервью.
Структура интервью
Итак, вы на собеседовании, интервьюер дал задачку, что же дальше? Во-первых, помните, что ваша задача - играть как можно более активную роль в обсуждении, по факту вы должны его вести. Однако, не забывайте включать интервьюера в диалог, он может задать уточняющие вопросы или дать важные подсказки. Главное, не уходите в состояние, когда собеседующему нужно вытягивать информацию из вас клещами.
Возвращаясь к самой задаче, первым этапом будем полезно понять в чем же ключевая часть проектируемой системы? Например, у Твиттера и Инстаграмма это может быть лента новостей, у системы по проведению соревнований по программированию - модуль по проверке корректности ответов, а у системы живых комментариев механизм уведомления участников об печатаемом ответе. Не тратьте тут больше нескольких десятков секунд, если ответ сразу не пришел в голову, то еще будет время его найти.
Следующим шагом рекомендую поделиться с интервьюером планом вашего будущего рассказа. В качестве шаблона можно взять следующую структуру:
требования, функциональные и нефункциональные;
высокоуровневая архитектура;
ключевые продуктовые и технические метрики;
масштабируемость, отказоустойчивость;
оценка необходимой мощности;
эксплуатация, включая, например, выкатку новых версий и обнаружение и починку инцидентов.
Эти пункты можно прям написать на виртуальной или физической доске. Это, с одной стороны, поможет вам не сбиваться во время рассказа, а с другой, если времени не хватит, интервьюер все равно будет помнить, что вы хотели эти темы затронуть.
Следующий этап это сбор требований. Тут как раз поможет понимание того, что является ключевой особенностью проектируемой системы. Например, для ленты новостей важными свойствами могут быть порядок сообщений, среднее и максимальное количество подписчиков или то, с какого момента подписчик у себя в ленте должен видеть посты тех людей, на которых он подписался. Нефункциональные требования могу включать в себя общее кол-во пользователей системы, кол-во запросов (среднее и пиковое), ожидаемое время ответа, максимальное время недоступности и так далее. Необязательно собирать все возможные требования сразу, вполне нормально возвращаться к этому пункту в процессе проектирования для того, чтобы разрешить возникшую неопределенность.
Важная ремарка: не собирайте требования только ради сбора, впечатление о вас будет значительно лучше, если все собранные требования найдут отражение в получившемся дизайне.
Итак, время рисовать дизайн, который для большинства систем состоит из трех прямоугольничков: frontend, backend, database. Это, конечно же, шутка, но, как говорится, в каждой шутке только доля шутки.
В целом, на данном этапе у вас есть возможность проявить себя и показать свой опыт. Пока вы это делаете, помните о следующих моментах:
Старайтесь сохранять дизайн как можно более простым.
Фокусируйтесь на ключевой функциональности.
Не оставляйте неупомянутыми важные свойства: например, то, что backend слой на самом деле состоит из нескольких экземпляров приложения, которые не имеют состояния, и то, что это позволит вам легко масштабировать систему в будущем.
Когда рисуете на схеме любые квадратики, прямоугольнички или стрелочки, объясняйте какую задачу они решают, какие альтернативы есть и почему вы выбрали именно эту. Например, хорошим обоснованием будет более точное соответствие требованиям или легкость в эксплуатации, плохим - знакомство только с этим вариантом.
Старайтесь, чтобы каждому из элементов вашей схемы соответствовало хотя бы одно требование, а главное явно это проговаривайте. Если вы добавляете сложность просто так, то у интервьюера могут возникнуть неудобные вопросы :)
Окей, высокоуровневая схема нарисована, знания о том, какие виды балансировки трафика или консистентности баз данных бывают, продемонстрированы, пора переходить к эксплуатационным аспектам проектируемой системы.
Начинать говорить об эксплуатации, пожалуй, стоит с метрик, как продуктовых так и технических. Продуктовые метрики покажут, что вы понимаете для чего будет использоваться система, которую вы строите. Технические же продемонстрируют, что вы знаете как эксплуатировать сложные программные комплексы и как использовать метрики для выявления и диагностики неприятностей. Здесь же можно упомянуть логи и трейсы и как они помогают в диагностике проблем.
Для разговора о масштабируемости и отказоустойчивости я рекомендую выделить отдельную двух-трех-минутку, еще раз пройтись по всем компонентам схемы и рассказать, как именно будут обеспечиваться эти свойства. Однако, не стоит вдаваться в детали слишком глубоко до тех пор, пока интервьюер этого не попросит.
Следующий шаг это оценка количества оборудования, необходимого для функционирования системы. Стоит явно спросить интервьюера хочет ли он, чтобы вы это посчитали. Если да, то используйте цифры из опыта и интернета, но не забудьте про то, о чем говорили в предыдущем пункте о доступности и отказоустойчивости и заложите запас, чтобы обеспечить также и эти характеристики.
Ну, и в конце стоит быстро упомянуть, что вы знаете, что такое CI/CD, зачем нужны тесты, как вы будете выкатывать обновления в продакшн и кого будет будить робот ночью в случае проблем.
Подготовка
Начинать готовиться нужно с теории. Перечитайте еще раз книжки про проектирование распределенных систем и статьи в интернете на эту тему, освежите воспоминания о тех системах, в проектировании которых вы принимали участие, посмотрите записи выступлений на конференциях, где докладчики рассказывают о создании или переработке сложных систем.
Но, сколько бы мы не говорили о важности теории, в конечном счете, на собеседованиях все решает практика. Как и с секциями на кодирование, я рекомендую немного попрактиковаться перед прохождением архитектурной части. Начните с соло варианта, записывая себя, например, в зуме, потом попрактикуйте мок-интервью с инженерами из крупных компаний. В конце подготовки сходите на пару собеседований в компании второго эшелона, это поможет вам уменьшить стресс и чувствовать себя более уверенно в боевой обстановке. В процесс подготовки внимательно следите за таймингом, весь рассказ должен укладываться в 30-35 минут, оставшееся время, если оно будет, можно посвятить обсуждению особенностей системы или одной из ее компонент.
Все вышеописанное основано на личном опыте как интервьюирующего и так и интервьюируемого, но, как обычно, YMMV. Удачи на собеседованиях!