Базы данных
База данных на собеседовании
Инженер с 5 годами опыта провалил собеседование в Amazon: не смог объяснить N+1 проблему и выбор между SQL и NoSQL. Второй кандидат с 2 годами опыта прошёл - потому что умел рассуждать о trade-offs вслух. Базы данных на собеседовании - не тест памяти, а тест инженерного мышления.
- **Google**: system design собеседования всегда включают вопрос 'какую БД используешь и почему' - ожидается trade-off анализ
- **Stripe**: практические вопросы о транзакциях, idempotency и consistency - темы прямо из production payment systems
- **Netflix**: вопросы о data modeling для streaming - как хранить viewing history, recommendations, user preferences при 260M пользователях
Частые вопросы на собеседовании
Вопросы о базах данных на собеседованиях делятся на несколько категорий: концептуальные (что такое ACID, CAP теорема), практические (оптимизация запроса, выбор индекса), design (спроектируй схему для Instagram), и trade-off вопросы (когда использовать NoSQL вместо SQL). Каждый тип требует своего подхода.
По данным Glassdoor и LeetCode, вопросы о базах данных встречаются в 80% backend собеседований. В FAANG часто спрашивают system design с фокусом на выбор хранилища. В mid-size компаниях - практические SQL вопросы и оптимизация.
Интервьюер спрашивает 'Объясни N+1 проблему'. Какой ответ правильный?
Schema Design: пошаговый подход
Schema design задача на собеседовании - спроектируй БД для X. Подход: 1) уточнить требования, 2) определить сущности, 3) нарисовать связи, 4) добавить индексы для key queries, 5) обсудить масштаб и trade-offs. Не молчать - думать вслух, показывать процесс рассуждений.
На собеседовании в Google схема URL shortener часто расширяется до 'как масштабировать до 100B ссылок?' - тут идёт разговор о шардировании по short_code, CDN для hot links, Redis кеш для популярных redirects. Основная схема - только начало разговора.
Почему short_code в URL shortener лучше хранить как CHAR(7) а не INT auto-increment?
Query Optimization: читать EXPLAIN ANALYZE
Задача оптимизации запроса на собеседовании: медленный запрос, нужно найти проблему. Алгоритм: EXPLAIN ANALYZE -> найти Seq Scan на большой таблице -> добавить индекс или переписать запрос -> проверить результат. Знание плана выполнения - базовый навык backend разработчика.
Ключевые термины EXPLAIN ANALYZE: Seq Scan (плохо для больших таблиц), Index Scan (хорошо), Index Only Scan (лучшее - из индекса без heap fetch), Bitmap Heap Scan (компромисс). actual time и rows расхождение с estimates означает устаревшую статистику (ANALYZE нужен).
EXPLAIN ANALYZE показывает Seq Scan on orders (rows=2000000). Что это означает?
Trade-off Framework для ответов
Лучшие ответы на вопросы о базах данных используют trade-off framework: не 'X лучше Y', а 'X лучше для A, B, C; Y лучше для D, E, F'. Интервьюер проверяет не знание ответов, а умение рассуждать о компромиссах в зависимости от контекста.
Сильный ответ на вопрос о производительности всегда включает: 'это нужно измерить в вашем конкретном случае'. Теоретические рассуждения хороши, но интервьюеры в FAANG ценят тех кто понимает что benchmark в вакууме - не ответ на вопрос 'что быстрее'.
Интервьюер спрашивает: 'Что лучше - нормализованная или денормализованная схема?' Какой ответ демонстрирует глубину понимания?
Mock Interview: schema для Instagram
Задача: спроектируй схему базы данных для Instagram. 1 миллиард пользователей, 100 миллионов постов в день, 4 миллиарда лайков в день. Нужно: хранить посты с медиа, подписки, лайки, комментарии, лента пользователя.
Real Instagram (по данным их engineering blog): PostgreSQL для users/posts, Cassandra для activity feed (write-heavy), Redis для counters и session, Elasticsearch для search, S3 для медиа. Схема выше - упрощение для демонстрации рассуждений, не точная копия production.
На собеседовании нужно дать 'правильный' ответ - единственную верную схему или выбор БД
Собеседование по базам данных оценивает процесс рассуждений: умение уточнять требования, обсуждать trade-offs, и объяснять выбор в контексте конкретных требований
В реальной работе нет единственно правильного решения. Instagram, Twitter, LinkedIn - все используют разные схемы для похожих задач. Ценится умение анализировать требования, знать плюсы и минусы каждого подхода, и принимать обоснованные решения.
В схеме Instagram лайки партиционированы по created_at. Почему это важно?
Итоги
- **Trade-off framework** - не 'X лучше Y', а 'X лучше для A и B, Y лучше для C и D' - именно это ценят интервьюеры
- **EXPLAIN ANALYZE** - базовый инструмент: Seq Scan на большой таблице = нет индекса; actual vs estimated rows = устаревшая статистика
- **Schema design** - уточнить требования, нарисовать сущности и связи, добавить индексы для key queries, обсудить масштаб
Связанные темы
Успешное собеседование требует знания всего курса:
- Индексы B-Tree — Чтение EXPLAIN ANALYZE и добавление правильных индексов - самый частый практический вопрос
- ACID транзакции — ACID и уровни изоляции - стандартный концептуальный вопрос в любом backend собеседовании
- Data Modeling — Schema design задачи (Instagram, Twitter, URL shortener) - практическое применение всех принципов моделирования
Вопросы для размышления
- Интервьюер спрашивает: 'Как бы ты реализовал систему лайков которая обрабатывает 1 миллион лайков в секунду?' Какие вопросы нужно уточнить прежде чем отвечать?
- Запрос работает быстро в staging (10K строк) но медленно в production (10M строк). Почему и какой будет план действий?
- Назови 3 вопроса которые ты задашь интервьюеру перед проектированием schema - какие требования критичны для правильного дизайна?