3 апреля 2026 г.

Собеседование на аналитика данных: 50+ вопросов с ответами

Q: Какие этапы собеседования на аналитика данных?

Типичный процесс: HR-скрининг (15-20 минут), SQL-интервью (45-90 минут, ключевой фильтр), Python и работа с данными (30-60 минут, не везде), статистика и эксперименты (30-60 минут), финальное интервью с нанимающим менеджером.

Q: Что важнее всего для собеседования аналитика данных?

SQL — абсолютный приоритет, по нему отсеивают больше всего кандидатов. Нужно уверенно владеть GROUP BY, JOIN, оконными функциями и CTE. На втором месте — продуктовые метрики и умение разбирать кейсы. Python и статистика важны, но их вес зависит от компании.

Q: Какие SQL-задачи дают на собеседовании аналитика?

Пять основных типов: агрегации с GROUP BY и HAVING, JOIN нескольких таблиц, оконные функции (ROW_NUMBER, LAG, скользящие средние), подзапросы и CTE, задачи на retention и когорты. Для middle+ позиций оконные функции — самая частая тема.

Q: Как готовиться к собеседованию аналитика данных за 4 недели?

Неделя 1 — SQL (базовый, JOIN, оконные функции). Неделя 2 — Python (pandas, визуализация). Неделя 3 — статистика и A/B-тесты. Неделя 4 — продуктовые кейсы, повторение слабых мест, mock-интервью. По 1.5-2 часа в день с практическими задачами.

Кто такой аналитик данных

Аналитик данных — специалист, который превращает сырые данные в выводы и рекомендации. Он пишет SQL-запросы, строит дашборды, проверяет гипотезы, находит закономерности и помогает бизнесу принимать решения на основе фактов, а не интуиции.

Роль существует практически в любой отрасли — от e-commerce и финтеха до логистики и медиа. В зависимости от компании аналитик данных может фокусироваться на продуктовых метриках, маркетинговой атрибуции, финансовой отчётности или операционной эффективности. Но набор базовых навыков один и тот же: SQL, работа с данными в Python, понимание статистики и умение доносить результаты анализа до стейкхолдеров.

Если вам ближе продуктовый фокус — метрики, воронки, эксперименты — посмотрите отдельный гайд по собеседованию на продуктового аналитика. Здесь мы разберём подготовку для более широкой роли аналитика данных.

Этапы собеседования

Процесс найма в большинстве компаний включает пять этапов. Порядок может отличаться, но структура устоялась.

1. HR-скрининг

Звонок на 15–20 минут. Рекрутер проверяет ваш опыт, мотивацию, зарплатные ожидания. Главная задача — показать, что вы понимаете роль и можете внятно рассказать, чем занимались. Подготовьте рассказ о себе на две минуты: какие задачи решали, с какими данными работали, какой результат принесли.

Типичные вопросы: «Почему хотите к нам?», «Расскажите про самый интересный проект», «Какие инструменты используете?». Не нужно глубоко разбирать кейсы — достаточно чёткого и структурированного ответа.

2. SQL-интервью

Техническое собеседование на 45–90 минут. Вам дают задачи и просят решить их в реальном времени — в онлайн-редакторе или на расшаренном экране.

Это ключевой фильтр: по SQL отсеивают больше всего кандидатов. Вопросы варьируются от базовых (GROUP BY, JOIN) до продвинутых (оконные функции, подзапросы, CTE). Подробнее о подготовке — в разделе SQL.

3. Python и работа с данными

Отдельный этап или часть технического интервью — 30–60 минут. Проверяют, можете ли вы работать с данными в pandas, строить визуализации, писать скрипты для автоматизации рутинных задач. Иногда дают задачу на чистку и трансформацию датасета.

Этот этап есть не везде. В компаниях, где аналитики работают в основном в SQL + BI-инструменты, Python могут не спрашивать. Но тренд однозначный — Python спрашивают всё чаще.

4. Статистика и эксперименты

Этап на 30–60 минут. Проверяют понимание основ: доверительные интервалы, проверка гипотез, распределения, A/B-тесты. Формат — либо устные вопросы, либо задачи на расчёт.

