Все про собеседования по System Design / ДЕПЛОЙ ПОДКАСТ

Сегодня мы разберем подробный разговор о том, как устроена и зачем нужна секция System Design на технических собеседованиях: от истории её появления и ключевых навыков, которые она проверяет, до типичных ошибок кандидатов и советов по подготовке. Интервьюер из телеком-компании Mango Office делится практическим опытом — как грамотно внедрять такие интервью, избегать субъективности и почему System Design считается одним из самых честных инструментов оценки инженерных компетенций.

Вопрос 1. Что такое IT-бизнес-партнёр и в чём заключается эта роль?

Таймкод: 00:00:28

Ответ собеседника: Правильный. IT-бизнес-партнёр — это роль, обеспечивающая доставку бизнес-ценности. Управляет потоком разработки, архитектурой. Является единой точкой входа для бизнеса по всем IT-вопросам. В разных компаниях эту роль называют по-разному: CTO, руководитель разработки для бизнеса. Также руководит командой архитекторов.

Правильный ответ:

IT-бизнес-партнёр (IT Business Partner) — это роль, которая выступает связующим звеном между бизнесом и IT-отделом. Основная задача — обеспечение доставки бизнес-ценности через технологические решения.

Ключевые обязанности:

• Стратегическое партнёрство: Участие в формировании бизнес-стратегии с точки зрения технологических возможностей и ограничений
• Управление потоком разработки: Приоритизация задач, управление бэклогом, обеспечение эффективной доставки фич
• Архитектурное руководство: Определение технического направления, контроль качества архитектурных решений
• Единая точка входа: Бизнес обращается к IT-бизнес-партнёру по всем вопросам, связанным с разработкой
• Управление командой: Руководство командой архитекторов и разработчиков

В зависимости от компании эту роль могут называть: CTO, руководитель разработки для бизнеса, Head of Engineering, VP of Engineering.

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

Вопрос 2. Как организована IT-структура компании: размер, количество команд и распределение архитекторов?

Таймкод: 00:02:30

