Собеседование аналитика данных: SQL, A/B-тесты и кейс

Собеседование аналитика почти всегда собрано из одних и тех же блоков: SQL с экрана, статистика и A/B-тесты, немного Python и продуктовый кейс вроде «выручка упала на 10%, разберитесь». Вопросы повторяются от компании к компании. В банке Sobes это «Чем WHERE отличается от HAVING?», «Какие оконные функции использовал чаще всего? Чем RANK отличается от DENSE_RANK?», «Как анализировать падение метрики, с чего начать?». Последний спрашивали в 7 компаниях.

При этом сыплются чаще всего на SQL, а не на кейсе. По разборам собеседований пользователей Sobes тема «оконные функции SQL» оказалась слабой в 40% разборов, где её оценивали, «SQL и JOIN» в 39%. Для сравнения, A/B-тестирование проседает в 24%.

SQL: оконные функции и JOIN

Задачу обычно дают одну-две, пишете при интервьюере. Проверяют три вещи: знаете ли вы синтаксис без подсказки, понимаете ли, сколько строк вернёт запрос, и проверяете ли результат.

С JOIN главная ошибка одна: размножение строк. Вы соединяете заказы с платежами, у заказа два платежа, и сумма заказов удваивается. Перед тем как писать, скажите вслух, какая связь между таблицами: один к одному или один ко многим. Вопрос «Почему используется LEFT JOIN, а не другие типы JOIN?» проверяет то же самое: понимаете ли вы, какие строки потеряете при INNER.

С оконными функциями спотыкаются на трёх местах: разница между ROW_NUMBER, RANK и DENSE_RANK, рамка окна по умолчанию при ORDER BY и попытка отфильтровать по оконной функции в WHERE. Типовая задача «первый заказ каждого пользователя» решается так:

select user_id, order_id, created_at
from (
  select o.*,
         row_number() over (partition by user_id order by created_at) as rn
  from orders o
) t
where rn = 1;

Полезно сразу объяснить, зачем подзапрос: оконная функция считается после WHERE, поэтому фильтровать по ней можно только уровнем выше. Вопрос «Зачем нужны оконные функции в SQL и чем они отличаются от GROUP BY?» про то же: GROUP BY схлопывает строки, окно их сохраняет.

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

Статистика и A/B-тесты

Вопросы на определения: «Что такое нулевая гипотеза и альтернативная гипотеза?», «Какие типы статистических критериев ты знаешь?», «Где будут расположены медиана и среднее при правостороннем скошенном распределении?». За ними почти всегда идёт практический: «Расскажи о кейсе с A/B-тестом: какой это был тест и что ты в нём сделала?».

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

Тестировали новый экран оплаты. Главной метрикой взяли конверсию в оплату, заранее посчитали размер выборки под эффект в один процентный пункт, вышло две недели. Делили по пользователям, не по сессиям. Разница получилась в полпункта и незначимая, так что выкатывать не стали, но в сегменте новых пользователей эффект был заметнее, и следующий тест запустили только на них.

Здесь есть метрика, расчёт длительности до запуска, единица рандомизации и честный результат. Незначимый тест с понятным решением звучит убедительнее, чем «выросло на 30%».

Частые уточнения: почему нельзя остановить тест, как только увидели значимость, что делать с несколькими метриками сразу, когда A/B-тест провести нельзя.

Python и pandas

Для аналитика это обычно короткий блок: «Как отфильтровать DataFrame по одному условию?», «Как агрегировать значения по одному полю и одному показателю в Pandas?». Хватает уверенного владения groupby, merge, pivot_table, работы с датами и пропусками. Хороший приём: проговорить, как ту же задачу вы решили бы в SQL. Интервьюер видит, что вы понимаете операцию, а не помните метод.

Продуктовый кейс

Самый частый кейс про падение метрики. В банке он звучит так: «Если North Star метрика (количество успешных заказов) снижается, что делать?». Правильного ответа интервьюер не ждёт. Он смотрит на порядок действий:

Уточнить метрику: как считается, за какой период упала, по сравнению с чем.
Проверить данные: не сломался ли трекинг, не менялась ли логика расчёта, не задержалась ли загрузка.
Отсечь внешние причины: сезонность, праздники, акции конкурентов, сбой у платёжного провайдера.
Разложить метрику на множители. Заказы = посетители × конверсия в корзину × конверсия в оплату. Найти, какой множитель просел.
Разрезать по сегментам: платформа, версия приложения, регион, канал, новые и вернувшиеся.
Связать с изменениями: релизы, эксперименты, изменения цен.
Сформулировать гипотезу и сказать, как её проверить.

Начало хорошего ответа звучит так:

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

Кандидат сужает область поиска шаг за шагом, и каждый шаг можно проверить запросом.

Как вести кейс вслух

Кейс чаще проваливают из-за молчания и догадок, чем из-за незнания метрик. Несколько правил:

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

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

Как отрепетировать

SQL репетируется только руками. Решайте задачи на окна и JOIN в SQL-тренажёре без автодополнения и объясняйте вслух, сколько строк вернёт запрос. Теорию по статистике пройдите по вопросам разделов аналитики данных и продуктовой аналитики: ответ вслух на минуту, с примером.

Кейс удобно тренировать в мок-интервью: там есть режим кейс-интервью с задачами по аналитике. Разговор ведёте вы, а интервьюер выдаёт факты только на точный вопрос. Если спросить «что случилось?», ответа не будет. Если спросить «как изменилась конверсия в оплату на Android за последнюю неделю?», вы получите цифру. Это хорошо отучает от привычки гадать вместо того, чтобы спрашивать. В разборе после кейса видно, какие факты вы так и не запросили.

Какие ещё темы чаще всего подводят кандидатов, собрано в статье о том, на чём проваливаются на собеседованиях.