Глубина зависит от роли. Для junior-позиции достаточно понимать, что такое p-value и зачем нужен контрольная группа. Для middle и выше — ожидают уверенное владение: расчёт размера выборки, ошибки первого и второго рода, множественное тестирование.

5. Финальное интервью

Встреча с нанимающим менеджером — 30–45 минут. Обсуждают ваш опыт в деталях, подход к решению задач, совместимость с командой. Могут дать мини-кейс: «Вот такая ситуация в данных — как бы вы её исследовали?». Здесь оценивают не скорость написания кода, а способность мыслить структурно и коммуницировать.

SQL: топ-5 типов вопросов

SQL — фундамент собеседования на аналитика данных. Вот пять категорий задач, которые встречаются чаще всего.

1. Агрегации и GROUP BY

Базовый уровень, но не стоит недооценивать. Просят посчитать количество, сумму, среднее по группам — с условиями и фильтрами.

SELECT
    department,
    COUNT(*) AS employee_count,
    ROUND(AVG(salary), 0) AS avg_salary
FROM employees
WHERE hire_date >= '2025-01-01'
GROUP BY department
HAVING COUNT(*) >= 5
ORDER BY avg_salary DESC

Подробный разбор GROUP BY и HAVING — в шпаргалке.

2. JOIN и работа с несколькими таблицами

Задачи на объединение данных из разных источников. Важно понимать разницу между INNER, LEFT, RIGHT, FULL JOIN и уметь объяснить, когда какой нужен.

SELECT
    u.user_id,
    u.registered_at,
    COUNT(o.order_id) AS order_count
FROM users u
LEFT JOIN orders o ON u.user_id = o.user_id
    AND o.created_at >= u.registered_at
    AND o.created_at < u.registered_at + INTERVAL '30 days'
GROUP BY u.user_id, u.registered_at

Типичная ловушка — забыть про LEFT JOIN и потерять пользователей без заказов. Подробнее — в шпаргалке по JOIN.

3. Оконные функции

Самая частая тема для middle-позиций. ROW_NUMBER, RANK, LAG, LEAD, скользящие средние, нарастающие итоги.

SELECT
    user_id,
    event_date,
    revenue,
    SUM(revenue) OVER (
        PARTITION BY user_id
        ORDER BY event_date
        ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
    ) AS cumulative_revenue,
    LAG(event_date) OVER (
        PARTITION BY user_id ORDER BY event_date
    ) AS prev_visit
FROM user_events

Оконные функции нужно довести до автоматизма — на собеседовании времени на вспоминание синтаксиса не будет.

4. Подзапросы и CTE

Сложные задачи, где нужно строить многоуровневые запросы. Например, «найти пользователей, чей средний чек выше среднего по их городу».

WITH city_avg AS (
    SELECT city, AVG(order_total) AS avg_total
    FROM orders o
    JOIN users u ON o.user_id = u.user_id
    GROUP BY city
)
SELECT u.user_id, u.city, AVG(o.order_total) AS user_avg
FROM orders o
JOIN users u ON o.user_id = u.user_id
JOIN city_avg ca ON u.city = ca.city
GROUP BY u.user_id, u.city, ca.avg_total
HAVING AVG(o.order_total) > ca.avg_total

CTE делают запрос читаемым. На собеседовании это ценят — покажите, что вы пишете код, который можно понять.

5. Retention и когорты

Задачи на пересечении SQL и продуктовой аналитики. Посчитать retention по когортам, построить воронку конверсии, найти паттерны в пользовательском поведении.

Этот тип задач проверяет не только SQL, но и понимание бизнес-логики. Уточняйте определения: что считаем активностью, как определяем когорту, какой часовой пояс используем.

Python: что спрашивают

pandas — ядро

Большинство Python-вопросов на собеседовании аналитика крутятся вокруг pandas. Типичные задачи:

Загрузка и осмотр данных: read_csv, info(), describe(), value_counts().
Фильтрация и трансформация: условная фильтрация, apply, map, создание новых столбцов.
Группировки: groupby + агрегации, agg с несколькими функциями, transform.
Объединение: merge, concat, join — и понимание, чем они отличаются.
Работа с датами: pd.to_datetime, dt.date, resample, расчёт разницы между датами.
Пропуски: isna(), fillna(), стратегии заполнения.

Часто просят решить задачу, которую можно решить и в SQL — но на Python. Это проверяет, насколько свободно вы переключаетесь между инструментами.

