Собеседование аналитика данных в Mytona: статистика и SQL

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

Что такое ошибки первого и второго рода

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

Представим эксперимент с новым экраном оплаты:

Решение	Реального эффекта нет	Реальный эффект есть
Изменение признали значимым	Ошибка первого рода	Верное обнаружение
Значимости не получили	Верное решение	Ошибка второго рода

Уровень значимости α ограничивает вероятность ошибки первого рода. Мощность теста 1 − β показывает вероятность обнаружить эффект заданного размера, если он действительно есть. Поэтому уменьшение одной ошибки обычно требует большей выборки или меняет риск другой.

Чем односторонний критерий отличается от двустороннего

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

Выбирать направление после просмотра данных нельзя: так исследователь подгонит правило под полученный результат. В библиотеке SciPy направление задаётся параметром alternative; документация прямо различает варианты less, greater и two-sided для t-теста независимых выборок.

Как отвечать. Сначала назвать проверяемую гипотезу, потом направление эффекта и только затем критерий. Фраза «односторонний смотрит на один хвост распределения» верна, но без условия выбора звучит неполно.

Как найти пользователей, которых нет в таблице читеров

Нужно вернуть игроков из основной таблицы, для которых нет строки с тем же user_id в списке читеров. Надёжный вариант — NOT EXISTS:

SELECT p.user_id, p.country_code
FROM players AS p
WHERE NOT EXISTS (
  -- Подзапрос проверяет наличие того же пользователя среди читеров.
  SELECT 1
  FROM cheaters AS c
  WHERE c.user_id = p.user_id
);

Альтернатива — LEFT JOIN и условие c.user_id IS NULL. Конструкция NOT IN требует осторожности: NULL в подзапросе способен привести к неожиданному результату. Сильный ответ также уточняет уникальность user_id во второй таблице и проверяет, не умножит ли соединение строки.

Как определить уровень первой покупки

У нас есть события прохождения уровней и покупки с временными метками. Сначала для каждого прохождения находим время следующего уровня через LEAD(). Затем выбираем первую покупку пользователя и связываем её с интервалом: покупка произошла не раньше текущего уровня и раньше следующего.

WITH level_intervals AS (
  SELECT
    user_id,
    level,
    completed_at,
    LEAD(completed_at) OVER (
      PARTITION BY user_id ORDER BY completed_at
    ) AS next_level_at
  FROM level_events
),
first_purchase AS (
  SELECT user_id, MIN(purchased_at) AS purchased_at
  FROM purchases
  GROUP BY user_id
)
SELECT l.level, COUNT(*) AS buyers
FROM level_intervals AS l
JOIN first_purchase AS p
  ON p.user_id = l.user_id
 AND p.purchased_at >= l.completed_at
 AND (p.purchased_at < l.next_level_at OR l.next_level_at IS NULL)
GROUP BY l.level
ORDER BY buyers DESC;

Оконная функция сохраняет отдельные события пользователя и добавляет к каждой строке вычисленное значение. Это удобнее ранней группировки, которая потеряла бы последовательность уровней.

Как раскрывать опыт продуктового аналитика

На вопрос об опыте лучше отвечать не перечнем инструментов, а рабочей историей:

1. Назвать продуктовый вопрос: например, почему игроки уходят до оплаты.
2. Уточнить выбранную метрику и источник данных.
3. Объяснить собственное действие: запрос, проверку качества, сегментацию или эксперимент.
4. Завершить измеримым результатом либо решением, которое приняла команда.

Так интервьюер понимает границы личной ответственности. Формулировка «работал с продуктовой аналитикой и SQL» этого не показывает.

Полезно заранее подготовить два разных кейса: один про регулярную аналитику, второй про неопределённую исследовательскую задачу. В каждом назовите исходные данные, спорное допущение и способ проверки. Тогда рассказ не рассыплется, когда интервьюер изменит условие или спросит, почему вы выбрали именно эту метрику.

Итог: получил бы кандидат оффер

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

Источники

• SciPy: t-test для независимых выборок
• PostgreSQL: оконные функции
• PostgreSQL: табличные выражения и JOIN