Ответ собеседника: Правильный. В IT около 400 человек, 22 команды, 13 архитекторов. Архитекторы распределены по бизнес-доменам, а не по стеку. Некоторые мелкие команды сгруппированы под одним архитектором — один архитектор занимается двумя-тремя командами. Исключение — внутренние продукты, где один архитектор покрывает разные стеки (1С, C#, PHP).

Правильный ответ:

Организационная структура IT-отдела выглядит следующим образом:

Масштаб:

• Общая численность IT — около 400 человек
• Количество команд — 22
• Количество архитекторов — 13

Принцип распределения архитекторов:

• По бизнес-доменам — основной подход, когда архитектор привязан к конкретному бизнес-направлению, а не к технологическому стеку
• Группировка мелких команд — один архитектор может покрывать 2-3 небольшие команды, работающие в одном домене
• Исключение для внутренних продуктов — здесь один архитектор может покрывать разные технологические стеки (1С, C#, PHP), что обусловлено спецификой внутренних инструментов

Почему распределение по доменам лучше, чем по стеку:

• Архитектор глубоко понимает бизнес-логику своего домена
• Упрощается коммуникация с бизнесом
• Архитектурные решения лучше соответствуют бизнес-потребностям
• Снижается количество контекстных переключений

Вопрос 3. Чем занимается компания Mango Office и какова её стратегия развития?

Таймкод: 00:04:00

Ответ собеседника: Правильный. Компания занимается коммуникациями: голос, текст, видео. Стратегия на ближайшие 5 лет — построить платформу унифицированных коммуникаций, чтобы пользователь мог звонить по видео, получать расшифровку, закидывать в текстовый канал, звонить голосом — всё через одну платформу. Используются LLM-модели, боты для суммаризации разговоров, голосовые роботы. Продукты: контакт-центр, виртуальная АТС, мессенджер.

Правильный ответ:

Mango Office — это компания, специализирующаяся на коммуникационных решениях для бизнеса.

Основные направления:

• Голосовые вызовы
• Текстовые коммуникации
• Видеосвязь

Продуктовая линейка:

• Контакт-центр (CCaaS)
• Виртуальная АТС
• Корпоративный мессенджер

Стратегия на 5 лет: Построение платформы унифицированных коммуникаций (UCaaS), которая объединит все каналы связи в единый продукт.

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

Технологический стек и инновации:

• LLM-модели для обработки естественного языка
• Боты для автоматической суммаризации разговоров
• Голосовые роботы для автоматизации рутинных звонков

Ключевая ценность: Упрощение коммуникаций для бизнеса за счёт интеграции всех каналов связи в единую экосистему.

Вопрос 4. Какие технологические стеки используются в компании?

Таймкод: 00:06:14

Ответ собеседника: Правильный. Основные стеки: C++ (база для телекома, низкоуровневые задачи), PHP (веб), Java, TypeScript/Node.js (бэкенд и фронт). Из фронтовых технологий используют Angular. Также есть Java и немного других технологий.

Правильный ответ:

Технологический стек компании достаточно разнообразен и обусловлен историческим развитием и спецификой продуктов.

Бэкенд:

• C++ — основа телеком-платформы, используется для низкоуровневых задач, обработки голоса и видео в реальном времени
• PHP — веб-приложения и связанная функциональность
• Java — используется в некоторых продуктах и сервисах
• TypeScript/Node.js — бэкенд для современных сервисов

Фронтенд:

• Angular — основной фронтенд-фреймворк

Распределение по доменам:

Выбор технологии зависит от конкретного бизнес-домена и задач:

• Телеком-ядро — C++, так как требуется максимальная производительность и низкая задержка
• Веб-интерфейсы — PHP и Angular
• Новые сервисы — TypeScript/Node.js для более быстрой разработки

Почему такой разнообразный стек:

• Компания развивалась органически, и разные команды выбирали оптимальные инструменты под свои задачи
• Телеком-специфика требует C++ для обработки медиа-потоков
• Разные продукты имеют разные требования к производительности и скорости разработки

Вопрос 5. Есть ли в компании секция System Design на собеседованиях и для каких позиций она применяется?

Таймкод: 00:07:09

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

Правильный ответ:

Да, в компании применяется секция System Design на собеседованиях, но с чётким пониманием, для каких ролей она действительно необходима.

Текущее применение:

• Архитекторы — основная целевая аудитория, System Design является обязательной частью оценки
• Senior-разработчики — рассматривается возможность включения этой секции, так как старшие разработчики должны уметь проектировать компоненты системы

Почему не для всех:

Для мидлов System Design пока не внедряют по нескольким причинам:

• Навык проектирования систем у мидлов ещё в стадии формирования
• Результаты такой секции не дадут объективной картины текущего уровня
• Интервью может демотивировать кандидатов, которые ещё не доросли до этого уровня

Логика подхода:

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

Вопрос 6. Что такое System Design интервью, из чего оно состоит и какова его цель?

Таймкод: 00:08:21

Ответ собеседника: Правильный. System Design интервью позволяет оценить навыки проектирования у разработчиков и не только. При разработке ПО так или иначе занимаешься проектированием: начинающий специалист проектирует маленькие участки кода, классы, функции, а синьор и выше — части систем или целые системы. Эти навыки и оцениваются через System Design интервью. Главный плюс — практически не ограничен в том, куда пойти в рамках интервью. Можно пойти в глубину отдельных элементов системы. Кейсы могут начинаться от низкоуровневых вещей с алгоритмами до высокоуровневых задач вроде «спроектируй Google Docs». Дальше всё зависит от желания интервьюера и задачи на данную вакансию.

Правильный ответ:

System Design интервью — это формат оценки навыков проектирования программных систем различного масштаба.

Цель интервью:

Оценить способность кандидата проектировать системы — от отдельных компонентов до архитектуры целых платформ.

Что оценивается:

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

Спектр задач:

System Design интервью охватывает широкий диапазон задач:

• Низкоуровневое проектирование: Алгоритмы, структуры данных, проектирование отдельных классов и модулей
• Средний уровень: Проектирование отдельных сервисов и компонентов системы
• Высокоуровень: Архитектура распределённых систем, например «спроектируй Google Docs» или «спроектируй систему обмена сообщениями»

Ключевая особенность:

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

Вопрос 7. Когда и почему появился System Design как секция на собеседованиях?

Таймкод: 00:08:28

Ответ собеседника: Правильный. System Design вырос из архитектурной секции для архитекторов и тимлидов. Популяризации способствовали: поиск структурированной оценки кандидатов крупными компаниями, появление микросервисов в 2011 году, смещение архитектуры к распределённым системам. Книги и советы крупных компаний сделали System Design зарегулированным процессом.

Правильный ответ:

System Design как отдельная секция собеседований появился в результате эволюции подходов к найму в технологических компаниях.

Исторический контекст:

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

Причины популяризации:

• Масштабирование найма: Крупные технологические компании столкнулись с необходимостью структурированно оценивать огромное количество кандидатов, отходя от неэффективных каверзных логических вопросов
• Архитектурная революция: В 2011 году появился термин «микросервисы», что привело к фундаментальному сдвигу в архитектуре — от монолитов к распределённым системам
• Новые задачи: Возникли задачи проектирования отдельных сервисов с собственными базами данных, очередями сообщений, механизмами взаимодействия
• Систематизация знаний: Благодаря книгам и публикациям крупных компаний (Designing Data-Intensive Applications и др.) System Design стал стандартизированным процессом с примерным планом прохождения

Итог:

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

Вопрос 8. Что проверяет System Design интервью и какие навыки кандидата являются ключевыми?

Таймкод: 00:13:50

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

Правильный ответ:

System Design интервью проверяет три ключевых аспекта компетенций кандидата.

1. Накопленный инженерный опыт

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

• Понимание распределённых систем и их паттернов
• Опыт работы с реальными системами и их ограничениями
• Знание типичных проблем и способов их решения

Почему это важно: Другие форматы интервью часто сводятся к заучиванию ответов, тогда как System Design позволяет оценить реальный опыт, который невозможно имитировать.

2. Ориентация в дисциплине System Design

Оценивается:

• Знание основных концепций и паттернов проектирования
• Понимание компромиссов между различными архитектурными решениями
• Владение терминологией и 框架ками для описания систем

3. Системное мышление

Это когнитивный навык, который проявляется в:

• Способности структурировать сложную задачу
• Умении отделять главное от второстепенного
• Реакции на подсказки и направляющие вопросы интервьюера
• Инженерном подходе к работе с задачами

Важно: Кандидат должен демонстрировать не только знания, но и процесс мышления — как он приходит к решениям, какие альтернативы рассматривает, какие компромиссы принимает.

Вопрос 9. Можно ли «взломать» System Design интервью, подготовившись заранее?

Таймкод: 00:15:44

Ответ собеседника: Правильный. System Design практически невозможно взломать, можно только подготовиться. Кейсов очень много, нет единственного правильного ответа. Есть паттерны и базовые правила (например, модель C4), знание которых показывает компетентность. Но заранее подготовить ответ тяжело, потому что невозможно угадать, куда поведёт интервьюер.

Правильный ответ:

System Design интервью принципиально отличается от других форматов тем, что его крайне сложно «взломать» простым заучиванием ответов.

Почему невозможно подготовить единственный правильный ответ:

• Множество кейсов: Существует огромное количество возможных задач — от проектирования URL-шортенера до создания системы потокового видео
• Нет единственного правильного решения: Одну и ту же задачу можно решить множеством способов, и каждое решение будет иметь свои плюсы и минусы
• Непредсказуемость направления: Даже если кейс знаком, интервьюер может углубиться в совершенно разные аспекты — производительность, безопасность, масштабирование, отказоустойчивость

Что можно и нужно готовить:

• Паттерны проектирования: Знание типархитектурных решений и их применимости
• Фреймворки описания: Модель C4, диаграммы последовательности, ER-диаграммы
• Базовые принципы: CAP-теорема, модели консистентности, паттерны масштабирования
• Типовые компоненты: Базы данных, очереди сообщений, кэши, балансировщики нагрузки

Ключевой момент:

Подготовка к System Design — это не заучивание ответов, а формирование инженерного мышления и понимания фундаментальных принципов. Именно поэтому опытный интервьюер легко отличит реальное понимание от заученного ответа.

Вопрос 10. Добавляет ли гибкость System Design интервью субъективность в оценку и как с этим бороться?

Таймкод: 00:17:45

Ответ собеседника: Правильный. Любое интервью можно сделать субъективным, всё зависит от интервьюера. Для объективности нужен чек-лист вопросов и результатов, который структурирует сознание интервьюера. Также важно, чтобы результаты интервью проревьюили.

Правильный ответ:

Гибкость System Design интервью действительно создаёт риск субъективности, но этот риск можно и нужно минимизировать.

Источники субъективности:

• Разные интересы интервьюеров: Один может копать в производительность, другой — в безопасность
• Отклонение от опыта кандидата: Если интервьюер углубляется в области, не указанные в резюме кандидата
• Личные предпочтения: Симпатия или антипатия к определённым технологиям или подходам

Как бороться с субъективностью:

• Чек-лист вопросов: Интервьюер приходит на интервью с заранее подготовленным списком вопросов и тем для обсуждения
• Чек-лист результатов: Чёткие критерии оценки, что кандидат должен продемонстрировать
• Структурирование: Чек-лист структурирует сознание интервьюера и убирает субъективность
• Проревью результатов: Результаты интервью должны пересматриваться другими членами команды найма
• Гибкость чек-листа: Чек-лист может включать необязательные пункты и зависеть от конкретного проекта

Важно: Любое интервью потенциально субъективно — всё зависит от интервьюера. Именно поэтому процессуальные меры (чек-листы, проревью) так важны для объективной оценки.

Вопрос 11. С чего начать подготовку к System Design интервью и какие ресурсы рекомендуются?

Таймкод: 00:19:56

Ответ собеседника: Правильный. Рекомендуется начать с книги Алекса Сю «System Design Interview» (две части). Дополнительно — гайды крупных компаний (Т-банк), видео на YouTube с реальными интервью, подкасты с разбором глав книги. На GitHub и Reddit тоже есть полезные материалы. Начинать с литературы, заканчивать статьями и видео.

Правильный ответ:

Подготовка к System Design интервью требует системного подхода и использования разнообразных ресурсов.

Книги:

• Алекс Сю — System Design Interview (Volume 1 и Volume 2) — основной ресурс, дающий базу и понятный скрипт прохождения интервью. Вторая часть написана другими авторами, но продолжает первую
• Designing Data-Intensive Applications Мартина Клеппмана — глубокое погружение в принципы построения распределённых систем

Гайды компаний:

• Т-банк и другие крупные компании публикуют подробные гайды по подготовке, которые дают понимание ожиданий интервьюеров

Видео и подкасты:

• YouTube — записи реальных System Design интервью на конференциях и обучающие ролики
• Подкасты — разбор глав из книги Алекса Сю с экспертами, имеющими реальный опыт

Сообщества:

• GitHub — репозитории с подборками материалов и примерами решений
• Reddit — обсуждения, советы, реальные вопросы с интервью

Рекомендуемый порядок подготовки:

1. Начать с книг для формирования фундамента
2. Изучить гайды компаний для понимания формата
3. Смотреть видео с реальными интервью для понимания динамики
4. Практиковаться на примерах из сообществ

Вопрос 12. Можно ли, готовясь к System Design интервью, научиться по-настоящему проектировать системы?

Таймкод: 00:22:40

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

Правильный ответ:

System Design интервью — это проверка уже имеющегося опыта и глубины инженерного базиса, а не возможность быстро научиться проектировать системы.

Что даёт подготовка:

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

Что подготовка не даёт:

• Реальный опыт проектирования: Невозможно за несколько дней или недель наработать базис, который формируется годами
• Глубокое понимание распределённых систем: Серьёзная литература требует времени на осмысление и применение на практике

Типичная проблема даже для опытных кандидатов:

Даже человек с большим инженерным базисом может допустить ошибки при первом прохождении System Design:

• Не задать достаточно уточняющих вопросов вначале
• Не выяснить полный контекст задачи
• Потеряться в структуре ответа

Вывод:

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

Вопрос 13. Пройдёт ли кандидат с реальным опытом проектирования, но без знания «шаблона» System Design интервью?

Таймкод: 00:25:25

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

Правильный ответ:

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

Факторы, влияющие на успех:

• Свежесть опыта: Если кандидат активно занимался проектированием в последнее время, его знания будут актуальны. Если последние 2 года он не проектировал системы, будет сложнее
• Глубина базиса: Глубокий реальный опыт остаётся в «подкорке» и может компенсировать незнание формата
• Адаптивность: Способность быстро ориентироваться в незнакомом формате

Роль шаблона:

Знание структуры System Design интервью — это ожидание интервьюера. Кандидат должен понимать:

• Как начинать интервью (уточняющие вопросы)
• Как структурировать ответ
• Какие аспекты важно покрыть

Риски без знания шаблона:

• Не задать достаточно вопросов вначале и уйти не в ту сторону
• Не покрыть важные аспекты (масштабирование, отказоустойчивость)
• Потерять структуру ответа и выглядеть менее компетентным, чем есть на самом деле

Вывод:

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

Вопрос 14. Можно ли за час спроектировать систему на собеседовании так же, как в реальной работе, и как стресс влияет на прохождение?

Таймкод: 00:26:24

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

Правильный ответ:

System Design интервью принципиально отличается от реального проектирования систем, и это важно понимать.

Различия с реальной работой:

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

Влияние стресса:

Стресс может серьёзно повлиять на результат даже опытного кандидата:

• Забыть начать с выяснения требований
• Упустить важные аспекты, которые обычно покрываются автоматически
• Потерять структуру ответа
• Неправильно интерпретировать отсутствие информации (если не сказали требования — это не значит, что их нет)

Роль интервьюера:

Интервьюер должен создавать комфортную атмосферу, а не ломать кандидата. Пример из практики: неуважительное поведение интервьюера (унижение, демонстративное пренебрежение) может серьёзно повлиять на результат и запоминается надолго.

Важно понимать:

Цель интервью — не получить идеальный дизайн за час, а оценить, как кандидат думает, какие компромиссы принимает, как структурирует задачу.

Вопрос 15. Топ-4 ошибки кандидатов на System Design интервью

Таймкод: 00:28:21

Ответ собеседника: Правильный. 1) Сразу начинать решать задачу без вопросов. 2) Уходить в детали слишком рано. 3) Не следить за временем. 4) Не слушать интервьюера и пропускать подсказки.

