Собеседование по SQL и Python: чего ждать и как готовиться

Как проходят собеседования по SQL и Python

Компании комбинируют несколько форматов. От формата зависит, как готовиться, поэтому уточните у рекрутёра заранее: какая СУБД или диалект, можно ли запускать код и смотрит ли кто-то, как вы печатаете.

Типичная цепочка: разговор с рекрутёром, затем онлайн-тест или технический скрининг, потом один-два технических раунда (SQL, иногда Python или кейс) и в конце разговор о команде и опыте. Процессы у компаний сильно различаются, так что считайте это картой, а не обещанием.

Чем различаются роли

Жёстких правил тут нет. На бэкенд-интервью могут попросить оконную функцию, а у аналитика спросить про схему. Основательно готовьте то, что нужно вашей роли, а смежное повторите вскользь.

Что оценивают интервьюеры

Почти любая оценочная карточка сводится к шести пунктам. Верный запрос, который вы не можете объяснить, оценят ниже, чем почти верный, который вы аккуратно построили и проверили вслух.

• Правильность. Результат отвечает на вопрос, включая случаи, которые легко забыть. Верная гранулярность, верные столбцы, верный порядок.
• Крайние случаи. NULL, одинаковые значения, дубликаты, пустые группы, границы дат, «а если у клиента нет заказов?». Назвать их до того, как спросят, один из самых сильных сигналов на уровне junior и middle.
• Коммуникация. Вы пересказываете задачу, задаёте полезные вопросы, проговариваете план и честно говорите, в чём не уверены.
• Структура. Вы строите ответ по шагам (CTE с понятными именами), а не пишете один вложенный запрос на 40 строк, в котором никто не разберётся.
• Понимание производительности. Вы можете сказать, что примерно сделает база, где помог бы индекс и что изменится при данных в сто раз больше. Оптимизировать заранее не нужно.
• Чистота кода. Единые псевдонимы, явные условия соединения, никакого SELECT * в итоговом ответе, одна мысль на один CTE.

Пошаговый метод решения SQL-задачи вживую

Когда идёт время, заранее заученный порядок действий не даёт «зависнуть». Проходите эти пять шагов каждый раз, даже на лёгких задачах, пока они не станут привычкой.

1. Уточните вопросСпрашивайте до того, как начнёте печатать. Как минимум выясните: гранулярность (одна строка — это что?), NULL (может ли в столбце быть пусто и что тогда делать?), одинаковые значения (если двое делят первое место, показывать обоих?), дубликаты (может ли одно событие встретиться дважды?), границы дат (включительно или нет, какой часовой пояс, от какого «сегодня» считать «последние 30 дней»?) и определения («активный», «выручка»: какие статусы учитывать?).
2. Определите результатЗапишите список столбцов, гранулярность и порядок сортировки до первого SELECT. Набросайте две-три строки ожидаемого результата. Если не получается, значит, вы ещё не поняли задачу.
3. Стройте по шагамНачните с минимальной верной основы (обычно одно соединение), посмотрите на неё, затем добавляйте по одному действию в виде CTE: фильтр, агрегация, ранжирование, финальный SELECT. Называйте каждый CTE по тому, что в нём лежит. После каждого шага спрашивайте себя: «сколько здесь должно быть строк?».
4. Проверьте крайние случаиПрогоните крошечный пример через запрос вслух. Проверьте пустую группу, NULL, одинаковые значения, граничную дату и дубликат. Именно здесь чаще всего удаётся отыграть потерянные баллы.
5. Обсудите производительность и альтернативыСкажите, что делает база (сканирование, соединение, сортировка), какой индекс помог бы, подошла бы ли оконная функция, самосоединение или EXISTS и что вы изменили бы при данных в сто раз больше.

Разобранный пример

Схема придумана для этого гайда. Даты хранятся текстом в формате ISO, деньги в копейках (центах).

users(user_id, name, country, signed_up_at)            -- signed_up_at: 'YYYY-MM-DD'
payments(payment_id, user_id, amount_cents, status, paid_at)
                                                      -- status: 'paid' | 'failed' | 'refunded'
                                                      -- paid_at: 'YYYY-MM-DD HH:MM:SS'

1. Уточняем

• Гранулярность: одна строка на страну. Если двое делят первое место, возвращаем обоих? Допустим, да, обоих.
• «Первые 30 дней»: считается ли платёж ровно через 30 дней после регистрации? Допустим, нет: окно — день регистрации плюс следующие 29 дней (дни с 0-го по 29-й после регистрации), то есть «раньше, чем дата регистрации + 30 дней».
• «Успешные»: только status = 'paid', возвращённые и неудачные не считаем.
• Пользователи без платежей и страны, где никто не платил: не показываем.
• Сумма: в денежных единицах, а не в копейках, с двумя знаками.

