6 ошибок на System Design собесе, из-за которых тебе не дадут оффер

System Design — самый непредсказуемый этап собеседования. Ни один другой раунд не имеет такого разрыва между «я всё знаю» и «я не получил оффер». Кандидаты проваливают его чаще любого другого технического этапа — не потому что не знают технологии, а потому что допускают одни и те же структурные ошибки.

1. Сразу бросаешься рисовать диаграммы

Ошибка: Услышал «спроектируй URL shortener» — и через 10 секунд уже рисуешь базу данных, кэш, балансировщик. Не задал ни одного вопроса.

Почему это провал: Интервьюер видит, что ты проектируешь в вакууме. Сколько пользователей? Какая нагрузка? Нужна ли аналитика кликов? Без ответов любая архитектура — угадайка. В реальной работе никто не проектирует систему без ТЗ. На собесе от тебя ждут того же.

Как надо: Первые 3–5 минут — только вопросы. Сколько пользователей? Какой RPS? Нужна ли высокая доступность? Какие SLA? Запиши ответы — они станут фундаментом для каждого решения дальше.

2. Называешь технологии, но не объясняешь «почему»

Ошибка: «Возьмём Kafka для обработки событий, Redis для кэша, PostgreSQL для хранения». Интервьюер спрашивает: «Почему Kafka?» — и ты отвечаешь: «Ну, она масштабируемая».

Почему это провал: Это ответ уровня «прочитал описание на сайте». Интервьюер хочет увидеть trade-off analysis. Почему не RabbitMQ? Почему не простая очередь на Redis? При 1000 пользователях Kafka — это как нанять грузовик, чтобы отвезти пакет молока.

Как надо: Каждый выбор — это «Я выбрал X, потому что [требование]. Альтернатива Y не подходит, потому что [ограничение]». Два предложения. Никакой лекции.

3. Собрал требования — и забыл про них

Ошибка: Ты молодец, задал вопросы в начале. Узнал: RPS — 10 000, данных — 500 TB, latency — 100ms. А потом проектируешь систему, ни разу не ссылаясь на эти числа.

Почему это провал: Требования — не ритуал для галочки. Если RPS — 10 000, это должно повлиять на выбор базы данных, стратегию кэширования, количество реплик. Если цифры не появляются в решениях — интервьюер видит, что ты задавал вопросы механически.

Как надо: Привязывай каждое решение к конкретному числу. «При 10 000 RPS одна нода PostgreSQL не выдержит — добавлю read-реплики и кэш перед базой». Это мышление инженера, а не декоратора диаграмм.

4. Пытаешься нарисовать «идеальную» систему с первого раза

Ошибка: Сразу проектируешь на миллиард пользователей: шардирование, CDN, event sourcing, три уровня кэширования. На 10-й минуте на доске — хаос, который ты сам не можешь объяснить.

Почему это провал: System Design — не тест «кто знает больше buzzwords». Интервьюер хочет видеть эволюцию: простое решение → bottleneck → масштабирование. Если стартуешь с финального варианта — ты не показываешь процесс мышления. А именно за него ставят оценку.

Как надо: Начни с MVP. Один сервер, одна база, один кэш. Потом: «Вот узкое место. Вот как я его решу». Масштабируй итеративно — ровно так проектируют системы в реальности.

5. Молчишь по 3 минуты, пока «думаешь»

Ошибка: Интервьюер задал follow-up — и ты замолчал, рисуя что-то в голове. Через три минуты выдал готовое решение.

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

Как надо: Думай вслух. «Здесь bottleneck на записи. Два варианта: шардирование или append-only storage. Первый проще, но потребует consistent hashing...» Даже если не уверен — озвучивай. Это показывает, как ты принимаешь решения.

6. Не считаешь числа

Ошибка: Говоришь «нам нужен кэш», но не можешь посчитать, сколько памяти он займёт. Говоришь «шардируем базу», но не знаешь на сколько шардов. Все решения — на уровне ощущений.

Почему это провал: Back-of-the-envelope calculations — отдельный навык, который проверяют целенаправленно. 100 млн пользователей × 1 KB на запись = 100 GB. Помещается в одну ноду? Да. Значит шардирование пока не нужно. Без цифр ты не можешь доказать, что архитектура выдержит.

Как надо: Считай на ходу. Прикинь объём данных, throughput, latency. Не нужна точность до байта — нужен порядок величин. «100 млн записей × 500 байт ≈ 50 GB — укладывается в одну ноду с SSD». Три секунды — и ты уже выглядишь как человек, который проектировал реальные системы.

Что объединяет все 6 ошибок

Ни одна — не про незнание технологий. Все — про процесс. System Design собес проверяет не то, сколько ты прочитал про Kafka, а то, как ты думаешь, когда нет готового ответа.

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

Потренировать это можно с Sobes AI — он задаёт задачу, слушает твою архитектуру, задаёт follow-up и указывает на пропущенные bottleneck'и. Как настоящий интервьюер, только без стресса и с разбором после.