Правильный ответ:

На основе опыта проведения и прохождения System Design интервью можно выделить четыре наиболее распространённые ошибки.

1. Сразу начинать решать задачу

Кандидат сразу рисует квадраты, стрелки, сервисы, не задав ни одного уточняющего вопроса. Это критическая ошибка, потому что:

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

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

2. Уходить в детали слишком рано

Кандидат начинает детально проектировать API, схему базы данных или конкретные алгоритмы, не имея верхнеуровневой картины системы:

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

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

3. Не следить за временем

Кандидат увязает в деталях одного компонента и не успевает завершить дизайн всей системы:

• Интервью ограничено по времени (обычно 45-60 минут)
• Незавершённый дизайн не позволяет оценить полноту мышления
• Важно покрыть все ключевые аспекты, а не углубиться в один

Правильный подход: Следить за таймингом, выделять время на каждый этап.

4. Не слушать интервьюера

Кандидат пропускает подсказки и направляющие сигналы от интервьюера, особенно в состоянии стресса:

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

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

Вопрос 16. Как понять по поведению интервьюера, что System Design проходит успешно или провален?

Таймкод: 00:29:39

Ответ собеседника: Правильный. Явный признак провала — досрочная остановка интервью. Хорошие признаки: отработали весь слот, перешли к низкоуровневым вопросам, интервьюер углубляется в деталь. Вовлечённость интервьюера — признак успеха. Бывают добрые, злые и нейтральные интервьюеры.

