Провал на System Design интервью редко упирается в пробелы в знаниях. Кандидат знает, что такое кэш, уверенно объясняет шардирование, пять раз смотрел разбор «спроектируйте Twitter». Отказ всё равно приходит — из-за того, как он распоряжается 45 минутами.
Интервьюер оценивает короткий список сигналов. Сузили ли вы расплывчатую задачу? Выбрали решение и защитили его? Нашли слабое место в собственной схеме? Ведёте разговор или читаете доклад? Семь ошибок ниже ломают ровно эти сигналы. К каждой — пара ответов, слабый и сильный, чтобы услышать разницу.
1. Рисовать схему раньше вопросов
Задача: «Спроектируйте ленту новостей». Кандидат хватает маркер и выводит балансировщик нагрузки. Выглядит продуктивно. Только лента на 500 друзей и лента на 50 миллионов подписчиков — два разных проекта, а какой именно нужен, пока неизвестно.
Слабо: «Итак, у нас будут клиенты, балансировщик и несколько серверов приложений…»
Сильно: «Прежде чем что-то рисовать, несколько вопросов. Это лента друзей или подписки со знаменитостями? Ранжирование или хронология? Насколько свежими должны быть данные? Сколько примерно активных пользователей в день?»
Хороший подрядчик спросит, сколько человек будет жить в доме, до того как заливать фундамент. Первые пять минут разговора уходят на вопросы, а ответы вы записываете на доске — потом будете на них ссылаться.
2. Посчитать нагрузку и больше о ней не вспоминать
Многие научились считать по конверту. Получают 12 000 записей в секунду — и ни разу не упоминают это число дальше. Оценка не ритуал, а аргумент: каждое число должно менять проектное решение.
Слабо: «Получается около 12K записей в секунду. Ок, переходим к API».
Сильно: «12K записей в секунду — больше, чем я хотел бы видеть на одном Postgres primary для такой нагрузки. Поэтому партиционирую по user ID сразу и держу путь записи тонким».
Если число не поменяло схему, считать его было незачем.
3. Перечислять инструменты вместо решений
«Возьмём Kafka». «Поставим Redis спереди». «Cassandra, она хорошо масштабируется». Название инструмента — не проектное решение. Интервьюер хочет услышать, какую задачу вы закрываете и чем за это платите.
Слабо: «Поставим Kafka между сервисами».
Сильно: «Загрузка файла и создание превью не обязаны завершаться одновременно. Ставлю между ними очередь, чтобы медленный джоб с превью не блокировал загрузку. Плата — превью появится на несколько секунд позже, и здесь это нормально».
Простой тест: про каждый компонент скажите одно предложение о том, зачем он тут, и одно — про его цену. Не можете сформулировать второе — выбор ещё не понят.
4. Проектировать только happy path
Схема идеально работает, пока ничего не ломается. В продакшене что-то ломается постоянно, и вопрос «а если этот узел умрёт?» ставит часть кандидатов в тупик.
Слабо: «Сервис оплаты вызывает банк, потом помечает заказ оплаченным».
Сильно: «Если вызов банка упал по таймауту, мы не знаем, прошёл ли платёж. Поэтому каждый платёж несёт idempotency key. При повторе банк вернёт исходный результат, а не спишет деньги дважды».
Закрывать все возможные отказы не нужно. Возьмите два самых болезненных для пользователя и разберите их как следует — этого уже хватит, чтобы обогнать большинство.
5. Уходить в глубину не туда
Кандидат тратит 20 минут на индексы в базе сокращателя ссылок, а время заканчивается раньше, чем он доходит до редиректа, через который идёт 99% трафика. Глубина — это хорошо. Глубина не в том месте — утечка времени.
Слабо: долгая экскурсия по внутренностям B-tree, пока основной поток ещё не описан.
Сильно: «Самое интересное здесь — путь чтения, потому что чтений в 100 раз больше, чем записей. Хочу углубиться в кэширование редиректов. Так正常 — или вы предпочли бы другую область?»
Сначала соберите простую схему целиком, от начала до конца. И только потом ныряйте. Доделанный простой дизайн выигрывает у недоделанного умного.
6. Монолог
Кандидат говорит 30 минут подряд. Интервьюер дважды пытается его развернуть — тот не замечает. System design интервью устроено как совместная работа: интервьюер часто подкидывает подсказки, куда копать. Не слушаете — пропускаете их.
Короткие проверки на естественных паузах работают лучше: «Вот поток на высоком уровне. Прежде чем углубляться, на чём хотите, чтобы я сосредоточился?» Это парное программирование, а не лекция.
7. Одна модель консистентности на всю систему
Часто выбирают либо strong, либо eventual consistency целиком. Реальные системы смешивают оба подхода — и умение разложить данные по тому, сколько устаревания они терпят, читается как один из самых явных признаков senior-уровня.
| Тип данных | Модель | Как это объяснить |
|---|---|---|
| Лайки, счётчики просмотров | Eventual consistency | Пара секунд расхождения никого не смутит; считаем батчами через counter service |
| Заказы и записи о платежах | Strong consistency | Уходят в реляционную базу с транзакциями |
| Баланс на счёте | Strong consistency | Устаревшее значение означает потерянные или лишние деньги |
| Бронь места | Strong consistency | Двое не могут занять одно и то же место |
Чек-лист перед прогоном
- Задать 4–6 уточняющих вопросов и записать ответы на доске. Больше — превращается в допрос интервьюера.
- Проверить, что каждая цифра из оценки нагрузки поменяла хотя бы одно решение.
- Проговорить для каждого компонента причину и цену.
- Разобрать два самых болезненных отказа, для повторов — idempotency key.
- Собрать простой сквозной дизайн, потом углубляться там, где сосредоточена нагрузка.
- Делать короткий check-in на паузах.
- Раздать разным типам данных свою модель консистентности.
Частые вопросы
Стоит ли заучивать типовые схемы?
Изучать — да, заучивать финальные диаграммы — нет. Интервьюер меняет одно требование, и выученный ответ рассыпается. Полезнее разобраться, почему в схеме приняты именно такие решения.
Что делать, если не знаю технологию, о которой спросил интервьюер?
Сказать прямо и рассуждать от первых принципов: «Не работал с этим, но если это очередь на основе лога, я ожидаю вот таких свойств». Честное рассуждение ценится выше блефа.
Плохо ли менять дизайн по ходу интервью?
Наоборот. Заметить дырку в своей же схеме и починить её — сильный сигнал. Проговорите, что меняете и почему.
Как тренировать коммуникативную часть?
Таймированные mock-интервью вслух. Нет партнёра — включите таймер на 45 минут, запишите себя и посмотрите запись. Монологи становятся слышны сразу.
Все семь ошибок про одно: про управление временем и разговором. Диаграммы можно подсмотреть, умение выбрать решение и назвать его цену — нет. Начните с двух-трёх прогонов вслух под таймер: они покажут, где именно вы теряете минуты.
Fluxs
Комментарии (0)
Войдите, чтобы комментировать.
Пока нет комментариев. Будьте первым.