Визуализация

Могут попросить построить график по данным: распределение, временной ряд, барплот по категориям. Достаточно уверенно владеть matplotlib или seaborn на уровне базовых графиков. Продвинутые библиотеки вроде plotly обычно не спрашивают.

Главное — не просто построить картинку, а объяснить, почему вы выбрали именно этот тип графика и что на нём видно.

Статистика: что нужно знать

Статистика на собеседовании аналитика данных — это не академический курс. Спрашивают прикладные вещи, которые нужны в работе каждый день.

Доверительные интервалы

Что это, как построить, как интерпретировать. Типичный вопрос: «Средний чек — 1 200 рублей, доверительный интервал 95% — от 1 150 до 1 250. Что это значит?». Нужно уметь объяснить без зазубренных формулировок, простым языком.

Проверка гипотез

Нулевая и альтернативная гипотезы, p-value, уровень значимости. Ошибки первого и второго рода — что это и к чему приводят в бизнес-контексте. Ошибка первого рода: вы внедрили изменение, которое на самом деле не работает. Ошибка второго рода: вы отклонили изменение, которое на самом деле полезно.

Подробнее — в разделе по статистике.

Распределения

Нормальное распределение и его свойства. Почему средний чек обычно не распределён нормально (правый хвост). Что делать, когда данные не нормальные — логарифмирование, непараметрические тесты, бутстрап.

A/B-тесты

Как спланировать эксперимент: выбрать метрику, рассчитать размер выборки, определить длительность. Как интерпретировать результат: что делать, если p-value = 0.06, что такое практическая значимость и почему она важнее статистической.

Отдельно стоит знать про типичные ловушки: подглядывание в результаты (peeking), множественные сравнения, novelty effect, сетевые эффекты. Подробнее — в разделе A/B-тестирования.

Продуктовые и бизнес-кейсы

Даже если вы идёте не на продуктового аналитика, кейсовые вопросы встречаются часто. Два самых распространённых формата:

Расследование метрики

«Вчера DAU упало на 20%. Как будете разбираться?»

Структура ответа:

Проверить данные. Нет ли бага в трекинге, не было ли технического сбоя, корректно ли собираются логи.
Декомпозировать. Разбить по платформам, источникам трафика, регионам, сегментам пользователей. Найти, где именно упало.
Проверить внешние факторы. Выходной день, сезонность, конкурент запустил акцию, изменились рекламные кампании.
Проверить внутренние изменения. Был ли релиз, изменился ли онбординг, не поломался ли ключевой экран.
Сформулировать гипотезы и план проверки. Какие запросы напишете, какие данные посмотрите.

Дизайн эксперимента

«Мы хотим добавить рекомендации на главную страницу. Как проверить, что это улучшение?»

Что ожидают в ответе:

Метрика успеха. Не «клики по рекомендациям», а бизнес-метрика: конверсия в целевое действие, время до первой покупки, retention на D7.
Единица рандомизации. Пользователь, а не сессия — и объяснение почему.
Размер выборки и длительность. Хотя бы на уровне понимания: от чего зависит, как рассчитать.
Guardrail-метрики. Что может пойти не так — например, рекомендации увеличат клики, но снизят глубину просмотра.

План подготовки: 4 недели

Если до собеседования есть месяц — вот план, который покрывает все темы системно.

Неделя 1: SQL

Дни 1–2. Базовый SQL: SELECT, WHERE, GROUP BY, HAVING, ORDER BY. Решите 10–15 задач.
Дни 3–4. JOIN: INNER, LEFT, FULL. Задачи на объединение нескольких таблиц. Разберите шпаргалку по JOIN.
Дни 5–7. Оконные функции: ROW_NUMBER, RANK, LAG, LEAD, SUM OVER. Задачи на ранжирование, нарастающие итоги, скользящие средние.

Цель недели: уверенно решать SQL-задачи уровня middle за 15–20 минут.

Неделя 2: Python и визуализация

Дни 1–3. pandas: загрузка данных, фильтрация, группировки, merge, работа с датами и пропусками.
Дни 4–5. Решите 5–7 задач на трансформацию данных в Python. Попробуйте пересчитать SQL-задачи из первой недели в pandas.
Дни 6–7. Визуализация: matplotlib/seaborn. Постройте 5 разных графиков по реальному датасету. Потренируйтесь объяснять, что на них видно.