Правильный ответ:

Оценка прогресса System Design интервью по поведению интервьюера — важный навык для кандидата.

Признаки провала:

• Досрочная остановка интервью — единственный явный признак провала. Это нарушение этики, но если интервью остановили раньше времени, значит всё плохо

Признаки успеха:

• Отработан весь отведённый слот — интервью прошло полностью по таймингу
• Переход к низкоуровневым вопросам — верхнеуровневый дизайн принят, начинается углубление
• Углубление в конкретную деталь — интервьюер хочет проверить глубину знаний в определённой области
• Вовлечённость интервьюера — если всё идёт хорошо, интервьюер начинает активнее участвовать в обсуждении

Типы интервьюеров:

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

Важно понимать:

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

Вопрос 17. Как готовиться к System Design интервью: каты, менторы, штурм собесов?

Таймкод: 00:32:34

Ответ собеседника: Правильный. Сначала изучить теорию (книги, гайды). Затем практиковаться на катах — задачках на проектирование. Каты доступны в интернете. Наставник всегда лучше. Штурм собесов в компании, куда не хочешь — распространённая, но непростая практика. Каты — более доступный и эффективный способ.

Правильный ответ:

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

Этап 1: Изучение теории

Прежде чем практиковаться, необходимо сформировать теоретическую базу:

• Книги (Алекс Сю, Мартин Клеппман)
• Гайды компаний
• Видео и подкасты

Этап 2: Практика на катах

Каты — это задачки на проектирование, где из требований на входе нужно родить дизайн системы:

• Каты доступны в интернете в свободном доступе
• Можно решать самостоятельно, сравнивая с эталонными решениями
• Это наиболее доступный способ практики

Этап 3: Работа с ментором

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

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

Этап 4: Штурм собесов

Практика прохождения интервью в компаниях, куда не планируешь устраиваться:

• Распространённая практика, но непростая
• Нужно пройти HR-фильтр
• System Design может идти не первым этапом
• Если не возьмут — сложно понять свою вилку и зоны роста

Рекомендация:

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

Вопрос 18. Практика катов — это только навык прохождения собесов или реальное развитие?

Таймкод: 00:34:32

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

Правильный ответ:

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

Что такое ката:

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

Преимущества практики катов:

• Расширение кругозора: Позволяет проектировать системы, которые на работе могут никогда не встретиться — от социальных сетей до систем реального времени
• Выход за пределы отрасли: Опыт проектирования в разных доменах делает инженера более гибким
• Систематизация знаний: Структурирование подходов к проектированию

Форматы практики:

• Самостоятельная практика: Решение кат из открытых источников с последующим сравнением с эталонными решениями
• Парная практика: Существуют площадки, где соединяют двух инженеров — один решает задачу, другой слушает и задаёт вопросы как интервьюер
• Соревнования: Проводятся архитектурные соревнования по катам, где участники соревнуются в качестве проектирования

