Я разобрала 899 задач с собеседований на аналитика — вот что спрашивают на самом деле

Когда я готовилась к собеседованиям на аналитика, больше всего меня раздражала невозможность приоритизировать. Советы в интернете либо общие («подтяните SQL»), либо противоречат друг другу. Учить сначала оконные функции или продуктовые метрики? Тратить вечера на LeetCode или на теорию A/B? Времени на всё нет, а данных, на чём строить план, — тоже нет

Я аналитик, поэтому сделала то, что делаю на работе: собрала данные. За два года у меня накопилась база из 899 задач с собеседований на аналитика (data / product analyst) — авторские задачи по мотивам реальных интервью и открытых источников. Каждую я разметила по секции, теме внутри секции, сложности и грейду, на котором её обычно спрашивают. В этой статье — частотный разбор всей базы: какие секции доминируют, что переоценено, и как собеседование меняется от джуна к сеньору

Сразу дисклеймер: это не репрезентативная выборка по всему рынку труда. Это срез одной большой базы с понятными смещениями, о них ниже. Но закономерности на 899 задачах устойчивые, и они сильно расходятся с тем, как люди обычно готовятся

Откуда данные и как размечались

Без этого раздела статье верить нельзя, поэтому по порядку

• Что это за задачи. Авторские задачи по мотивам реальных собеседований и тестовых заданий: мой собственный опыт собеседований (я продуктовый аналитик, до этого — мехмат МГУ), рассказы коллег и кандидатов, открытые подборки (GitHub-репозитории interview-вопросов, статьи на Хабре, LeetCode, публичные тестовые задания компаний). Всего 171 источник
• Состав по происхождению: ~45% — открытые источники и учебные подборки, ~21% — по мотивам собеседований в российском финтехе и банках, ~14% — российский бигтех и продуктовые компании, ~4% — зарубежные компании, остальное — смешанное
• Объём и период. 899 задач, собирались и размечались в 2024–2026
• Разметка. Секция (SQL, статистика, A/B и т.д.), тема внутри секции, сложность (easy 25% / medium 54% / hard 21%), грейд. Разметка авторская: грейд — это моя оценка «на каком уровне это обычно спрашивают», а не факт из вакансии
• Смещения. Перекос в сторону финтеха и продуктовых компаний. Задачи, которые кандидаты запоминают и пересказывают, — обычно сложные и необычные, поэтому хвост «интересных» задач переоценен, а рутинные «выведите топ-5 клиентов» — недооценены. Поведенческую секцию я не размечала вовсе: база про технические задачи, так что выводов про софт-скиллы здесь не будет

Общая картина: из чего состоит собеседование

Пять секций — SQL, кейсы, статистика, метрики и A/B — дают 77% всех задач. Если времени на подготовку мало, то весь план уже виден из одной таблицы

SQL: треть всех задач

Топ тем внутри секции:

Оконные функции (18% секции), JOIN и их подвохи (13%), агрегации с GROUP BY и HAVING (11%). Четвёртое место меня удивило: теория БД и хранилища — нормализация, ACID, SCD, проектирование витрин — 10% SQL-секции. К «просто пишу запросы» это не сводится: у аналитиков спрашивают, как данные устроены, а не только как их достать

Задача по мотивам реальных собеседований — из тех, где отсеивается заметная часть кандидатов:

Задача. Есть таблица событий events(user_id, event_type, ts). Постройте таблицу пользовательских сессий, если новая сессия начинается после 30 минут бездействия

Где спотыкаются. Пытаются решить через self-join по времени и получают либо квадратичный запрос, либо неверные границы сессий. Рабочее решение — LAG() по пользователю, флаг «прошло больше 30 минут», накопительная сумма флагов как номер сессии:

SELECT user_id, ts,
       SUM(new_session) OVER (PARTITION BY user_id ORDER BY ts) AS session_id
FROM (
  SELECT user_id, ts,
         CASE WHEN ts - LAG(ts) OVER (PARTITION BY user_id ORDER BY ts)
                   > INTERVAL '30 minutes'
              OR LAG(ts) OVER (PARTITION BY user_id ORDER BY ts) IS NULL
         THEN 1 ELSE 0 END AS new_session
  FROM events
) t;

Сессионизация, когорты, retention и воронки вместе дают ещё 9% SQL-секции — это ровно те паттерны, которые аналитик потом пишет каждую неделю на работе

Типичная ошибка секции: кандидат уверенно решает учебные запросы на одну таблицу, но сыпется, как только нужно скомбинировать окно с агрегацией или объяснить, почему LEFT JOIN после WHERE по правой таблице превратился во INNER

Бизнес-кейсы и продуктовые метрики: 26% на двоих