Цель недели: уметь решить любую табличную задачу в pandas и построить осмысленный график.

Неделя 3: статистика и эксперименты

Дни 1–2. Основы статистики: распределения, среднее vs. медиана, стандартное отклонение, доверительные интервалы.
Дни 3–4. Проверка гипотез: t-тест, хи-квадрат, p-value, ошибки первого и второго рода. Решите 3–4 задачи на интерпретацию результатов тестов.
Дни 5–7. A/B-тесты: дизайн эксперимента, расчёт размера выборки, MDE, типичные ловушки. Разберите 2–3 кейса от начала до конца.

Цель недели: объяснить любой статистический концепт простым языком и спроектировать A/B-тест.

Неделя 4: кейсы, повторение, mock-интервью

Дни 1–2. Продуктовые кейсы: декомпозиция метрик, расследование аномалий, выбор North Star метрики. Разберите 3–4 кейса вслух.
Дни 3–4. Повторите слабые места. Пройдитесь по задачам, которые вызвали затруднения в первые три недели.
Дни 5–6. Mock-интервью. Попросите друга или коллегу проинтервьюировать вас. Если некого попросить — решайте задачи с таймером и проговаривайте решение вслух.
День 7. Отдых. Перед собеседованием нужна свежая голова, а не ещё один раунд зубрёжки.

Частые ошибки

Молча писать код

Собеседование — не экзамен. Интервьюер хочет видеть ваш ход мысли, а не только финальный результат. Проговаривайте, что делаете и почему. «Сначала я соединю таблицы по user_id, использую LEFT JOIN, чтобы не потерять пользователей без событий» — это именно то, что ожидают.

Не уточнять условия

Задачи на собеседовании намеренно сформулированы неточно. «Посчитайте retention» — какой именно? Day-N или rolling? По дате регистрации или первого действия? Что считаем активностью? Кандидат, который задаёт правильные вопросы, выигрывает у того, кто молча пишет запрос по своим предположениям.

Знать теорию, но не уметь объяснить

«P-value — это вероятность получить наблюдаемый результат или более экстремальный при условии истинности нулевой гипотезы». Формально верно, но если вы не можете объяснить это простым языком и привести пример из бизнеса — на собеседовании это не засчитают. Тренируйтесь объяснять концепты так, будто рассказываете менеджеру, который не знает статистику.

Игнорировать edge-кейсы в SQL

NULL, дубли, пустые строки — кандидаты забывают про них, а на реальных данных они есть всегда. Перед тем как писать запрос, подумайте: что будет, если у пользователя нет заказов? Что, если дата — NULL? Что, если один пользователь встречается в таблице дважды?

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

«SQL я знаю отлично, остальное подтянется». Не подтянется. Собеседование проверяет всё: SQL, статистику, продуктовое мышление, коммуникацию. Провал на любом этапе — это отказ, даже если на остальных вы были идеальны. Распределяйте время на все темы.

Не засекать время

На собеседовании на задачу дают 15–20 минут. Если дома вы решаете аналогичную задачу за 40 минут — на интервью не уложитесь. Всегда тренируйтесь с таймером.

50 реальных вопросов с собеседований

Ниже — вопросы, которые действительно задают на собеседованиях в Яндексе, Тинькофф, Ozon, Сбере и других крупных компаниях. К каждому — краткий ответ: используйте его как ориентир, но на интервью отвечайте своими словами и с примерами.

SQL (15 вопросов)

Q: Чем отличается WHERE от HAVING? WHERE фильтрует строки до группировки, HAVING — после. Если нужно отобрать группы по результату агрегации (например, только отделы с более чем 10 сотрудниками), используется HAVING. Подробнее — в шпаргалке по GROUP BY и HAVING.

Q: В чём разница между LEFT JOIN и INNER JOIN? INNER JOIN возвращает только строки, у которых есть совпадение в обеих таблицах. LEFT JOIN возвращает все строки из левой таблицы, даже если совпадения нет — в этом случае столбцы правой таблицы заполняются NULL. Разбор всех типов — в шпаргалке по JOIN.

