Собеседование аналитика данных: 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: пробное интервью вслух без подсказок.