2. Определяем результат

country, user_id, spend: одна строка на страну (больше только при равенстве), сортировка по стране, затем по user_id.

3. Строим

WITH first_30 AS (                      -- платежи в окне каждого пользователя
  SELECT u.user_id, u.country, p.amount_cents
  FROM users u
  JOIN payments p ON p.user_id = u.user_id
  WHERE p.status = 'paid'
    AND date(p.paid_at) >= u.signed_up_at
    AND date(p.paid_at) <  date(u.signed_up_at, '+30 days')
),
per_user AS (                           -- одна строка на пользователя
  SELECT user_id, country, SUM(amount_cents) / 100.0 AS spend
  FROM first_30
  GROUP BY user_id, country
),
ranked AS (                             -- больше потратил, выше место; равные делят первое
  SELECT user_id, country, spend,
         RANK() OVER (PARTITION BY country ORDER BY spend DESC) AS rnk
  FROM per_user
)
SELECT country, user_id, printf('%.2f', spend) AS spend
FROM ranked
WHERE rnk = 1
ORDER BY country, user_id;

Каждый CTE отвечает на один вопрос: какие платежи учитываем, сколько потратил каждый пользователь, кто первый в своей стране. Здесь синтаксис SQLite; в PostgreSQL границу окна записали бы как p.paid_at < u.signed_up_at + INTERVAL '30 days'. printf('%.2f', spend) печатает ровно два знака после запятой (текстом); в PostgreSQL используйте ROUND(spend, 2).

4. Проверяем крайние случаи

На горстке придуманных строк (Ана и Бо из KZ, Си и Ди из DE, Эд из FR. Ана зарегистрировалась 5 января: 30.00 в день регистрации, 20.00 на 29-й день (3 февраля) и 99.00 на 30-й день (4 февраля); Бо: один платёж 45.00 и один возвращённый на 50.00; Си и Ди по 40.00; у Эда платежей нет) запрос вернёт:

Платёж Аны на 30-й день верно не попал в сумму (50.00, а не 149.00), возврат Бо проигнорирован, равенство в DE показало обоих, а страны FR в результате нет. Проговаривайте каждую такую проверку вслух.

5. Обсуждаем

• Равенство: RANK оставляет обоих. Если бизнесу нужен ровно один, переходите на ROW_NUMBER() с ORDER BY spend DESC, user_id, чтобы результат был детерминированным.
• Производительность: индекс payments(user_id, paid_at) поддерживает соединение, а фильтр по дате сможет им воспользоваться, только если сравнивать paid_at «как есть»: p.paid_at >= u.signed_up_at AND p.paid_at < date(u.signed_up_at, '+30 days'), без функции вокруг столбца, как в запросе выше. На больших данных я написал бы именно так.
• Альтернатива: обойтись без ранжирования и сравнить сумму с MAX(spend) по стране. Ответ тот же, но оконный вариант легко превращается в «топ-3 по каждой стране».

Python и базы данных: темы и как на них отвечать

Эти темы встречаются на собеседованиях бэкенд-разработчиков и дата-инженеров, обычно вперемешку: «напишите» и «объясните». Ниже у каждой темы есть: что нужно знать, как об этом говорить и на чём потренироваться. Примеры на sqlite3 из стандартной библиотеки, как и в направлении Python в QueryGym.

# неправильно: ввод становится частью SQL
conn.execute(f"SELECT * FROM products WHERE name LIKE '%{term}%'")

# правильно: значение передаётся отдельно
conn.execute("SELECT * FROM products WHERE name LIKE ?", (f"%{term}%",))

13 типичных ошибок (и задачи, на которых их отрабатывают)

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

WHERE end_date IS NULL
WHERE status IS DISTINCT FROM 'x'   -- стандартный SQL (PostgreSQL, SQLite 3.39+); в старом SQLite: status IS NOT 'x'

WHERE NOT EXISTS (SELECT 1 FROM orders o WHERE o.customer_id = c.customer_id)

SELECT d.name, COUNT(e.employee_id) AS headcount   -- не COUNT(*)
FROM departments d LEFT JOIN employees e ON e.department_id = d.department_id
GROUP BY d.department_id, d.name;

SELECT customer_id, COUNT(*) AS n
FROM orders
WHERE status = 'completed'      -- строки
GROUP BY customer_id
HAVING COUNT(*) > 3;           -- группы