Q: Как найти дубликаты в таблице? Сгруппировать по столбцам, в которых ищем дубликаты, и отфильтровать через HAVING COUNT(*) > 1. Для удаления дублей удобно использовать ROW_NUMBER() с PARTITION BY по ключевым столбцам и удалить строки, где номер больше 1.

Q: Что такое CTE и зачем он нужен? CTE (Common Table Expression) — именованный временный результат запроса, объявляемый через WITH. Он делает сложные запросы читаемыми, позволяет переиспользовать подзапросы и упрощает отладку. Подробнее — в статье про CTE.

Q: Как работает ROW_NUMBER() и чем отличается от RANK()? ROW_NUMBER() присваивает уникальный последовательный номер каждой строке в партиции. RANK() тоже нумерует, но при одинаковых значениях даёт одинаковый ранг и пропускает следующие номера. Например, при двух одинаковых значениях RANK даст 1, 1, 3, а ROW_NUMBER — 1, 2, 3. Подробнее — в шпаргалке по оконным функциям.

Q: Как посчитать нарастающий итог (cumulative sum)? Через оконную функцию SUM() OVER(ORDER BY ...) с фреймом ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW. Партицию выбирают в зависимости от задачи — например, PARTITION BY user_id для нарастающей суммы по каждому пользователю отдельно.

Q: Как найти вторую по величине зарплату в таблице? Через подзапрос с DENSE_RANK() OVER(ORDER BY salary DESC) и фильтром WHERE rank = 2. Альтернативный вариант — SELECT DISTINCT salary ORDER BY salary DESC LIMIT 1 OFFSET 1, но он менее надёжен при наличии дублей.

Q: Что такое оконная рамка (window frame) и зачем её указывать? Оконная рамка определяет, какие строки внутри партиции участвуют в вычислении — например, ROWS BETWEEN 6 PRECEDING AND CURRENT ROW для скользящего среднего за 7 дней. По умолчанию рамка включает все строки от начала партиции до текущей, что не всегда ожидаемо. Подробнее — в шпаргалке по оконным функциям.

Q: Как обработать NULL в агрегатных функциях? Большинство агрегатных функций (COUNT столбца, SUM, AVG) игнорируют NULL. Исключение — COUNT(*), который считает все строки. Если NULL критичен — используйте COALESCE для подстановки значения по умолчанию перед агрегацией.

Q: В каком порядке выполняются части SQL-запроса? Логический порядок: FROM, JOIN, WHERE, GROUP BY, HAVING, SELECT, DISTINCT, ORDER BY, LIMIT. Это объясняет, почему нельзя использовать алиас из SELECT в WHERE — WHERE выполняется раньше. Подробнее — в статье о порядке выполнения SQL-запроса.

Q: Как найти пользователей, которые совершили покупку два дня подряд? Через LAG(event_date) OVER(PARTITION BY user_id ORDER BY event_date) вычислить дату предыдущего события и отфильтровать строки, где разница между текущей и предыдущей датой равна 1 дню. Альтернативно — self-join таблицы по user_id и условию на разницу дат.

Q: Чем UNION отличается от UNION ALL? UNION удаляет дубликаты из результата, UNION ALL — нет. UNION ALL работает быстрее, потому что не требует сортировки и дедупликации. Используйте UNION ALL, если уверены, что дублей нет или они допустимы.

Q: Как посчитать retention Day 7 в SQL? Взять дату первого события пользователя (когорта), затем проверить, было ли событие ровно через 7 дней. Retention = количество вернувшихся / размер когорты. Нужно уточнять: Day-N (ровно на 7-й день) или Rolling (в любой день после 7-го). Подробнее — в статье про retention.

Q: Что такое индекс и когда он ускоряет запрос? Индекс — структура данных (обычно B-tree), которая ускоряет поиск по столбцу. Он полезен при фильтрации (WHERE), соединении (JOIN) и сортировке (ORDER BY). Но индексы замедляют вставку и обновление данных, а также занимают дополнительное место.

Q: Как написать запрос для расчёта конверсии воронки по шагам? Считаем количество уникальных пользователей на каждом шаге воронки и делим на количество пользователей на предыдущем шаге (или на первом). Удобно делать через CTE для каждого шага, затем объединить результаты. Подробнее — в статье про воронку конверсии.

