Работал ли ты напрямую с PostgreSQL

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

Считаете ли вы данные в базе или выгружаете всё в память и разбираетесь дальше сами. Для работы с данными и моделями PostgreSQL это основной инструмент подготовки выборок, поэтому спрашивают про SQL за пределами простой фильтрации.

Как отвечать

Покажите, что умеете переносить вычисления в базу.

• Аналитический SQL: оконные функции, общие табличные выражения, группирующие наборы, перцентили, усечение времени, соединение по интервалу через LATERAL.
• Выгрузка в Python: чтение пачками или серверным курсором вместо одной огромной таблицы в памяти, загрузка результатов через COPY, а не построчными вставками.
• Производительность: EXPLAIN (ANALYZE, BUFFERS), индекс под фильтр и сортировку, материализованные представления для повторяющихся агрегатов.
• Где считать: тяжёлые запросы на реплику, а не на боевой узел, обязательно с ограничением времени выполнения.
• Специфика задач: расширение pgvector, если храните эмбеддинги, и аккуратная фиксация точки среза при сборе признаков.

select user_id, count(*) over (
         partition by user_id order by ts
         range between interval '7 days' preceding and current row
       ) as events_7d
from events;

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

Выгружают таблицу целиком и агрегируют в памяти. База сделала бы это дешевле, а так страдают и рабочая машина, и продуктовая нагрузка на сервере.

Допускают утечку будущего в признаки: агрегат считается по всей истории пользователя, включая период после момента предсказания. На обучении метрика прекрасная, в бою модель не работает.

Гоняют тяжёлую аналитику на боевом узле без ограничения по времени, а результат описывают процентами ускорения, ни разу не показав план запроса. Ни то ни другое не переживает первого уточняющего вопроса.