Можешь ли писать базовые SQL-запросы?

Что проверяют

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

Как отвечать

Ответьте «да» и сразу очертите границы уверенного владения, привязав их к работе с данными:

• выборка и фильтры: SELECT, WHERE, ORDER BY, LIMIT, работа с NULL через IS NULL и COALESCE;
• агрегаты: GROUP BY, COUNT, SUM, AVG, условия на группы через HAVING;
• соединения: разница между INNER JOIN и LEFT JOIN, поиск строк без пары;
• оконные функции: ROW_NUMBER() для дедупликации, LAG() для разницы с прошлым периодом, скользящие средние через OVER (PARTITION BY ... ORDER BY ...);
• CTE (WITH): разбить длинный запрос на читаемые шаги.

Добавьте, где вы это применяли: сбор признаков для модели, разметка таргета, проверка качества данных, выгрузка в pandas через read_sql. Назовите свои базы: PostgreSQL, ClickHouse, BigQuery, Spark SQL. Примеры и цифры приводите свои: сколько строк было в таблицах, что именно считали.

Для ML полезно упомянуть утечку данных: признаки собираются только из событий до даты среза, иначе модель на валидации выглядит лучше, чем будет в проде.

Если основной опыт в pandas, так и скажите: логику groupby и merge вы переносите в SQL, а синтаксис оконных функций подтягиваете. Честная граница лучше уверенного «да», которое рассыплется на первой задаче.

Где спотыкаются

Пишут условие на правую таблицу LEFT JOIN в WHERE и незаметно превращают его во внутреннее соединение. Условие нужно переносить в ON.

Сравнивают с NULL через = и удивляются пустому результату. Сюда же путаница COUNT(*) и COUNT(column): второй не считает строки, где в колонке NULL.

Не замечают размножения строк после соединения один-ко-многим. Сумма после такого JOIN завышена, а кандидат уверенно называет её выручкой.