Вывод:

Практика катов — это логичная и полезная практика, которая развивает реальные навыки проектирования, а не только умение проходить интервью.

Вопрос 19. Должны ли задачи на System Design соответствовать предметной области компании?

Таймкод: 00:35:24

Ответ собеседника: Правильный. Предметная область должна определять задание. Стрёмно просить спроектировать YouTube, если работа — перекладывание JSON-ов. В Mango Office дают задачи, которые реально могут встретиться, но не специфичны для телекома.

Правильный ответ:

Соответствие задач System Design предметной области компании — это вопрос баланса между реалистичностью и оценкой инженерных навыков.

Аргументы за релевантные задачи:

• Справедливость: Стрёмно просить кандидата спроектировать YouTube, если работа будет заключаться в перекладывании JSON-ов из формы в базу
• Мотивация: Кандидат лучше покажет себя на задаче, которая ему понятна и интересна
• Оценка контекста: Можно оценить не только технические навыки, но и понимание бизнес-домена

Подход Mango Office:

• Задачи реально могут встретиться в компании
• При этом они не специфичны для телекома — обычные задачи с распределёнными системами
• Это позволяет оценить инженерные навыки без необходимости глубокого знания специфики домена

Общий принцип:

Задача должна быть:

• Достаточно общей, чтобы не требовать специфических знаний домена
• Достаточно реалистичной, чтобы кандидат мог оценить её применимость
• Сложной, чтобы продемонстрировать навыки проектирования

Вывод:

Предметная область должна влиять на выбор задачи, но задача не должна быть настолько специфичной, чтобы кандидат не мог её решить без опыта работы в конкретной компании или отрасли.

Вопрос 20. Что нужно знать для прохождения System Design интервью?

Таймкод: 00:36:01

Ответ собеседника: Правильный. Базовый набор: HTTP/IP, очереди (вероятность встречи более 50%), реляционные базы данных, NoSQL (key-value типа Redis, документные типа MongoDB). Дальше — принципы распределённых систем: консистентность, алгоритмы консенсуса. Не нужно гнаться за экзотикой — лучше хорошо обосновать простое решение, чем нарисовать «космический корабль» и запутаться.

