SQL-собеседование без паники: что реально спрашивают и где валятся даже сильные

На SQL-собеседованиях интервьюер часто формулирует условия устно, просит рассуждать вслух и быстро писать запрос в реальном времени. Это непривычный формат — и именно поэтому он становится испытанием даже для тех, кто много практиковался.

Привет! Меня зовут Дмитрий, я data engineer и автор курсов на Stepik по подготовке к SQL-интервью. Больше года веду блог про Data Engineering, а в 2025 году много ходил по собеседованиям и собрал повторяющиеся паттерны: что спрашивают, где чаще всего ошибаются и что интервьюер реально оценивает.

Недавно был номинирован на Stepik Awards 2025 в категории 🧩Лучшая система практических заданий. В этот раз не забрал награду, но для меня это уже большая честь, что позвали на сцену.

Как обычно устроено SQL-интервью

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

Чаще всего всё начинается довольно спокойно: интервьюер уточняет ваш опыт, пару слов о проектах, чтобы понимать, на каком уровне держать планку вопросов. И уже после этого предлагает пройти короткий «разогрев» на теории.

1. Скрининг (10–20 минут)

Первая короткая сессия чаще всего проходит с HR-специалистом или джун-интервьюером, который проверяет базовую теорию.Это  5–10 быстрых вопросов, на которые нужно ответить без долгих раздумий. Типовые формулировки могут б��ть такими:

• «Левая таблица — 10 строк, правая — 5. Какое минимальное и максимальное число строк может получиться при разных JOIN?»

• «Чем отличаются WHERE и HAVING?»

• «Когда уместнее DISTINCT, а когда — GROUP BY?»

• «В чём разница между JOIN и EXISTS?»

• «Что произойдёт, если фильтр из ON перенести в WHERE, особенно в LEFT JOIN?»

На этом этапе важна не зубрёжка терминов, а то, насколько уверенно вы объясняете базовую логику. Если тут много пауз и сомнений, до задач иногда просто не доходят — так устроен этап отбора, не более.

2. Практическая часть (30–60 минут)

Если с теорией всё в порядке, переходят к задачам. Обычно дают 2–3 задачи:от простых к более объёмным.

Частая последовательность такая:

• первая задача — на SELF JOIN или базовые агрегации;

• следующие — на оконные функции (ROW_NUMBER, RANK, фреймы, работа с периодами и датами).

Формулировки чаще всего идут в духе: «Вот таблицы, вот вопрос аналитика — получите нужную выборку и объясните, что вы делаете и почему».

Здесь интервьюер смотрит не только на финальный код. Гораздо важнее, как вы рассуждаете: уточняете ли данные, комментируете ли шаги, видите ли крайние случаи. И да, нервничать абсолютно нормально. Никто не ждёт знания всего синтаксиса наизусть, но умение мыслить вслух и аккуратно проверять гипотезы ценится очень высоко.

Мини - кейсы

A: фильтрация

Это один из самых популярных примеров на собеседованиях, в нём быстро видно, понимает ли кандидат, как фильтрация влияет на тип JOIN. Формулировка обычно звучит довольно просто. 

Задача: вернуть всех клиентов и сумму их оплаченных транзакций. Если оплат не было — сумма должна быть 0.

Дальше интервьюеры смотрят, куда именно кандидат ставит фильтр по статусу транзакции.

Вот корректный подход — фильтровать оплаченные транзакции прямо в ON, чтобы не потерять клиентов без оплат:

SELECT c.client_id,
       COALESCE(SUM(t.amount), 0) AS total_paid
FROM clients c
LEFT JOIN transactions t
  ON t.client_id = c.client_id
 AND t.status = 'paid'
GROUP BY c.client_id;

Если же вынести фильтр в WHERE, логика ломается — LEFT JOIN по сути превращается в INNER JOIN, и строки клиентов без оплат исчезнут:

SELECT c.client_id,
       COALESCE(SUM(t.amount), 0) AS total_paid
FROM clients c
LEFT JOIN transactions t
  ON t.client_id = c.client_id
WHERE t.status = 'paid'
GROUP BY c.client_id;

Какие уточняющие вопросы часто задают после решения.

1. Как вывести только клиентов без оплат?

2. Почему здесь нужен COALESCE?

3. Что с производительностью?

B: окна — последняя транзакция и сумма по последним трём

Задачи на оконные функции — довольно частые вещи. Обычно интервьюеры не просто хотят увидеть знание ROW_NUMBER или агрегатов по окну, а смотрят, понимает ли кандидат логику: что значит «последние», по какому признаку мы сортируем и как выбираем нужный диапазон.

Один из типичных примеров выглядит так: для каждого клиента нужно определить дату последней транзакции и сумму трёх последних транзакций.

Решение чаще всего строят через ранжирование записей и накопление значений окна:

WITH ranked AS (
  SELECT
    t.client_id,
    t.trx_date,
    t.amount,
    ROW_NUMBER() OVER (PARTITION BY t.client_id ORDER BY t.trx_date DESC) AS rn,
    SUM(t.amount) OVER (
      PARTITION BY t.client_id
      ORDER BY t.trx_date DESC
      ROWS BETWEEN 2 PRECEDING AND CURRENT ROW
    ) AS sum_last3
  FROM transactions t
)
SELECT client_id,
       MAX(CASE WHEN rn = 1 THEN trx_date END)   AS last_trx_date,
       MAX(CASE WHEN rn = 1 THEN sum_last3 END)  AS sum_last3_trx
FROM ranked
GROUP BY client_id;

Как готовиться и не сгореть

Хорошая подготовка к SQL-собеседованию — это не перечитывание статей, а регулярная практика. Теорию можно пролистать за вечер, но когда вы видите задачу «вживую», часто оказывается, что проверить гипотезу негде, данных мало, а времени — ещё меньше. Именно поэтому чтение полезно, но без практики легко впасть в ступор.

Немного ностальгии по университету.

Один из рабочих подходов — условный режим «Бауманки», когда сначала даётся задача, и у вас есть время разобраться с ней любым удобным способом. Можно открыть документацию, поискать примеры, свериться с учебником — важно не угадать синтаксис, а понять сам приём и уметь потом объяснить, почему решение устроено именно так.

Для подготовки помогает небольшой, но стабильный темп: 30–60 минут в день.
Обычно хватает двух задач:

• одна — на агрегации или JOIN,

• вторая — на окна или EXISTS.

Такой режим хорошо тренирует мышление. Проговаривайте ход решения вслух, формулируйте допущения, проверяйте крайние случаи. Чем больше таких микро-репетиций, тем спокойнее чувствуешь себя на реальном собеседовании.

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

Почему я собрал сборники задач на Stepik

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

Внутри — градация от базы до многоэтапных решений с CTE и окнами. И, на мой взгляд, в хорошей задаче полезно иметь:

• ответ-ориентир, чтобы понимать, какой должна быть итоговая выборка;

• подсказки, если застря��и;

• разбор с комментариями и дополнительными вопросами “как от старшего”.

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

Если вам понравился материал — заходите на мой сайт и в блог.
Там я стараюсь регулярно публиковать разборы SQL-задач, ловушки на собеседованиях и тренировочные подборки.