Продуктовые метрики (10 вопросов)

Q: Что такое DAU, WAU, MAU и как они связаны? DAU — уникальные пользователи за день, WAU — за неделю, MAU — за месяц. Отношение DAU/MAU (stickiness) показывает, насколько часто пользователи возвращаются. У мессенджеров stickiness ~50%, у e-commerce — обычно 5-15%. Подробнее — в статье про метрики продукта.

Q: Чем отличается retention от churn? Retention — доля пользователей, которые вернулись через определённое время. Churn — доля тех, кто ушёл. Математически churn = 1 - retention, но считаться они могут по-разному в зависимости от определения «активности». Разбор формул — в статье про retention.

Q: Что такое unit-экономика и какие ключевые метрики в неё входят? Unit-экономика оценивает прибыльность на единицу (пользователя, заказ). Ключевые метрики: LTV (lifetime value), CAC (cost of acquisition), средний чек, маржинальность. Бизнес устойчив, если LTV > CAC. Подробнее — в статье про unit-экономику.

Q: Как декомпозировать выручку? Выручка = Количество пользователей x Конверсия в покупку x Средний чек x Среднее количество покупок. Декомпозиция позволяет найти, какой множитель просел. Можно декомпозировать глубже: по каналам, сегментам, регионам, когортам.

Q: Вчера DAU упало на 15%. Ваши действия? Сначала проверить данные — нет ли бага в трекинге или технического сбоя. Затем декомпозировать по платформам, каналам, регионам, сегментам и найти, где именно просадка. Проверить внешние факторы (сезонность, выходные) и внутренние (релизы, изменения). Подробный разбор — в статье про расследование падения метрик.

Q: Что такое North Star метрика и как её выбрать? North Star — главная метрика продукта, которая отражает ценность для пользователя и коррелирует с долгосрочным успехом бизнеса. Для маркетплейса это может быть количество завершённых заказов, для мессенджера — количество отправленных сообщений. Критерий выбора: метрика должна расти вместе с пользой для клиента.

Q: Что такое ARPU и ARPPU? ARPU — средний доход на пользователя (всех), ARPPU — средний доход на платящего пользователя. ARPU = Выручка / MAU, ARPPU = Выручка / Количество платящих. ARPU можно декомпозировать: ARPU = ARPPU x Доля платящих. Подробнее — в статье про метрики.

Q: Как выбрать метрику для оценки нового функционала? Метрика должна быть чувствительной (меняется при изменении фичи), интерпретируемой, быстро измеримой и непосредственно связанной с изменением. Также нужны guardrail-метрики — чтобы убедиться, что новая фича не ломает другие показатели. Подробнее — в статье про guardrail-метрики.

Q: Что такое когортный анализ и зачем он нужен? Когортный анализ группирует пользователей по времени первого действия и отслеживает их поведение со временем. Он позволяет увидеть, улучшается ли продукт от когорты к когорте, и не смешивать старых и новых пользователей. Подробнее — в статье про когортный анализ.

Q: Как отличить сезонное падение метрики от реальной проблемы? Сравнить с аналогичным периодом прошлого года (year-over-year). Если динамика повторяется — это сезонность. Дополнительно проверить: затронуло ли падение все сегменты равномерно (сезонность) или только конкретные (проблема). Также помогает декомпозиция — при сезонности структура трафика обычно не меняется.

A/B-тестирование и статистика (10 вопросов)

Q: Что такое p-value простыми словами? P-value — вероятность получить такой же или более сильный эффект случайно, если на самом деле разницы между группами нет. Если p-value < 0.05, мы считаем результат статистически значимым — то есть маловероятно, что эффект случаен. Подробнее — в статье про p-value.

Q: Что такое ошибки первого и второго рода? Ошибка первого рода (false positive) — решили, что эффект есть, а его нет. Внедрили бесполезную фичу. Ошибка второго рода (false negative) — решили, что эффекта нет, а он есть. Отклонили полезную фичу. Уровень значимости альфа контролирует первую ошибку, мощность (1 - бета) — вторую. Подробнее — в статье про проверку гипотез.

