Транспорт бэкенда
Транспорт на FAANG интервью
Два кандидата в Google. Первый выдаёт идеальную Kafka архитектуру за 2 минуты без вопросов. Второй тратит 5 минут на уточнения: 'какой consistency level нужен? какой бюджет на latency?', затем предлагает решение проще. Нанимают второго. Потому что первый демонстрирует memorization, второй - engineering judgment.
- **Stripe L6 интервью**: кандидаты оцениваются по 'trade-off clarity' - умению объяснить не только что выбрано, но почему НЕ выбрана альтернатива. 'Kafka потому что надёжный' - fail. 'Kafka для replay и fan-out, RabbitMQ был бы лучше если бы нам не нужен был replay' - pass
- **Meta E5 System Design**: используют RADIO framework (Requirements, API, Infrastructure, Data, Optimization). Кандидаты которые тратят > 15 мин на любой раздел - red flag: не умеют управлять временем интервью
- **Discord**: сервис с 8M concurrent WebSocket connections строился командой из 5 инженеров на Elixir/Erlang. На интервью важнее показать что знаешь trade-offs (почему Elixir, не Node.js?) чем демонстрировать решения Google scale
Common Questions
System design интервью в Uber/Meta/Google неизменно включают вопросы на выбор транспорта. Типичные формулировки: 'Спроектируй notification system для 1B пользователей', 'Как бы ты реализовал real-time chat', 'Почему Uber использует Kafka вместо REST для trip events'. Интервьюер оценивает не правильный ответ, а structured thinking: требования -> constraints -> trade-offs -> decision.
Google L5+ interview tip: интервьюер не ищет конкретный ответ. Он ищет признаки production experience: знаешь ли ты реальные числа (Discord 8M concurrent WS, Kafka 1M msg/s per partition), встречал ли edge cases (что если Redis недоступен при WS fanout), думаешь ли о observability (как ты узнаешь что система работает правильно).
Интервьюер спрашивает: 'Как бы ты масштабировал WebSocket соединения до 10M concurrent?'. Какой ответ демонстрирует senior-level thinking?
Trade-off Framework
Trade-off framework - структурированный способ объяснить решение на интервью. Не 'я выбрал Kafka потому что он лучший', а 'для данных requirements (replay, fan-out, throughput > 100K/s) Kafka оптимален, его цена - операционная сложность и latency P99 в 50-100ms вместо 5ms RabbitMQ, что приемлемо для нашего async use case'.
На Meta System Design интервью используют формат 'RADIO': Requirements, API Design, Infrastructure, Data Model, Optimization. Trade-off discussion встроен в каждый раздел. Типичная ошибка: кандидат называет технологию не объясняя why именно здесь. Интервьюер всегда спросит 'почему не X?' - нужен готовый ответ про alternative и когда X был бы лучше.
Кандидат говорит: 'Я использую gRPC для всех microservice коммуникаций потому что он быстрее REST'. Что не так с этим ответом?
Whiteboard Approach
Whiteboard system design - 45-минутная структурированная дискуссия. Первые 5 минут критичны: уточнить scope, scale, constraints. Ошибка - сразу рисовать boxes и arrows. Типичная 45-минутная структура: 5 мин requirements, 10 мин API + data model, 20 мин high-level + deep dive, 10 мин trade-offs + bottlenecks. Уложиться в эту структуру - признак опыта.
Interviewer signals: если интервьюер начинает задавать leading questions ('А что если у нас 100x больше пользователей?') - это hint что нужно идти глубже в scalability. Если interrupts и переключает тему - хочет breadth, не depth. Правильная реакция со стороны кандидата: 'Хотите чтобы я поглубже рассмотрел этот компонент или перейти к следующему?' - контроль времени важен.
Кандидат на System Design интервью первые 10 минут детально описывает схему базы данных для chat сервиса. Интервьюер не останавливает. Что скорее всего произойдёт к концу интервью?
Red Flags
Red flags на system design интервью - паттерны которые сигнализируют о lack of production experience. Наиболее частые: невозможность назвать реальные числа (latency, throughput), незнание failure modes ('а что если Kafka упадёт?'), отсутствие observability ('как узнать что работает?'), игнорирование security, jumping to solution без requirements.
Uber interview tip от Senior Engineer: 'Мы не ожидаем что кандидат знает все детали Uber инфраструктуры. Мы ожидаем что он знает что НЕ знает, и умеет задавать правильные вопросы.' Фраза кандидата 'здесь я не уверен, моё предположение X потому что Y, можете подтвердить?' - это green flag, не weakness.
Кандидат на вопрос 'как обработать ситуацию если downstream сервис недоступен?' отвечает: 'Добавим retry'. Что интервьюер скорее всего спросит дальше?
Mock Interview
Мини mock interview: 'Спроектируй URL Shortener'. Задача: bit.ly обрабатывает 600M redirects/day. Requirements: создание короткой ссылки, redirect, analytics (click count по timestamp). Non-functional: redirect P99 < 10ms, availability 99.99%, read:write = 100:1.
После mock interview - self-debrief: 1) Уточнил ли все requirements в первые 5 минут? 2) Назвал ли конкретные цифры (не 'много', а 7000/s)? 3) Объяснил ли почему 302 а не 301? 4) Упомянул ли observability? 5) Уложился ли в структуру? Запись себя на видео - эффективный способ найти red flags в собственном ответе.
Правильная архитектура = хорошее интервью
System Design интервью оценивает communication, structured thinking и trade-off analysis. Кандидат с 'неоптимальной' архитектурой который чётко объясняет trade-offs и limitations проходит лучше, чем кандидат с правильной архитектурой без объяснений
Интервьюер не знает future requirements системы. Он оценивает: задаёт ли кандидат правильные вопросы, думает ли о failure modes, может ли защитить свои решения. Engineering judgement важнее memorized solutions
В URL Shortener кандидат выбрал 301 redirect (permanent) вместо 302. Почему это проблема для аналитики?
Итоги
- **Trade-off template**: WHAT + WHY (requirements) + COST (честно о недостатках) + ALTERNATIVE (когда другое решение лучше) + MONITORING - это структура сильного ответа на любой transport question
- **Time management**: 45 мин = 5 requirements + 10 API/data model + 20 high-level/deep dive + 10 trade-offs. Кандидат отвечает за управление временем, а не интервьюер
- **Red flags**: неназванные числа, неизвестные failure modes, отсутствие observability, jumping to solution. Think out loud при затруднении - green flag, молчание - red flag
Связанные темы
Интервью проверяет знания из всего курса в интегрированном виде:
- Decision Matrix — Trade-off framework на интервью - это применение Decision Matrix в реальном времени. 5 измерений (latency, throughput, durability, ordering, coupling) - готовая структура для любого transport question
- System Design: URL Shortener — URL Shortener - один из самых частых вопросов на интервью. Урок содержит полный blueprint: back-of-envelope, API, Redis cache, async analytics через Kafka
- System Design: Real-Time Chat — Chat - второй по частоте вопрос после URL Shortener. WebSocket архитектура, delivery receipts, offline sync из урока - готовый ответ для FAANG интервью
Вопросы для размышления
- Интервьюер предлагает: 'Давай предположим что нам нужно обрабатывать 1000x больше трафика чем ты спроектировал'. Как правильно перестроить архитектуру URL Shortener под 70M redirects/s без потери P99 < 10ms?
- На интервью в Uber кандидат предложил использовать PostgreSQL для хранения trip events (10M trips/day). Интервьюер спросил: 'Почему не Kafka?'. Кандидат не смог объяснить. Как бы ты ответил, включая когда PostgreSQL лучше и когда Kafka лучше для этого use case?
- После 40 минут отличного system design интервью интервьюер спрашивает: 'Как бы ты постепенно мигрировал legacy систему без downtime на эту новую архитектуру?'. У кандидата 5 минут. Что сказать?