EasyТеория11 min

Зачем System Design интервью

Что проверяют на System Design интервью, какие навыки оценивают и почему это важно для Senior+ инженеров

Почему System Design стал стандартом

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

Разница между coding и system design

Аспект Coding Interview System Design Interview
Фокус Алгоритм и структуры данных Архитектура и инфраструктура
Правильных ответов Обычно один оптимальный Множество допустимых
Масштаб Одна функция/класс Целая система
Оценка Корректность + сложность Мышление + trade-offs
Уровень Junior-Senior Senior+

Что проверяют на System Design

1. Способность работать с неопределенностью

Реальные задачи всегда неполные. На интервью вам дают размытое условие, и ваша задача -- уточнить требования.

<?php

declare(strict_types=1);

/**
 * Interview question: "Design a notification system"
 *
 * BAD approach: immediately start drawing boxes
 *
 * GOOD approach: ask clarifying questions first
 */

// Questions to ask:
// 1. What types of notifications? (push, email, SMS, in-app)
// 2. How many users? (1K vs 100M changes everything)
// 3. How many notifications per day?
// 4. Real-time or batched delivery?
// 5. Priority levels? (urgent vs marketing)
// 6. Delivery guarantees? (at-least-once, exactly-once)
// 7. User preferences? (opt-out, channels, schedule)

// After clarifying requirements, define the contract
final readonly class NotificationRequest
{
    /**
     * @param array<string> $channels Delivery channels
     * @param array<string, mixed> $payload Template variables
     */
    public function __construct(
        public string $userId,
        public string $templateId,
        public array $channels,
        public array $payload,
        public Priority $priority = Priority::Normal,
        public ?\DateTimeImmutable $scheduledAt = null,
    ) {}
}

enum Priority: string
{
    case Urgent = 'urgent';     // Password reset, security alerts
    case High = 'high';         // Order confirmation
    case Normal = 'normal';     // Social notifications
    case Low = 'low';           // Marketing, digests
}
### 2. Понимание масштабирования

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

<?php

declare(strict_types=1);

/**
 * Scale analysis example for notification system
 *
 * Small scale (1K users):
 * - Single server, direct DB writes
 * - Synchronous email sending
 * - Simple cron for scheduled notifications
 *
 * Medium scale (1M users):
 * - Message queue for async processing
 * - Read replicas for user preferences
 * - Cache for templates
 *
 * Large scale (100M users):
 * - Partitioned queues by priority
 * - Sharded user data
 * - Rate limiting per channel
 * - Dedicated infrastructure per channel
 */

// Small scale: simple and direct
final class SimpleNotificationSender
{
    public function __construct(
        private readonly MailerInterface $mailer,
        private readonly \PDO $db,
    ) {}

    public function send(string $userId, string $message): void
    {
        $stmt = $this->db->prepare('SELECT email FROM users WHERE id = :id');
        $stmt->execute(['id' => $userId]);
        $email = $stmt->fetchColumn();

        $this->mailer->send($email, $message);
    }
}

// Large scale: queue-based with priority routing
final class ScalableNotificationSender
{
    public function __construct(
        private readonly MessageProducer $queue,
        private readonly UserPreferenceCache $preferences,
        private readonly RateLimiter $rateLimiter,
    ) {}

    public function send(NotificationRequest $request): void
    {
        // Check user preferences before even queuing
        $prefs = $this->preferences->get($request->userId);
        if (!$prefs->isChannelEnabled($request->channels)) {
            return;
        }

        // Rate limit check per user
        if (!$this->rateLimiter->isAllowed($request->userId)) {
            // Queue for later delivery
            $request = $request->withDelay(seconds: 60);
        }

        // Route to priority-specific queue
        $queueName = match ($request->priority) {
            Priority::Urgent => 'notifications.urgent',
            Priority::High => 'notifications.high',
            Priority::Normal => 'notifications.normal',
            Priority::Low => 'notifications.low',
        };

        $this->queue->publish($queueName, $request);
    }
}
### 3. Знание trade-offs

Каждое архитектурное решение -- это компромисс. Интервьюер ищет способность осознанно выбирать и обосновывать выбор.