Q: Как рассчитать необходимый размер выборки для A/B-теста? Размер зависит от четырёх параметров: базовое значение метрики, MDE (минимальный детектируемый эффект), уровень значимости (обычно 0.05) и мощность (обычно 0.8). Чем меньше MDE хотим поймать, тем больше нужна выборка. Подробнее — в статье про размер выборки.

Q: Что такое MDE и почему его важно определить заранее? MDE (Minimum Detectable Effect) — минимальный эффект, который мы хотим зафиксировать. Если ожидаемое улучшение — 2%, а тест может поймать только 5%, мы рискуем пропустить реальный эффект. MDE определяет размер выборки и длительность теста — чем он меньше, тем дольше тест.

Q: Почему нельзя «подглядывать» в результаты A/B-теста до окончания? При многократной проверке вероятность случайно увидеть значимый результат растёт. Это называется peeking problem. Если проверять каждый день, шанс ложноположительного результата может вырасти с 5% до 30% и выше. Решение — зафиксировать срок теста заранее или использовать sequential testing. Подробнее — в статье про ошибки в A/B-тестах.

Q: Что такое статистическая мощность теста? Мощность — вероятность обнаружить реальный эффект, если он существует. Обычно закладывают мощность 80%. Это значит: если эффект реально есть и равен MDE, мы обнаружим его в 80% случаев. Повысить мощность можно увеличением выборки или применением методов снижения дисперсии, например CUPED.

Q: Когда использовать t-тест, а когда хи-квадрат? T-тест — для сравнения средних значений количественных метрик (средний чек, время на сайте). Хи-квадрат — для сравнения пропорций или категориальных данных (конверсия, доля кликов). Если метрика — процент/конверсия, обычно используют z-тест для пропорций или хи-квадрат.

Q: Что такое множественное тестирование и как с ним бороться? Если одновременно тестировать много гипотез (несколько метрик или вариантов), вероятность хотя бы одного ложноположительного результата возрастает. Для коррекции используют поправку Бонферрони (делить альфа на число сравнений) или метод Бенджамини-Хохберга. Подробнее — в статье про поправку на множественное сравнение.

Q: Что такое CUPED и зачем он нужен? CUPED — метод снижения дисперсии в A/B-тестах с использованием предэкспериментальных данных. Он вычитает из метрики ковариату (например, значение до эксперимента), что уменьшает шум и позволяет быстрее обнаружить эффект. Экономит до 50% времени теста. Подробнее — в статье про CUPED.

Q: Чем практическая значимость отличается от статистической? Статистическая значимость означает, что эффект не случаен. Практическая — что эффект достаточно большой, чтобы бизнесу было выгодно его внедрять. Рост конверсии на 0.01% может быть статистически значимым на большой выборке, но не окупит затраты на разработку.

Кейсы и продуктовое мышление (10 вопросов)

Q: Как бы вы спроектировали A/B-тест для нового алгоритма рекомендаций? Определить метрику успеха (CTR рекомендаций, конверсия в покупку, GMV на пользователя) и guardrail-метрики (время загрузки, возвраты). Единица рандомизации — пользователь. Рассчитать размер выборки под ожидаемый MDE. Длительность — не менее 1-2 недель, чтобы учесть дневные и недельные паттерны.

Q: Конверсия в покупку выросла, но выручка упала. Как такое возможно? Вероятно, снизился средний чек. Пользователи стали покупать чаще, но более дешёвые товары. Нужно декомпозировать: Выручка = Количество покупок x Средний чек. Проверить, не появилась ли акция или скидка, не изменилась ли товарная выдача.

Q: Как определить, какие пользователи находятся в группе риска оттока? Построить когорты и найти паттерны перед оттоком: снижение частоты визитов, уменьшение глубины сессий, прекращение ключевых действий. Затем сегментировать текущих активных пользователей по этим признакам. Для автоматизации можно построить модель на основе исторических данных об ушедших.

Q: Команда хочет запустить программу лояльности. Какие метрики отслеживать? Основные: retention участников vs. не-участников, LTV участников, частота покупок, средний чек. Guardrail: маржинальность (скидки не должны съедать прибыль), каннибализация (не покупают ли со скидкой то, что купили бы без неё). Долгосрочно — влияние на churn.

