Подготовка к System Design Interview в MAANG+ компании

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

Я недавно успешно прошел ряд System Design сессий в указанные выше компании. Ниже я опишу свой опыт успешной подготовки к этому виду собеседований на уровне Senior/Staff Software Engineer в компаниях уровня Meta/Apple/Amazon, а также перспективных стартапах (Stripe/Reddit).

Есть много ресурсов, которые содержат отличные примеры и подробные сведения о передовых методах проектирования систем, например, Groking System Design или Designing Data-Intensive Applications. Но кроме схемы подготовки, в целом похожей на другие источники, я дам несколько советов, основываясь на личном опыте, который получил на собеседованиях.

Привычный набор собеседований в компаниях MAANG уровня — это Coding, System Design, Behavioral. Coding-секция проверяет собственно способность кодить, Behavioural(поведенческая) часть содержит вопросы о том, как кандидат действовал в конкретной ситуации. Они предназначены для оценки реакций на стресс, навыков саморегуляции и особенностей поведения в профессиональной среде.

Теперь разберемся, что собой представляет секция собеседований System Design. На ней проверяется способность кандидата проектировать сложные распределенные системы, знание плюсов и минусов различных подходов при проектировании архитектуры, умение уточнять требования. Эта секция очень важна для оценки уровня кандидата. Если Coding-секцию обычно важно просто пройти (pass/fail), то System Design может быть причиной downgrade и в очень редких случаях upgrade.

System Design-секция, как правило, проводится только для уровней Middle и выше, то есть если вы пробуетесь на Junior/Intern позиции, скорее всего, вам придется проводить время только за leetcode.

Условно подготовку к собеседованию по System Design, я разделил на 6 этапов, плюс 7-ой — собственно собеседование.

Этот этап, как и в целом подготовку к System Design, я рекомендую проводить еще до назначения собеседований, как часть длительной подготовки к более активному этапу. Здесь рекомендую отталкиваться от вашего собственного опыта, поэтому необходимо составить полный список “артефактов”, требующих изучения и полировки знаний. Хороший ресурс для подготовки такого списка ( и в целом для подготовки) от Donne Martin на GitHub.

На собеседованиях часто просят спроектировать что-нибудь хорошо знакомое, что используется каждый день, например, ленту Twitter или обмен сообщениями в WhatsApp. Есть около 20 популярных вопросов, архитектуру которых стоит изучить до собеседования. Некоторые концепты могут быть нетривиальны, и если вы раньше с ними не сталкивались, с ходу разобраться будет трудно. Материалы для подготовки: статья или видео, выбирайте, что больше нравится.

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

В эпоху онлайн-собеседований придется рисовать на виртуальной доске. Тут могут быть разные варианты, либо кандидат сам выбирает удобный инструмент и предоставляет доступ к своему экрану, на котором рисует архитектуру, или же собеседующий предоставит один из инструментов совместного доступа, принятый в компании. Так что советую потренироваться с популярными сервисами, которые часто предлагают на собеседовании — Google Drawings, Excalidraw, Draw.

Рассказ готов, теперь нужно его отрепетировать. Это можно сделать разными способами. Самый простой, но эффективный — рассказ самому себе о том, как устроена архитектура популярных сервисов. Отлично работает и тренировка в реальных условиях, на собеседованиях с представителями компании. Альтернативный способ — подготовка с другом, когда вы собеседуете друг друга по очереди. Можно воспользоваться и платными сервисами, в которых секцию System Design проведет сотрудник BigTech компании и даст развернутый feedback. Советую попробовать TechMockInterview или Interviewing.

Итак, вы набрались смелости и откликнулись, впереди долгожданные собеседования. Большинство компаний проводят System Design собеседования только на on-site этапе, поэтому начинать беспокоиться о нем можно после успешного прохождения Phone interview. Однако, недавно я дважды встретил System Design на Phone Screening этапе, это были собеседования в Twitter и Reddit. По всей видимости, это встречается в ряде компаний для Staff позиций. В любом случае важно расспросить рекрутера об ожиданиях от вас на каждом этапе собеседования. Это нормальная практика, рекрутер — ваш друг, он, как и вы, заинтересован в успешном интервью.

Несмотря на то что структура рассказа в целом общая для всех, компании могут делать акцент на разных вещах. Например, иногда от кандидата ожидается активное участие в разговоре, а иногда лучше сделать презентацию. Некоторые компании ждут от вас расчетов размеров хранилища/latency, а другие не оценивают вас по этому показателю, поэтому не нужно тратить время на расчеты. Чтобы правильно рассчитать время и составить план рассказа, попробуйте найти список часто встречающихся вопросов на System Design собеседовании в конкретную компанию. Помочь в этом может YouTube и раздел Discuss на leetcode.com.

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

Начните рассказ с простой high-level архитектуры, и далее переходите к усложнению, по шагам проходя по каждому из узких мест. Очень важно не забывать, что нет идеального варианта архитектуры, и конкретный выбор той или иной технологии (например, SQL/NoSQL) в реальности зависит от огромного количества параметров. Поэтому проговаривайте компромиссные решения, это хороший способ показать широту знаний.

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

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

Желаю удачи!