Типичные trade-offs:

Решение A Решение B Trade-off
SQL (PostgreSQL) NoSQL (MongoDB) Консистентность vs гибкость схемы
Синхронная обработка Очередь сообщений Простота vs масштабируемость
Монолит Микросервисы Скорость разработки vs независимость деплоя
Push-модель Pull-модель Актуальность vs нагрузка на сервер
Кэширование Прямые запросы Скорость vs свежесть данных

4. Навыки коммуникации

System Design интервью -- это диалог, а не монолог. Интервьюер оценивает:

  • Структурированность -- есть ли у вас план, или вы мечетесь между темами
  • Ясность -- можете ли вы объяснить сложные концепции простыми словами
  • Восприимчивость -- слышите ли вы подсказки интервьюера
  • Обоснованность -- можете ли вы аргументировать свои решения

5. Практический опыт

Интервьюер различает теоретические знания и реальный опыт. Кандидат с опытом:

  • Упоминает конкретные проблемы, с которыми сталкивался
  • Знает подводные камни, которых нет в учебниках
  • Описывает, как решения менялись со временем
  • Понимает операционные аспекты (мониторинг, деплой, дебаг)

Какие навыки оценивают

Матрица оценки

<?php

declare(strict_types=1);

/**
 * System Design evaluation matrix
 * Typical scoring rubric used by interviewers
 */

final class InterviewEvaluation
{
    // Scored from 1 (poor) to 5 (exceptional)

    /** Requirements gathering and scoping */
    public int $problemExploration;

    /** Quality of high-level architecture */
    public int $highLevelDesign;

    /** Depth in critical components */
    public int $detailedDesign;

    /** Understanding of trade-offs */
    public int $tradeoffAnalysis;

    /** Knowledge of scaling patterns */
    public int $scalability;

    /** Communication and structure */
    public int $communication;

    /**
     * Scoring guide:
     *
     * 1 - Cannot discuss the topic
     * 2 - Surface-level understanding, major gaps
     * 3 - Solid understanding, some gaps
     * 4 - Deep understanding, discusses alternatives
     * 5 - Expert level, anticipates issues proactively
     */

    public function getOverallScore(): float
    {
        $weights = [
            'problemExploration' => 0.15,
            'highLevelDesign' => 0.20,
            'detailedDesign' => 0.25,
            'tradeoffAnalysis' => 0.20,
            'scalability' => 0.10,
            'communication' => 0.10,
        ];

        $total = 0;
        foreach ($weights as $field => $weight) {
            $total += $this->{$field} * $weight;
        }

        return round($total, 2);
    }
}
## Распространенные ошибки

1. Прыгать к решению без уточнения требований

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

2. Фокусироваться только на happy path

Реальные системы ломаются. Интервьюер хочет услышать:

  • Что происходит при сбое компонента?
  • Как обрабатываются дубликаты?
  • Что если данные повреждены?

3. Использовать модные слова без понимания

"Давайте добавим Kafka" -- а зачем? "Нам нужен Kubernetes" -- для 100 запросов в минуту? Каждая технология должна быть обоснована.

4. Игнорировать нефункциональные требования

  • Задержка (latency)
  • Доступность (availability)
  • Пропускная способность (throughput)
  • Стоимость (cost)
  • Операционная сложность (operational complexity)

5. Не управлять временем

45 минут пролетают быстро. Если потратить 20 минут на один компонент, на остальные не хватит времени.

Как System Design отличается от реальной работы

Интервью Реальная работа
45 минут Недели/месяцы
Один человек Команда
Whiteboard/бумага Код + инфраструктура
Широкий обзор Глубокая детализация
Устная коммуникация Документация + код
Нет legacy Много legacy

Ключевое: На интервью оценивается ваше мышление и подход, а не идеальный финальный результат. Процесс важнее ответа.

Выводы

System Design интервью -- это проверка вашей способности проектировать реальные системы. Оно оценивает не запоминание паттернов, а умение думать, коммуницировать и принимать обоснованные решения в условиях неопределенности.

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