Правильный ответ:

Для успешного прохождения System Design интервью необходим определённый базовый набор знаний о технологиях и концепциях.

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

• Сети: HTTP/IP — фундамент для понимания взаимодействия компонентов
• Очереди сообщений: Вероятность встречи в задаче более 50% — Kafka, RabbitMQ или аналоги
• Реляционные базы данных: SQL, транзакции, индексы, нормализация
• NoSQL базы данных:
  • Key-value хранилища (Redis)
  • Документные базы (MongoDB)

Принципы распределённых систем:

• Консистентность и CAP-теорема
• Алгоритмы консенсуса (Paxos, Raft)
• Паттерны масштабирования (шардирование, репликация)

Чего НЕ нужно делать:

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

Ключевой принцип:

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

Вопрос 21. Чего ожидать на System Design в хайлоад-компаниях?

Таймкод: 00:39:56

Ответ собеседника: Правильный. В хайлоад-компаниях вероятны задачи на шардирование, репликацию, выбор ключей шардирования. Но System Design — не ноль или единица, а пространство оценки. Если не поговорили про шардирование — это не факт отказа. Структура проекта отличается в зависимости от нагрузки.

Правильный ответ:

System Design интервью в компаниях с высокой нагрузкой имеет свою специфику, но важно понимать контекст.

Чего ожидать в хайлоад-компаниях:

• Шардирование: Вероятно встретятся задачи на горизонтальное разделение данных
• Репликация: Например, настройка репликации в Postgres
• Выбор ключей шардирования: Понимание, как правильно выбрать ключ для распределения данных

Важные нюансы:

• System Design — не бинарная оценка: Это не ноль или единица, а пространство оценки
• Отсутствие темы не означает отказ: Если не поговорили про шардирование — это не факт, что не возьмут
• Другие факторы: Есть и другие интервью, софт-скиллы, и вакансия может не предполагать «Супермена»
• Структура зависит от нагрузки: Архитектурные решения отличаются в зависимости от требований к масштабируемости

Ключевой момент:

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

Вопрос 22. Спускаются ли на System Design интервью до уровня кода?

Таймкод: 00:41:39

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

Правильный ответ:

System Design интервью имеет чёткие границы по уровню детализации, но некоторые аспекты всё же затрагиваются.

Уровень кода:

• Обычно не затрагивается — это отдельное собеседование (Coding Interview)
• Для оценки навыков кода нужен отдельный полноценный этап интервью
• System Design фокусируется на архитектурных решениях, а не на реализации

Схема данных:

• Затрагивается часто — нарисовать схему данных просят регулярно
• Это логичное продолжение проектирования, отражение API и структуры системы
• Схема данных показывает понимание доменной модели

Современные тенденции:

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

Вывод:

System Design интервью остаётся на уровне архитектуры и дизайна, но может включать схему данных как естественное продолжение проектирования. Уровень кода — это отдельное интервью.

Вопрос 23. Верит ли спикер в System Design как единственный формат собеседования?

Таймкод: 00:43:03

Ответ собеседника: Правильный. Спикер не верит в System Design как единственный собес — это иллюзия. Для синьор-разработчика нужен отдельный собес для кода. Даже для архитекторов не ограничиваются только дизайн-интервью. Спикер верит в совокупность собесов: теория, System Design, фит-интервью. Оптимально — 2-3 собеса. Пример с 11 собесами в бигтехе — это тумач.

Правильный ответ:

System Design интервью — важный, но не единственный инструмент оценки кандидата. Использовать его как единственный формат — ошибка.

Почему System Design не может быть единственным интервью:

• Иллюзия полноты: Невозможно понять всё о человеке на одном собеседовании
• Разные навыки: Для позиции, где нужно писать код, необходима отдельная проверка кодовых навыков
• Разные аспекты: Даже для архитекторов не ограничиваются только дизайн-интервью

Оптимальный формат — совокупность интервью:

• Теоретическое интервью: Проверка базовых знаний и понимания технологий
• System Design: Оценка навыков проектирования и архитектурного мышления
• Фит-интервью: Понимание того, как человек мыслит, зачем хочет работать в компании, сможет ли работать в данной атмосфере
• Код-интервью (при необходимости): Проверка навыков написания кода

Рекомендуемое количество: Оптимально — 2-3 интервью. Пример с 11 собеседованиями в одном бигтехе — это чрезмерная нагрузка на кандидата и неэффективное использование ресурсов компании.

Ключевой принцип:

Каждое интервью должно проверять определённый аспект компетенций, и только совокупность результатов даёт полную картину о кандидате.

Вопрос 24. Как использование AI влияет на прохождение собеседований и на профессию программиста?

Таймкод: 00:45:51

Ответ собеседника: Правильный. Многие считают использование AI на собесах читингом, но умение пользоваться AI — признак мастера промптов. Правильно использовать AI можно только при понимании системы. 50% работы руководителя уже автоматизировано через ChatGPT. Cursor может написать API, но возвращать лишние данные — нужно знать, чтобы контролировать. Профессия программиста меняется: от кодера к инженеру, который говорит, что делать.

Правильный ответ:

Использование AI-инструментов трансформирует как процесс собеседований, так и саму профессию программиста.

AI на собеседованиях:

• Двойственное восприятие: Многие считают использование AI на собесах читингом, но есть мнение, что умение пользоваться AI — это признак мастера промптов
• Условие эффективного использования: Правильно использовать AI можно только при понимании, как строится система и что от неё ждать

Практические примеры использования AI:

• ChatGPT: Процентов 50 работы руководителя уже автоматизировано через ChatGPT
• Cursor и аналоги: Могут написать API, но возвращать лишние данные, не соответствующие правилам безопасности — нужно знать, чтобы это контролировать

Трансформация профессии:

• Эволюция: Профессия программиста будет меняться так же, как последние 10 лет
• От кодера к инженеру: Инженер руками практически не кодит, а говорит, что делать
• Профессия кодера исчезла: Тот, кто просто пишет код, уже не востребован
• Профессия инженера преобразуется: Фокус смещается на проектирование и архитектуру

Будущее собеседований:

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

Вопрос 25. Какие три книги должен прочитать каждый IT-специалист?

Таймкод: 00:51:09

Ответ собеседника: Правильный. 1) «Clean Code» Роберта Мартина — про базу дизайна кода. 2) Книга по дизайну — паттерны («Банда четырёх» или другие). 3) «Designing Data-Intensive Applications» (книга с кабанчиком) — продвинутый уровень, распределённые системы. Порядок: база, дизайн, продвинутый уровень.

Правильный ответ:

Существует три книги, которые формируют фундамент для роста IT-специалиста от программиста до инженера.

1. «Clean Code» Роберта Мартина

• Тема: Базовые принципы дизайна кода
• Зачем: Учит писать чистый, читаемый, поддерживаемый код
• Уровень: Базовый — с этого начинается путь к инженерному мышлению

2. Книга по паттернам проектирования

• Классика: «Design Patterns: Elements of Reusable Object-Oriented Software» («Банда четырёх»)
• Современные альтернативы: Множество других книг по паттернам
• Зачем: Даёт словарь и инструменты для проектирования систем, возможность развиться из программиста в инженера/стаф-роль

3. «Designing Data-Intensive Applications» Мартина Клеппмана

• Тема: Продвинутый уровень, погружение в мир распределённых систем
• Прозвище: «Книга с кабанчиком» (по обложке)
• Зачем: Глубокое понимание принципов построения распределённых систем, хранения данных, масштабирования

Логика порядка:

Сначала база (Clean Code), затем дизайн (паттерны), потом продвинутая работа с распределёнными системами. Этот путь позволяет последовательно наращивать компетенции и переходить от написания кода к проектированию систем.

Вопрос 26. Как бы вы охарактеризовали IT-сферу одним словом и почему?

Таймкод: 00:52:47

Ответ собеседника: Правильный. «Созидание». Инженеры из воздуха делают вещи. Раньше из воздуха делали вещи художники, поэты, а теперь — инженеры. Это вдохновляет.

Правильный ответ:

Одно слово, которое лучше всего характеризует IT-сферу — «Созидание».

Почему это слово:

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

Что это значит для профессии:

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