Вместе эти две секции дают 26% базы — больше, чем статистика и Python вместе. И к ним готовятся меньше всего, потому что «там же нечего учить»

Задача (по мотивам). «Просмотры сторис упали на 7%. Разберитесь, в чём дело»

Что проверяют. Не формулы, а структуру мышления. Сначала уточнить метрику: total views или views per DAU? Против чего упали — вчера или прошлый понедельник, с учётом недельной сезонности? Потом отсечь технику: выкатка, баг логирования, изменение самой метрики. Потом сегментировать: платформа, гео, новые против старых пользователей. И только потом гипотезы про продукт. Заваливаются те, кто с первой секунды прыгает в «наверное, конкуренты запустили похожую фичу», не проверив, что это не сломанный трекинг

Почему секция недооценена: к SQL готовятся все, а «думать вслух» по кейсу — почти никто. На middle-грейде кейсы и метрики — самая большая часть собеседования (31% задач), и именно здесь решается оффер

Статистика и A/B: маленькая секция с самыми дорогими ошибками

Статистика — 13% базы: вероятность, распределения и матожидание (28% секции), проверка гипотез и критерии (13%), условная вероятность и Байес (12%). A/B-тесты — ещё 7%, но внутри плотность боли максимальная: дизайн эксперимента (21% секции), ratio-метрики и дисперсия (19%), анализ результатов (19%) и подводные камни — peeking, novelty-эффект, множественные сравнения (17%)

Задача (по мотивам). «Тест идёт неделю. На третий день p-value было 0.04. PM предлагает остановить тест и катить фичу. Что отвечаете?»

Что проверяют. Понимаете ли вы peeking: стандартный t-test предполагает зафиксированный заранее размер выборки, а решение «останавливаем, когда p-value красивый» раздувает ошибку первого рода в разы. Правильный разговор — про заранее посчитанный размер выборки и MDE, а если бизнесу правда нужно смотреть раньше — про последовательные критерии

Типичная ошибка: заученные определения без понимания следствий. Вопрос «объясните p-value своими словами» отсеивает мгновенно: самый частый неверный ответ — «вероятность, что нулевая гипотеза верна»

Как собеседование меняется с грейдом

Самая интересная находка всей разметки:

• Junior: больше половины задач — SQL (53%), ещё 16% — Python/pandas. A/B-тестов ноль, продуктовых метрик почти ноль. Джуна собеседуют как оператора инструментов
• Middle: SQL сжимается до 26%, а главной секцией становятся кейсы и метрики (31%). Появляются A/B и ML
• Senior: SQL — только 17%, Python почти исчезает (1%). Половину собеседования занимают A/B-тесты (25%) и ML (23%)

Собеседование по сути переворачивается: у джуна проверяют «умеешь ли достать данные», у сеньора — «умеешь ли поставить эксперимент и принять решение». Если вы мидл и готовитесь к собесу так же, как на первую работу, — вы готовитесь к чужому собеседованию

Что меня удивило

1. Алгоритмы — 3% базы. При этом почти каждый, кого я спрашивала про подготовку, начинал с LeetCode, по привычке перенятой у бэкендеров. Для аналитика это худшая инвестиция первых недель подготовки
2. Python — это pandas. Внутри Python-секции доминируют groupby, merge, очистка данных и векторизация. Классических алгоритмических задачек на Python в базе — единицы, и почти все они для позиций с DS-уклоном
3. Теорию БД спрашивают чаще, чем кажется. Каждая десятая SQL-задача — не запрос, а вопрос про устройство: нормализация, транзакции, хранилища, SCD. В подборках «топ-50 SQL-вопросов» этого пласта почти нет
4. У сеньоров исчезает Python. 16% у джунов, 9% у мидлов, 1% у сеньоров. Инструмент перестают проверять, когда проверяют мышление

Как готовиться, если смотреть на цифры

1. Три ядра сначала: SQL, кейсы, статистика с A/B. Это 77% задач. В SQL первым делом оконные функции и JOIN — треть секции
2. Кейсы тренируются, хоть и кажется, что нет. Возьмите любую метрику продукта, которым пользуетесь, и разберите вслух «она упала на 10%, что делать» по схеме: уточнить метрику → техника → сегменты → гипотезы. Десять таких прогонов меняют собеседование сильнее, чем сотня решённых запросов
3. Готовьтесь к своему грейду. Джуну A/B почти не грозит, мидлу и сеньору без него никуда. Сеньору стоит вкладываться в дизайн экспериментов и ML-секцию, а не полировать SQL
4. Алгоритмы — в самый конец, если вы не в DS-трек. 3% задач не оправдывают недели на LeetCode

Вывод

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

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