-- теряем тарифы без активной подписки
FROM plans p LEFT JOIN subscriptions s ON s.plan_id = p.plan_id
WHERE s.status = 'active'

-- сохраняем все тарифы
FROM plans p LEFT JOIN subscriptions s ON s.plan_id = p.plan_id AND s.status = 'active'

ROUND(100.0 * completed / NULLIF(total, 0), 1)

ORDER BY order_date DESC, order_id DESC LIMIT 10 OFFSET 20

WHERE paid_at >= '2024-12-01' AND paid_at < '2025-01-01'

WITH r AS (
  SELECT *, ROW_NUMBER() OVER (PARTITION BY category_id ORDER BY revenue DESC, product_id) AS rn
  FROM product_revenue)
SELECT * FROM r WHERE rn <= 2;

Как общаться на интервью: думайте вслух

Интервьюеры нанимают тех, с кем смогут работать вместе. Молчание выглядит как «застрял», даже когда вы не застряли.

Рассуждайте вслух

• Пересказывайте задачу своими словами: «То есть мне нужна одна строка на страну, лучший по тратам за первые 30 дней. Верно?»
• Объявляйте план до кода: «Сначала отфильтрую платежи по окну каждого пользователя, потом посчитаю сумму на пользователя, потом проранжирую внутри страны».
• Проговаривайте решения, а не нажатия клавиш: «Здесь нужен LEFT JOIN, потому что клиенты без заказов тоже должны попасть в результат».
• Говорите о том, в чём не уверены, а не прячьте это: «Не помню, есть ли эта функция в таком диалекте; напишу так, как думаю, а вы поправите, если что».

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

• Что такое одна строка результата? Какая гранулярность у каждой таблицы?
• Может ли этот столбец быть NULL? Бывают ли пользователи без заказов?
• Если значения равны, вернуть обоих или выбрать одного?
• Бывают ли дубликаты строк или этот ключ уникален?
• Диапазоны дат включительно? Какой часовой пояс? От какого «сегодня» считаем?
• Какие статусы учитываются в выручке или в «активных»?
• Насколько большие таблицы и нужно ли думать о производительности?
• Для какого диалекта пишу и можно ли запускать запрос?

Если застряли

1. Скажите, где вы находитесь: «Понимаю, что нужен последний заказ каждого клиента, и выбираю между оконной функцией и коррелированным подзапросом».
2. Уменьшите задачу: решите для одного клиента, потом обобщите.
3. Напишите ту часть, в которой уверены, и посмотрите на её результат.
4. Разберите крошечный пример вручную: какую строку вы бы выбрали и почему.
5. Если минуту-две нет движения, попросите подсказку: «Можно уточнить, мне стоит смотреть в сторону оконных функций?» Спросить рано дешевле, чем молчать.

Проверяйте запрос вслух

Не запускайте и не говорите просто «вроде верно». Возьмите три-четыре строки и проведите их через запрос: «Ана зарегистрировалась 5 января, платёж 6 января попадает в окно, а платёж 4 февраля — тридцатый день, значит, он не входит». И каждый раз называйте, какой именно крайний случай проверяете.

Как принимать подсказки

• Подсказка — не провал, а помощь интервьюера, чтобы вы смогли показать, на что способны. Поблагодарите и используйте её.
• Перескажите подсказку своими словами, затем примените. Так видно, что вы поняли, а не скопировали.
• Не спорьте из обороны. Если не согласны, спокойно объясните почему, с примером.
• Если ошиблись, скажите, что сделали бы иначе, и исправьте. Умение выправить ситуацию — сильный сигнал.

Чек-лист: накануне и в день интервью

Тренировки с ИИ-наставником

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

Просите подсказки, а не ответы

• Сначала попробуйте сами: 10–15 минут в одиночку, потом спрашивайте.
• Спрашивайте конкретно: «Почему здесь 12 строк, хотя я ожидаю 9?» лучше, чем «помоги».
• Просите минимальную подсказку: «Дай намёк без запроса» или «Что мне проверить в первую очередь?». Подсказки ступенчатые, просите следующую, только когда она нужна.
• Проверяйте решение кнопкой проверки, а не чатом. Когда проверка пройдена, спросите «почему это работает?» и объясните ответ обратно своими словами.

Два действия в роли интервьюера

После пробного собеседования

Когда пробное собеседование закончится, вы получите отчёт и сможете попросить наставника разобрать сессию: что получилось, где вы потеряли время или баллы и что тренировать дальше. Перенесите выводы в журнал ошибок и в следующий день плана.