Собеседование аналитика данных: 30 задач и как решать их вслух

Коротко

Подготовка к собеседованию складывается из нескольких слоёв. SQL показывает, умеете ли вы достать данные без размножения строк. Python и pandas — можете ли быстро обработать таблицу и проверить гипотезу. Метрики и статистика — понимаете ли, что именно измеряете. Кейс и разговор с заказчиком — способен ли превратить расчёт в решение.

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

Какие блоки встречаются на собеседовании

Конкретный процесс зависит от компании и уровня, но повторяются одни и те же типы разговора: SQL-задача на несколько таблиц, вопрос про метрику или бизнес-сценарий, короткая работа с Python/pandas, статистика и обсуждение опыта. На отдельных позициях добавляются дашборд, Excel, продуктовый кейс или объяснение того, как вы взаимодействовали с менеджером.

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

Универсальный каркас ответа

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

После расчёта добавьте две проверки: sanity-check и альтернативный срез. Например, при подсчёте заказов проверьте уникальные order_id и сравните итог с суммой по дням. При падении конверсии разбейте результат по платформе и версии. Такой комментарий часто сильнее, чем ещё один редкий синтаксический приём.

• 1. Переформулировать вопрос одним предложением.
• 2. Назвать единицу результата: пользователь, заказ, сессия, аккаунт или день.
• 3. Определить окно, фильтры и правила исключения.
• 4. Посчитать минимально достаточный вариант.
• 5. Проверить крайние случаи и назвать продуктовый вывод.

Задача 1: найти топ-3 товара в каждой категории

Дана таблица order_items с полями order_id, product_id, category, quantity и price. Нужно найти три товара с максимальной выручкой внутри каждой категории за последний полный месяц. Сильный ответ начинается с уточнений: учитывать только оплаченные заказы, считать revenue как quantity * price, а при одинаковой выручке использовать стабильный tie-breaker по product_id.

Технически задача проверяет GROUP BY, оконную функцию и границы периода. Методологически — понимаете ли вы, что сортировать нужно уже агрегированные товары, а не отдельные позиции заказа. Перед row_number сначала получите одну строку на товар и категорию.

with product_revenue as (
  select category, product_id,
    sum(quantity * price) as revenue
  from order_items
  where order_status = 'paid'
    and ordered_at >= date_trunc('month', current_date) - interval '1 month'
    and ordered_at < date_trunc('month', current_date)
  group by 1, 2
), ranked as (
  select *, row_number() over (
    partition by category
    order by revenue desc, product_id
  ) as rn
  from product_revenue
)
select category, product_id, revenue
from ranked
where rn <= 3
order by category, rn;

Задача 2: почему упал DAU

Вместо ответа «проверю дашборд» соберите короткий план. Сначала исключите неполный день, смену таймзоны, поломку события и изменение определения active action. Затем разложите DAU на новых, вернувшихся и воскресших пользователей. После этого посмотрите канал, платформу, версию приложения и core action rate.

Интервьюеру нужен не список из двадцати разрезов, а порядок. Если падение видно только на Android после релиза, техническая гипотеза выше в списке. Если DAU просел только у paid-канала, сначала проверьте качество трафика. Если DAU стабилен, но core action rate падает, пользователи приходят, но не получают ценность — это уже другой разговор.

Задача 3: объяснить A/B-тест

Вам показывают conversion 8,2% в контроле и 8,8% в тесте и спрашивают, выкатывать ли изменение. Нельзя отвечать только «uplift положительный». Сначала уточните размер выборки, доверительный интервал, primary metric, длительность, guardrails, SRM и единицу рандомизации. Затем спросите, не было ли подглядывания и нескольких вариантов остановки.

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

Задача 4: обработать таблицу в pandas

Типовой промпт: есть orders с user_id, created_at, status, amount и channel. Посчитайте месячную выручку и число покупателей по каналам, исключив отменённые заказы. Перед groupby проверьте тип даты, дубли order_id, пропуски amount и зерно строк. Если одна строка — товарная позиция, сначала агрегируйте до заказа, иначе выручка и покупатели могут быть искажены.

На разговоре проговаривай, почему используете nunique, а не count, и почему границу следующего месяца задаёте через <. Попросите маленький пример или сам создайте его мысленно: один пользователь с двумя заказами должен дать двух заказов, но одного покупателя.

orders['created_at'] = pd.to_datetime(orders['created_at'])
paid = orders.loc[
    orders['status'].eq('paid')
    & orders['amount'].notna(),
].copy()
paid['month'] = paid['created_at'].dt.to_period('M')
answer = (paid.groupby(['month', 'channel'])
  .agg(revenue=('amount', 'sum'),
       buyers=('user_id', 'nunique'),
       orders=('order_id', 'nunique'))
  .reset_index())

Поведенческие вопросы: отвечайте через ситуацию и результат

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

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

• Ситуация: какой бизнес-контекст и кто ждал ответа?
• Задача: какое решение нужно было поддержать?
• Действие: что сделали именно вы и почему?
• Результат: что изменилось и как это измерили?
• Вывод: что теперь делаете иначе?

Карта задач по уровням

Одинаковое название позиции может скрывать разный уровень сложности. На junior-собеседовании важнее уверенно фильтровать и агрегировать данные, объяснять базовые метрики и не теряться в простой проверке. На middle добавляются неоднозначное условие, несколько таблиц, эксперимент и самостоятельная декомпозиция. На senior проверяют, как вы выбираете компромисс, влияете на roadmap и защищаете качество аналитической системы.

Используйте таблицу как список для самодиагностики. Не переходите к следующему уровню, пока не умеете решить задачу предыдущего без подсказки и объяснить, где в ней может возникнуть ошибка. Цель подготовки — не максимальная сложность, а стабильность на типовых рабочих вопросах.

Как выглядит сильный разбор неизвестной задачи

Иногда вопрос не похож ни на одну тренировочную карточку. Например: «Почему клиенты стали реже пользоваться отчётами?» Не нужно сразу искать знакомую метрику. Сначала переведите вопрос в наблюдаемое поведение: какой клиент, какой отчёт, какой период и что значит «реже». Затем опишите единицу — account, user или report view — и только после этого выберите данные.

Дальше отделите измерение от объяснения. Вы можете доказать, что usage снизился у SMB-клиентов после изменения тарифа, но ещё не доказал, что причина именно цена. Чтобы проверить механизм, нужны сравнение сегментов, события на экране тарифа, обращения в поддержку или эксперимент. Такая аккуратность и есть продуктовая зрелость на собеседовании.

• Перевести разговорное слово в измеримое событие.
• Проверить, не изменилось ли само определение события.
• Разделить масштаб проблемы и гипотезу причины.
• Назвать данные, которые подтвердят или опровергнут гипотезу.
• Закончить решением, которое можно принять после проверки.

Как тренироваться в последнюю неделю

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

На следующем круге решайте ту же задачу с другой гранулярностью или дополнительным условием. Например, вместо топ-товаров попросите топ-товары по неделям, а вместо общего DAU добавьте платформу. Так тренируется перенос логики, а не запоминание конкретного запроса.

• День 1–2: SELECT, JOIN, GROUP BY, оконные функции и даты.
• День 3: DAU, retention, funnel, ARPU и A/B-метрики.
• День 4: pandas, пропуски, merge, groupby и маленький график.
• День 5: два продуктовых кейса с декомпозицией.
• День 6: ответы по опыту и объяснение проекта за две минуты.
• День 7: пробное интервью вслух без подсказок.