Q: На сайте A/B-тест показал рост CTR кнопки на 10%, но конверсия в целевое действие не изменилась. Что делать? CTR кнопки — промежуточная метрика. Рост кликов без роста конверсии означает, что привлечённые клики были «пустыми» — пользователи кликали, но не завершали целевое действие. Возможно, кнопка стала заметнее, но не релевантнее. Решение: смотреть на downstream-метрики, а не промежуточные.

Q: Как оценить эффект рекламной кампании, если нельзя провести A/B-тест? Использовать квази-экспериментальные методы: разница-в-разницах (diff-in-diff), синтетический контроль, пропенсити-скоринг. Например, сравнить регион, где была реклама, с похожим регионом без неё, учитывая предыдущую динамику.

Q: Как проверить, работает ли система рекомендаций лучше, чем случайная выдача? Сравнить метрики рекомендательной модели с бейзлайном (случайная выдача, популярные товары, ручная подборка). Offline: precision@k, recall@k, NDCG. Online: CTR рекомендаций, конверсия в покупку из рекомендаций, share of revenue из рекомендательного блока.

Q: Стоит ли оптимизировать онбординг, если 80% пользователей его проходят? Зависит от объёмов. 20% потерь при 100 000 новых пользователей в месяц — это 20 000 человек. Стоит посмотреть, кто именно отваливается: если это целевая аудитория, оптимизация окупится. Также проверить, как онбординг влияет на retention — возможно, 80% проходят, но не усваивают ценность продукта.

Q: Как бы вы построили дашборд для отслеживания здоровья продукта? Верхний уровень: North Star метрика, DAU/MAU, выручка. Средний: воронка конверсии по шагам, retention по когортам, распределение по платформам. Нижний: технические метрики (время загрузки, ошибки). Обязательно — сравнение с прошлым периодом и алерты на аномалии.

Q: Пользователи жалуются на поиск, но метрики поиска не упали. Как разобраться? Метрики могут не отражать реальный опыт. Проверить: какие именно запросы проблемные (long-tail запросы), нет ли survivorship bias (те, кто не нашёл, просто ушли и не учтены в метриках). Посмотреть zero-result rate, уточнения запроса, время до клика. Проанализировать тексты жалоб для выявления конкретных паттернов.

Soft skills и общие вопросы (5 вопросов)

Q: Менеджер просит «быстро посмотреть данные» без чёткого вопроса. Как действовать? Уточнить: какое решение он хочет принять на основе данных, какая гипотеза у него есть, какой срок. Без чёткого вопроса анализ превращается в бесконечный процесс. Предложить 2-3 конкретных среза, которые можно посмотреть быстро, и согласовать ожидания по формату результата.

Q: Как презентовать результаты анализа нетехнической аудитории? Начать с вывода и рекомендации, затем — ключевые цифры, потом — методологию (кратко). Использовать простые визуализации, избегать жаргона. Правило: если слайд нельзя понять за 5 секунд, он слишком сложный. Подробнее о выборе графиков — в статье про типы графиков.

Q: Вы нашли ошибку в данных, которые уже использовались для принятия решения. Что делать? Сообщить стейкхолдерам как можно скорее, описать масштаб ошибки и её влияние на выводы. Предложить исправленный анализ и оценить, меняет ли ошибка принятое решение. Не замалчивать — доверие к аналитику важнее, чем отсутствие ошибок.

Q: Как приоритизировать аналитические задачи, когда запросов больше, чем времени? Оценить каждый запрос по двум осям: влияние на бизнес-решение и срочность. Задачи, блокирующие запуск фичи или крупное решение, идут первыми. Регулярные отчёты можно автоматизировать. Ad-hoc запросы без чёткого решения — обсудить и, возможно, отложить.

Q: Расскажите о проекте, которым вы гордитесь. Структура ответа: контекст (какая была задача), действия (что именно вы сделали — какие данные собрали, какой анализ провели, какие инструменты использовали), результат (как это повлияло на бизнес — в цифрах). Хороший ответ содержит конкретные метрики: «сократили отток на 12%», «сэкономили 3 часа в неделю на ручных отчётах».

Потренируйтесь решать задачи для аналитиков данных в Карьернике — тренажёре для подготовки к собеседованиям. SQL, Python, статистика, продуктовые метрики и A/B-тесты — с объяснениями и проверкой.

FAQ

Какие этапы собеседования на аналитика данных?