Вопросы на собеседовании SQL в 2026: что спрашивают и как готовиться

Если вы претендуете на позицию в IT, аналитике или даже в product-менеджменте, SQL на собеседовании вам не обойти. В 2026 году это давно не про «напишите SELECT из одной таблицы» — с таким вопросом скорее возьмут стажёра. Планка выросла: от кандидата ждут, что он объяснит, как база работает изнутри, как ускорить запрос и почему одна конструкция обгоняет другую.

Дальше — по группам: что реально спрашивают у аналитиков, разработчиков, QA-инженеров и продактов, с примерами и логикой решений.

JOIN'ы: не только LEFT JOIN

JOIN'ы всплывают на собеседовании чаще всего. Но одной фразы «LEFT JOIN возвращает все строки из левой таблицы» в 2026 году мало — интервьюер ждёт, что вы покажете понимание:

• разница между INNER и OUTER (LEFT, RIGHT, FULL) — с примерами, когда что использовать;
• CROSS JOIN — в каких кейсах (например, генерация всех комбинаций дат и продуктов);
• SELF JOIN — типичная задача «найти сотрудников с зарплатой выше среднего по отделу»;
• JOIN без ключа — что будет (декартово произведение), как избежать.

Пример задачи: «Есть таблицы users (id, name) и orders (id, user_id, amount). Напишите запрос, который выводит всех пользователей и сумму их заказов, включая тех, у кого заказов нет». Решение: SELECT u.name, COALESCE(SUM(o.amount), 0) FROM users u LEFT JOIN orders o ON u.id = o.user_id GROUP BY u.id, u.name — LEFT JOIN оставляет всех пользователей, GROUP BY сворачивает их заказы, а COALESCE подставляет 0 там, где заказов не было.

Спотыкаются обычно на одном и том же: после LEFT JOIN и GROUP BY забывают агрегировать поля из правой таблицы — и тогда NULL-строки повисают необработанными.

Агрегации и GROUP BY: подвохи с HAVING

SUM, COUNT, AVG, MIN, MAX кандидаты обычно знают наизусть — этим на собеседовании никого не удивишь. Вопросы на собеседовании SQL 2026 года заходят дальше:

• разница между COUNT() и COUNT(column) — COUNT() считает строки, COUNT(column) — ненулевые значения;
• HAVING vs WHERE — WHERE фильтрует до агрегации, HAVING — после;
• GROUP BY с несколькими столбцами — порядок влияет на группировку;
• DISTINCT vs GROUP BY — когда что эффективнее.

Пример: «Выведите отделы, где средняя зарплата больше 50000». Решение: SELECT department_id, AVG(salary) FROM employees GROUP BY department_id HAVING AVG(salary) > 50000 — сначала база группирует строки по отделам и только потом фильтрует группы по условию.

Ловят на том, что пробуют поставить WHERE туда, где нужен HAVING, — после GROUP BY это просто синтаксическая ошибка.

Оконные функции: тренд 2026

Без ROW_NUMBER, RANK, DENSE_RANK, LEAD, LAG и SUM OVER на собеседовании сейчас не обойтись — окна спрашивают почти всегда, и у аналитиков, и у разработчиков.

Задача: «Для каждого сотрудника вывести его зарплату и среднюю зарплату по отделу». Решение: SELECT name, salary, AVG(salary) OVER (PARTITION BY department_id) AS avg_dept_salary FROM employees. PARTITION BY режет данные на окна по отделам, а агрегация считается уже внутри каждого окна отдельно.

Второй вариант: «Пронумеровать заказы каждого пользователя по дате (самый новый — 1)». Решение: SELECT user_id, order_date, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY order_date DESC) AS rn FROM orders — ROW_NUMBER просто раздаёт уникальные номера внутри каждого окна.

RANK и DENSE_RANK путают почти всегда: при одинаковых значениях RANK перескакивает через номер, а DENSE_RANK идёт по порядку без пропусков.

Оптимизация запросов: explain, индексы, планы

На senior-позициях в вопросы на собеседовании SQL добавляется оптимизация. Спрашивают обычно вот что:

• как работает EXPLAIN (или EXPLAIN ANALYZE) — чтение плана выполнения;
• типы сканирования: Seq Scan, Index Scan, Index Only Scan — когда что выбирает планировщик;
• когда индекс не работает: функции на столбце, LIKE с ведущим %, неявное преобразование типов;
• разница между B-tree, Hash, GiST индексами (базово);
• как искать медленные запросы — через логи или pg_stat_statements.

Классическая формулировка: «У вас запрос SELECT * FROM orders WHERE order_date > '2025-01-01' AND status = 'completed' работает медленно. Что сделаете?» Правильный ход — сначала посмотреть EXPLAIN, а затем завести композитный индекс на (status, order_date): статус селективнее, и порядок столбцов важен.

Заваливаются на том, что оценивают запрос по одному синтаксису, не заглядывая в то, как он реально выполняется.

Проектирование схем: нормализация и денормализация

Про то, как вы проектируете саму схему данных, тоже спрашивают отдельно — вопросы на собеседовании SQL для разработчиков и аналитиков здесь обычно такие:

• нормальные формы: 1НФ, 2НФ, 3НФ — определение и примеры;
• когда денормализация оправдана (например, для ускорения чтения);
• первичные и внешние ключи, ограничения (NOT NULL, UNIQUE, CHECK);
• типы связей: one-to-one, one-to-many, many-to-many (через промежуточную таблицу).

Задача: «Спроектируйте таблицы для интернет-магазина: товары, категории, заказы». Рабочая схема выглядит так: товары (id, name, price, category_id), категории (id, name), заказы (id, user_id, order_date), позиции заказа (order_id, product_id, quantity).

И почти всегда забывают именно про связь many-to-many между заказами и товарами — про ту самую промежуточную таблицу позиций заказа.

Как готовиться и типичные провалы

Чтобы реально пройти такое собеседование в 2026 году, придётся:

• ежедневно решать задачи на LeetCode (medium), HackerRank, SQLZoo;
• практиковать оконные функции и JOIN'ы на реальных данных;
• уметь объяснять план запроса (EXPLAIN);
• разбирать свои ошибки — вести «дневник провалов».

А вот где ошибаются чаще всего:

• забывают обработать NULL (COALESCE, IS NULL);
• путают ORDER BY и GROUP BY;
• не используют индексы при JOIN'ах;
• пишут подзапросы там, где можно JOIN — это медленнее;
• не знают разницы между UNION и UNION ALL (UNION удаляет дубликаты, UNION ALL — нет).

Готовясь к собеседованиям, отклики на вакансии всё равно приходится рассылать — и здесь есть смысл снять с себя рутину. xt-job.ru автоматизирует отклики на hh.ru прямо через вашу браузерную сессию: бесплатно — до 25 откликов в день, на подписке XTPro — до 50, и каждый идёт с AI-сопроводительным письмом под конкретную вакансию.

Но количество здесь вторично — важнее релевантность. Поиск работы в России в среднем растягивается на месяцы, и именно поэтому каждый отклик стоит делать точечным.

Чек-лист подготовки к SQL-собеседованию

• [ ] Умею объяснять разницу между INNER, LEFT, RIGHT, FULL JOIN на примерах
• [ ] Знаю, как работает GROUP BY + HAVING, могу решить задачу с фильтром после агрегации
• [ ] Пишу оконные функции (ROW_NUMBER, RANK, SUM OVER) без подсказок
• [ ] Могу прочитать EXPLAIN и сказать, где узкое место
• [ ] Понимаю нормальные формы и могу спроектировать простую схему
• [ ] Разбираюсь с индексами: когда они ускоряют, а когда замедляют
• [ ] Решаю 2-3 задачи на LeetCode medium в день
• [ ] Готов объяснить каждый свой запрос: почему выбрал такой JOIN, а не другой

Как устроены остальные этапы собеседования — в статье /blog/sobesedovanie-podgotovka-gajd-2026.

Практика на реальных задачах и разбор собственных ошибок почти всегда работают лучше, чем зубрёжка синтаксиса. За большинством вопросов на собеседовании SQL стоит одно и то же: интервьюеру интересно, как вы рассуждаете о данных: почему выбрали такой JOIN, зачем нужен этот индекс, что случится с NULL, если его не обработать.