Практически каждый бэкенд разработчик, начиная с определенного уровня, на интервью сталкивается с необходимостью продемонстрировать свои навыки проектирования распределенных приложений. Под это может быть выделено 15 минут во время единственной встречи с тимлидом, а может, предложат пройти две независимые секции по 45-60 минут, если вы претендуете на относительно высокую позицию в западной интернет-компании.

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


Disclaimer: Эта статья не научит вас проектировать (распределенные) системы, для этого есть другие материалы, курсы, работа, наконец. Цель данного материала - помочь людям, которые уже умеют проектировать и делали это не один раз, успешно пройти собеседование.

Зачем вообще проводятся архитектурные секции? По большому счету, для собеседующего это единственный способ оценить какой сложности систему сможет спроектировать, реализовать и поддерживать сидящий напротив кандидат. Обычно, кандидату дается типовая задача, например, спроектировать Инстаграмм, Твиттер или что-то поменьше типа веб-краулера или подсистемы комментариев. Основными преимуществами типовых задач являются легкость калибровки (сравнения) кандидатов между собой и пониженные требования к интервьюерам. Достаточно написать подробную инструкцию как оценивать кандидатов и можно откинуться в кресле и ждать результатов. Альтернативным способом проведения архитектурных секций является так называемая техническая ретроспектива. На такой секции кандидат рассказывает собеседующему об одном из наиболее крутых своих проектов, а интервьюер задает разные вопросы, позволяющие понять какими соображениями руководствовался кандидат, когда создавал эту систему. Минусы этого подхода очевидны: слабая масштабируемость, отсев потенциально сильных кандидатов, которые не могут рассказать о недавних проектах из-за NDA. Поэтому дальше я буду рассказывать о первом варианте проведения архитектурных секций.

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

Структура интервью

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

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

Следующим шагом рекомендую поделиться с интервьюером планом вашего будущего рассказа. В качестве шаблона можно взять следующую структуру:

  • требования, функциональные и нефункциональные;

  • высокоуровневая архитектура;

  • ключевые продуктовые и технические метрики;

  • масштабируемость, отказоустойчивость;

  • оценка необходимой мощности;

  • эксплуатация, включая, например, выкатку новых версий и обнаружение и починку инцидентов.

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

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

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

Итак, время рисовать дизайн, который для большинства систем состоит из трех прямоугольничков: frontend, backend, database. Это, конечно же, шутка, но, как говорится, в каждой шутке только доля шутки.

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

  • Старайтесь сохранять дизайн как можно более простым.

  • Фокусируйтесь на ключевой функциональности.

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

  • Когда рисуете на схеме любые квадратики, прямоугольнички или стрелочки, объясняйте какую задачу они решают, какие альтернативы есть и почему вы выбрали именно эту. Например, хорошим обоснованием будет более точное соответствие требованиям или легкость в эксплуатации, плохим - знакомство только с этим вариантом.

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

Окей, высокоуровневая схема нарисована, знания о том, какие виды балансировки трафика или консистентности баз данных бывают, продемонстрированы, пора переходить к эксплуатационным аспектам проектируемой системы.

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

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

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

Ну, и в конце стоит быстро упомянуть, что вы знаете, что такое CI/CD, зачем нужны тесты, как вы будете выкатывать обновления в продакшн и кого будет будить робот ночью в случае проблем.

Подготовка

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

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


Все вышеописанное основано на личном опыте как интервьюирующего и так и интервьюируемого, но, как обычно, YMMV. Удачи на собеседованиях!

Комментарии (7)


  1. XaBoK
    11.05.2022 21:25

    Я не очень понимаю, зачем спрашивать верхнеуровневую архитектуру у разработчика. Для этого есть архитекторы. Разработчик должен уметь проектировать детали исполнения задания в коде. Уровень паттернов. Но если уж вас спрашивают, то:

    • основной фокус на детали задания - можно додумать, что там не указанно, но нельзя игнорировать то, что написали

    • фокус на безопасности - это всегда ограничивающий фактор

    • затем отказоустойчивость (восстановление, масштабируемость)

    • ну и автоматизация (тестирование, деплой и тд)

    И вот после этого можно начинать рисовать кубики без деталей.


    1. 1nd1go
      12.05.2022 23:13
      +1

      Спрашивать надо, потому что если разработчик не может даже рассказать о системе в которой его код работает, какие решения стоят за дизайном в который ему надо вписаться, то и код его будет работать через «пук- среньк-ой-тут-контейнер-все-прибил» и другое стыдное


      1. XaBoK
        13.05.2022 00:16

        Я думаю, что горизонт архитектора намного дальше и шире, чем у разработчика. Это разные уровни профессии. Это всё равно, что спрашивать про задачи и решения директора. Вы же не менеджера нанимаете. Отличная практика, спросить на один уровень выше (тимлид/техлид), но не на два-три.

        Конечно, он (программист) должен уметь рассказать о системе и понять систему. Так же как и понимать работу своего непосредственного лида. Но не проектировать, так как понимание "почему" уже намного глубже чем "как". И часто встречающийся, худший вариант собеседования - интервьюер сам не понимает глубоко предметную область и ожидает, что ему выдадут именно то решение, которое у него, а остальные не верные. Медсестра трансплантационной клиники нанимает санитара и просит построить план операции по пересадки сердца. Странновато, правда?

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


  1. wadik69
    11.05.2022 21:28

    https://www.youtube.com/watch?v=xfH2QMdCvWA - вот видео близкой тематики. Также на этом канале можно ещё парочку видео найти похожего содержания


  1. misato
    12.05.2022 07:48

    Перечитайте еще раз книжки про проектирование распределенных систем

    Кто-нибудь, посоветуйте, пожалуйста, хорошую книжку на эту тему. Можно на английском.


    1. andToxa
      12.05.2022 08:48
      +2

      Мартин Клеппман: Высоконагруженные приложения. Программирование, масштабирование, поддержка.


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


    1. questor
      12.05.2022 14:51
      +2

      Одна из типичных рекомендаций - Designing Data Intensive Applications от Martin Kleppman, в простонародье "кабанчик" (по рисунку на обложке издательства O'Reilly). На русском издавал Питер, под названием Высоконагруженные приложения, Клеппман Мартин.

      Помимо книг посмотрите вот такой репозиторий на гитхабе: https://github.com/donnemartin/system-design-primer

      Не из книг, но весьма ценятся в украинско-русском сообществе по подготовке в FAANG два вот таких курса: