Собеседование по проектированию системы

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

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

Сбор функциональных и нефункциональных требований

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

• Функциональные требования: что на самом деле должна делать система делать? Например, при разработке сокращателя URL-адресов следует задать один важный вопрос: хотим ли мы поддерживать обратный поиск (с длинного URL на существующий короткий URL)или если вы можете допустить, чтобы один и тот же длинный URL был сокращен двумя разными способами. Именно здесь вы понимаете, как пользователи на самом деле будут взаимодействовать с системой.
• Нефункциональные требования: как система ведет себя технически. Вы захотите понять масштаб системы (количество пользователей, одновременных запросов, объем обрабатываемых или хранимых данных). Еще одним распространенны�� фактором, который следует уточнить, является ожидаемая задержка, особенно сквозная задержка для всей системы, которая может включать требования к согласованности чтения после записи.

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

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

Представьте комплексное решение

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

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

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

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

Используйте стандартную отраслевую терминологию

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

Например, не стесняйтесь называть Kafka или Amazon SQS, если вас это устраивает, но упомяните, что вы хотите, чтобы очередь сообщений была настроена как система pub/sub. Такой подход имеет множество преимуществ:

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

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

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

Объясните, какие проблемы вы решаете с помощью своего выбора

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

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

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

Будьте готовы к глубокому погружению в свои области знаний

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

Вы говорили, что работали над потоковой архитектурой для обработки данных? Вы должны уметь говорить об очередях сообщений, упоминать такие технологии, как Apache Spark или Samza (или какие бы технологии вы не использовали раньше), компромиссы между потоковой обработкой и онлайн- или офлайн-обработкой данных и т. д. Если вы много работали с хранилищами данных, вы должны быть в состоянии говорить о шардинге, выборе баз данных, постоянном и внутридисковом кэшировании и кэшировании в памяти и т. д.

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

Поговорим о продакшн-системе

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

Здесь вы говорите о мониторинге и логировании, обработке ошибок (хотя некоторые из них, возможно, всплыли и раньше), постепенное развертывание для решения таких проблем, как периоды прогрева кэша, плавное снижение производительности в случае неожиданных всплесков трафика и т. д. В частности, мониторинг и обработка ошибок — это две области каждый системы, поэтому я бы начал с них.

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

Последний совет, который у меня есть, незначительный, но о нем стоит упомянуть: будьте готовы показывать свой дизайн по мере его создания. Если вы проводите собеседование лично, будьте готовы нарисовать блок-схемы на доске. Если собеседование виртуальное, выберите инструмент для рисования и потренируйтесь с ним. Это может даже означать приобретение собственной доски для себя! Просто убедитесь, что он виден с камеры.

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

Эта статья была первоначально опубликована на веб-сайте Hiring For Tech. Если вы хотите прочитать больше информации от меня, пожалуйста, подпишитесь по электронной почте или на LinkedIn. Если у вас есть какие-либо мысли о моем контенте, прокомментируйте ниже. И не забудьте Следуй за мной для получения большего количества контента!