10 задач с реальных собеседований аналитика: полные разборы

Задачи на собеседованиях аналитиков повторяются. Меняются таблицы, продукты и цифры, но скелет остаётся: антиджойн, оконные функции, теорема Байеса, декомпозиция метрики. Кандидат, который решил десять задач с пониманием паттерна, узнает одиннадцатую — ту, которую дадут уже ему, — и соберёт решение на месте.

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

Какие задачи бывают на собесе аналитика

Секции интервью устроены предсказуемо. Вот карта: какие типы задач встречаются, какой паттерн за ними стоит и как часто их дают.

Три секции — SQL, метрики, A/B — образуют ядро подготовки. Статистику спрашивают глубже там, где команда живёт экспериментами; кейсы — везде, где аналитик работает с продуктом.

Задача 1. Купили iPhone, но не AirPods

По мотивам собеседования в Amazon. Секция: SQL, паттерн — антиджойн.

Условие. Есть таблица Orders(customer_id, product_name, order_date). Маркетинг хочет отправить предложение всем, кто купил iPhone, но так и не купил AirPods. Напишите запрос, который вернёт этих клиентов.

Решение. На языке множеств это разность: «купили iPhone» минус «купили AirPods». В SQL разность множеств называется антиджойном, и у него три канонических реализации. Самая чистая — NOT EXISTS:

SELECT DISTINCT o.customer_id
FROM Orders o
WHERE o.product_name = 'iPhone'
  AND NOT EXISTS (
    SELECT 1 FROM Orders a
    WHERE a.customer_id = o.customer_id
      AND a.product_name = 'AirPods'
  );

Работают и два других способа:

-- через EXCEPT
SELECT customer_id FROM Orders WHERE product_name = 'iPhone'
EXCEPT
SELECT customer_id FROM Orders WHERE product_name = 'AirPods';

-- через LEFT JOIN ... IS NULL
SELECT DISTINCT o.customer_id
FROM Orders o
LEFT JOIN Orders a
  ON a.customer_id = o.customer_id AND a.product_name = 'AirPods'
WHERE o.product_name = 'iPhone'
  AND a.customer_id IS NULL;

Типичные неверные ответы. Первый — фильтр WHERE product_name = 'iPhone' AND product_name != 'AirPods': условие смотрит на одну строку, а не на историю клиента, и второе неравенство всегда истинно там, где истинно первое. Второй — забытый DISTINCT: клиент с двумя айфонами придёт в рассылку дважды.

Ловушка. NOT IN с подзапросом. Если среди customer_id в подзапросе встретится хотя бы один NULL, весь запрос молча вернёт пустой результат — по семантике трёхзначной логики SQL сравнение с NULL даёт UNKNOWN. Ошибку не видно ни в синтаксисе, ни в плане запроса, поэтому интервьюеры любят её отдельным вопросом: «а что будет, если написать NOT IN?»

Вариации. «Клиенты, покупавшие в январе, но не покупавшие в феврале» (антиджойн по периодам), «пользователи, смотревшие товар, но не купившие» (антиджойн двух событийных таблиц), «сотрудники без заказов» из классических учебных схем. Скелет один и тот же.

Задача 2. Год жизни клиента после e-mail

По мотивам стажировки в Спортмастере. Секция: SQL, паттерн — когорта с индивидуальным окном.

Условие. Две таблицы: table_ident(id_client, ident_type, dat_inserted) — события указания контактов, и table_sales(id_client, id_check, sales, dat_check) — покупки. Посчитайте средний оборот на клиента и среднюю частоту покупок за год с момента, когда клиент впервые указал e-mail. Когорта — те, кто впервые указал e-mail в сентябре 2019.

Решение. Три шага: собрать когорту по первому событию, построить каждому клиенту его собственное годовое окно, агрегировать.

WITH first_email AS (
    SELECT id_client, MIN(dat_inserted) AS email_dt
    FROM table_ident
    WHERE ident_type = 'Email'
    GROUP BY id_client
    HAVING MIN(dat_inserted) >= DATE '2019-09-01'
       AND MIN(dat_inserted) <  DATE '2019-10-01'
),
client_year AS (
    SELECT f.id_client,
           COALESCE(SUM(s.sales), 0) AS revenue,
           COUNT(s.id_check)         AS purchases
    FROM first_email f
    LEFT JOIN table_sales s
      ON s.id_client = f.id_client
     AND s.dat_check >= f.email_dt
     AND s.dat_check <  f.email_dt + INTERVAL '1 year'
    GROUP BY f.id_client
)
SELECT AVG(revenue)   AS avg_revenue_per_client,
       AVG(purchases) AS avg_purchases_per_client
FROM client_year;

Ключевые решения в коде. Когорта определяется через MIN(dat_inserted) и HAVING — фильтр именно на первый e-mail, а не на любой: клиент, указавший почту в 2018-м и обновивший в сентябре 2019-го, в когорту не входит. Окно у каждого клиента своё — [дата e-mail; +1 год), а не календарный 2019 год.

Типичные неверные ответы. Фильтр WHERE dat_inserted BETWEEN '2019-09-01' AND '2019-09-30' без MIN — в когорту попадают повторные указания почты. Календарный год вместо индивидуального окна — у клиентов из конца сентября окно обрезается на три недели раньше, чем у клиентов из начала.

Ловушка. INNER JOIN с покупками. Он молча выкидывает клиентов, которые за год не купили ничего, и средний оборот считается только по купившим — оценка завышается, иногда в разы. Для честного среднего по всей когорте нужен LEFT JOIN и COALESCE(…, 0). Этот же выбор — считать по всем или по активным — стоит проговорить вслух: это продуктовое решение, а не техническое.

Вариации. Ретеншен когорт по месяцу регистрации, LTV за 90 дней от первой покупки, «средний чек в первые 30 дней после подписки». Любая задача со словами «за N дней с момента X» решается индивидуальным окном на клиента.

Задача 3. Разбей события на сессии

По мотивам собеседования в Учи.ру. Секция: SQL, паттерн — sessionization (gaps and islands).

Условие. Таблица events(user_id, event, timest). Добавьте колонку session_id: если между двумя действиями пользователя прошло больше 30 минут, это разные сессии, иначе — одна.

Решение. Классический приём «gaps and islands»; так сессии считают почти в каждом продуктовом хранилище, а 30-минутный таймаут — стандарт, унаследованный от Google Analytics. Три шага, каждый — своя оконная функция:

WITH lagged AS (
    SELECT user_id, event, timest,
           LAG(timest) OVER (PARTITION BY user_id ORDER BY timest) AS prev_ts
    FROM events
),
flagged AS (
    SELECT user_id, event, timest,
           CASE WHEN prev_ts IS NULL
                  OR timest - prev_ts > INTERVAL '30 minutes'
                THEN 1 ELSE 0 END AS is_new_session
    FROM lagged
)
SELECT user_id, event, timest,
       SUM(is_new_session) OVER (
           PARTITION BY user_id ORDER BY timest
       ) AS session_id
FROM flagged;

LAG даёт время предыдущего события того же пользователя. Флаг is_new_session равен единице на первом событии пользователя и на каждом событии после разрыва больше 30 минут. Накопительная сумма флагов и есть номер сессии: каждый разрыв увеличивает счётчик на один.

Типичные неверные ответы. Self-join таблицы самой на себя по условию «событие раньше и в пределах 30 минут» — квадратичная сложность и неверная логика на цепочках событий. Попытка обойтись одним ROW_NUMBER — номера строк не знают о разрывах.

Ловушка. LAG без PARTITION BY user_id подтянет событие чужого пользователя, и сессии склеятся между людьми. Вторая тонкость: полученный session_id уникален только внутри пользователя; для глобального идентификатора его склеивают с user_id — например, user_id || '-' || session_id.

Вариации. «Посчитайте среднюю длительность сессии» (к этому же запросу добавить MAX(timest) − MIN(timest) по сессии), «среднее число сессий на пользователя в день», «найдите пользователей с разрывом больше 30 минут хотя бы раз» (достаточно LAG и фильтра, без накопительной суммы). Тот же паттерн решает задачи про непрерывные серии: дни подряд с заходом в приложение, непрерывный стаж подписки.

Задача 4. Найди aha moment в продукте

По мотивам собеседования в Aviasales. Секция: продуктовые метрики, паттерн — поиск активационной метрики.

Условие. Что такое aha moment, как найти его в данных и что с ним делать дальше? Классический пример — «7 друзей за 10 дней» у Facebook.

Решение. Aha moment — раннее действие пользователя, после которого он остаётся в продукте заметно чаще. Формула Facebook прозвучала в выступлениях Чамата Палихапитии, который руководил ростом компании: новичок, набравший 7 друзей за первые 10 дней, с высокой вероятностью оставался. Slack публично называл порог в 2000 отправленных сообщений командой.

Методика поиска по шагам:

1. Зафиксировать outcome — например, ретеншен 30-го дня.
2. Для каждого новичка посчитать действия первых дней: сессии, поиски, добавления в избранное, подписки на цену.
3. Разбить пользователей на бакеты по числу действий: 0 / 1 / 2–5 / 6+.
4. Посмотреть, между какими бакетами ретеншен делает скачок — это кандидат в aha moment.
5. Перестроить онбординг так, чтобы вести новичка к найденному порогу.

Типичные неверные ответы. Пересказать формулу Facebook как универсальный ответ — у каждого продукта своё ключевое действие, и для сервиса авиабилетов оно будет про поиск и подписку на цену, а не про друзей. Второй слабый ответ — остановиться на поиске корреляции и не сказать, что с ней делать.

Ловушка. Корреляция не причина, и интервьюер ждёт, что вы скажете это сами. Активные пользователи и так лояльнее — действие может быть маркером мотивированного пользователя, а не причиной удержания. Проверка причинности — эксперимент: подтолкнуть случайную группу новичков к целевому действию (онбордингом, подсказками) и посмотреть, вырос ли их ретеншен относительно контроля. Если вырос — действие работает как рычаг; если нет — это был просто индикатор.

Вариации. «Какая activation-метрика у маркетплейса?», «как измерить time-to-value подписочного сервиса?», «после какого действия водитель такси перестаёт отваливаться?». Везде та же связка: outcome → ранние действия → бакеты → скачок → эксперимент.

Задача 5. Дашборд для запуска Stories

По мотивам собеседования в ВК. Секция: продуктовые метрики, паттерн — дерево метрик с приоритетами.

Условие. Вы продуктовый аналитик и отвечаете за «истории» в большой соцсети. Прошла пара месяцев после запуска, и вас просят собрать дашборд об успехе фичи. Какие метрики выведете и в каком порядке важности?

Решение. Сильный ответ — пирамида, а не плоский список. Сверху вниз:

1. North Star. Дневная аудитория Stories: пользователи, которые создали или посмотрели хотя бы одну историю за день.
2. Креаторы и зрители раздельно. Создаёт истории порядка 5% аудитории, смотрят — 95%. Слитая метрика размажет обе группы: рост зрителей замаскирует отток авторов, без которых лента историй опустеет.
3. Здоровье фичи. Доля досмотров, ответы на истории, среднее число просмотренных историй на зрителя.
4. Когорты adoption. «Опубликовал в неделю N — публикует ли в N+1»: удержание именно в фиче, отдельно от удержания в продукте.
5. Влияние на весь продукт. Время в приложении целиком, активность ленты до и после запуска.
6. Guardrails. Краши, скорость загрузки, жалобы.

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

Типичные неверные ответы. Список из двадцати метрик вперемешку — просмотры, лайки, DAU, краши — без иерархии. Ответ только про вовлечённость, без защитных метрик. Метрика «число опубликованных историй» как главная — она накручивается активностью малой доли авторов и не отражает ценность для зрителей.

Ловушка. Каннибализация. Stories могли откусить время у ленты, и общий engagement продукта не вырос — фича перекладывает внимание, а не создаёт новое. Пара метрик пятого уровня — «время в приложении целиком» и «активность ленты до/после» — закрывает этот вопрос. Кандидат, который сам называет каннибализацию, получает плюс до того, как о ней спросят.

Вариации. «Дашборд для запуска коротких видео», «метрики успеха нового раздела рекомендаций», «как поймёте, что голосовые сообщения удались?». Каркас пирамиды переносится без изменений; подробный разбор построения метрик успеха фичи — в статье метрики успеха фичи.

Задача 6. Какой баннер выкатывать?

По мотивам собеседования в МТС. Секция: A/B-тесты, паттерн — z-тест двух пропорций.

Условие. A/B-тест баннера на странице заявки на банковскую карту. Вариант A: 350 кликов из 2574 посетителей. Вариант B: 375 из 2855. Какой вариант предложите продакту и почему?

Решение. Сначала точечные оценки: CTR(A) = 350/2574 ≈ 13,6%, CTR(B) = 375/2855 ≈ 13,1%. Разница 0,5 п.п. в пользу A. Дальше — проверка, отличима ли она от шума. Объединённая доля p = 725/5429 ≈ 0,1335; стандартная ошибка разности:

SE = √(p(1−p)(1/2574 + 1/2855)) ≈ 0,0092

z = 0,0046 / 0,0092 ≈ 0,5, что даёт p-value ≈ 0,6. Доверительный интервал на разницу накрывает ноль с большим запасом. Честный ответ продакту: по этим данным выкатывать нечего — различие целиком укладывается в шум. Если выбрать всё равно нужно, выбирайте по нестатистическим критериям: стоимость поддержки, консистентность дизайна.

Бонус, который отличает сильного кандидата, — прикидка размера выборки. Чтобы поймать разницу 0,5 п.п. на базе 13% с мощностью 80% и уровнем значимости 5%, нужно порядка 70 000 человек на группу — в тридцать раз больше, чем собрали. Тест был обречён не увидеть эффект такого размера с самого начала.

Типичные неверные ответы. «Вариант A, у него CTR выше» — сравнение точечных оценок без проверки значимости; на этом сыплется заметная часть кандидатов. «Нужно больше данных» без числа — правильное направление, но интервьюер ждёт хотя бы порядок величины.

Ловушка. Интерпретация незначимого результата. p ≈ 0,6 не означает «варианты одинаковые» — это означает «данных недостаточно, чтобы различить». Отсутствие доказательства эффекта и доказательство отсутствия эффекта — разные утверждения; чтобы обосновать «различий нет», нужен тест эквивалентности с заранее заданной границей.

Вариации. Те же числа с просьбой посчитать доверительный интервал; вопрос «какой тест примените» (z-тест пропорций, χ²-тест — для таблицы 2×2 они эквивалентны); задача с p = 0,04 и просьбой объяснить, что это значит на самом деле.

Задача 7. p = 0,001, а радости нет

Типовой вопрос — встречается почти на каждом собесе по A/B. Секция: A/B-тесты, паттерн — статистическая против практической значимости.

Условие. A/B-тест на 5 миллионах пользователей: p-value = 0,001, но абсолютный прирост метрики +0,05% при базе 8%. Скажете команде выкатывать?

Решение. Здесь проверяют, различаете ли вы «эффект есть» и «эффект важен». p-value зависит от двух вещей: размера эффекта и размера выборки. На 5 миллионах пользователей статистически значимым становится почти любое ненулевое отличие — стандартная ошибка сжимается пропорционально √n, и микроскопический сдвиг вылезает за порог значимости.

Алгоритм решения о выкатке:

1. Сравнить наблюдаемый эффект с MDE, зафиксированным до теста. Если ждали +1%, а получили +0,05% — тест по своей же планке провален.
2. Перевести эффект в деньги на масштабе компании: +0,05% к конверсии при базе 8% — это +0,6% относительного прироста; сколько это в выручке за год?
3. Взвесить стоимость владения: разработка уже сделана, но фичу нужно поддерживать, она усложняет код и будущие тесты.

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

Типичные неверные ответы. «Конечно выкатывать, p-value же меньше 0,05» — механическое правило без экономики. «Не выкатывать, эффект маленький» без попытки перевести эффект в деньги — направление верное, аргументация пустая.

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

Вариации. Зеркальная постановка: «эффект +3%, но p = 0,12 — что делать?» (проверить мощность: возможно, тест недобрал выборку, и его стоит продлить или перезапустить); «продакт просит докрутить тест ещё пару дней до значимости» (проблема подглядывания — см. разбор ловушек A/B в шпаргалке по кейсам).

Задача 8. Тест положительный. Точно болен?

По мотивам стажировки в Авито. Секция: статистика, паттерн — теорема Байеса.

Условие. Болезнь есть у 1% населения. Тест находит её у больного с вероятностью 99%, а у здорового ошибочно срабатывает в 2% случаев. Тест показал положительный результат. Какова вероятность, что человек на самом деле здоров?

Решение. Интуиция подсказывает «процента два», правильный ответ — примерно 67%. Проще всего увидеть это без формул, через натуральные частоты. Возьмём 10 000 человек:

• больных — 100; тест поймает 99 из них;
• здоровых — 9900; тест ложно сработает у 2%, то есть у 198.

Всего положительных результатов: 99 + 198 = 297. Здоровых среди них 198. Итого P(здоров | тест+) = 198/297 = 2/3 ≈ 0,67.

Формально это теорема Байеса:

P(здоров | +) = P(+ | здоров)·P(здоров) / P(+) = (0,02 · 0,99) / (0,02 · 0,99 + 0,99 · 0,01) = 0,0198 / 0,0297 ≈ 0,667.

Механика контринтуитивности: болезнь редкая, поэтому даже маленький процент ложных срабатываний на огромной массе здоровых даёт больше плюсов, чем честные срабатывания на немногих больных. Психологи называют систематическую недооценку этого эффекта пренебрежением базовой частотой (base rate neglect).

Типичные неверные ответы. «2%» — кандидат перепутал P(тест+ | здоров) с P(здоров | тест+). «1%» — взял априорную вероятность и не обновил её. «99%» — прочитал чувствительность теста как ответ.

Ловушка. Сама постановка вопроса: спрашивают вероятность того, что человек здоров при положительном тесте, а в условии даны вероятности результатов теста при известном статусе. Перепутать направление условной вероятности — и есть главная ошибка; задачу любят именно за этот переворот.

Вариации. Антифрод-версия: «модель помечает мошенника с вероятностью 95%, ложно срабатывает в 1% случаев, мошенников 0,1% — сколько среди помеченных настоящих?». Задача Канемана и Тверски про такси (85% зелёных, 15% синих, свидетель прав в 80% случаев). Спам-фильтр с теми же ролями. Числа меняются, скелет 2×2 остаётся.

Задача 9. Аномальная погода в Фаренгейтах

По мотивам тестового в Сравни.ру. Секция: статистика, паттерн — линейное преобразование случайной величины и правило двух-трёх сигм.

Условие. Температура в Москве — случайная величина со средним 10 °C и стандартным отклонением 10 °C. День считается аномальным, если температура вышла за два стандартных отклонения от среднего. Назовите границы аномального дня в градусах Фаренгейта.

Решение. Сначала в Цельсиях: 10 ± 2·10, то есть норма от −10 до +30 °C. Затем перевод каждой границы по формуле F = C·9/5 + 32:

• нижняя: −10 · 9/5 + 32 = 14 °F;
• верхняя: 30 · 9/5 + 32 = 86 °F.

Аномальный день — холоднее 14 °F или жарче 86 °F.

Полезно проговорить и второй способ: перевести параметры распределения. Среднее: 10 · 9/5 + 32 = 50 °F. Стандартное отклонение: 10 · 9/5 = 18 °F — сдвиг на 32 к разбросу отношения не имеет. Границы: 50 ± 2·18 = [14; 86] °F. Ответы сошлись — хорошая самопроверка.

Типичные неверные ответы. Прибавить 32 до умножения на 9/5 — порядок операций. Перевести стандартное отклонение вместе со сдвигом: σ_F = 10·9/5 + 32 = 50 °F — и получить бессмысленные границы.

Ловушка. Поведение параметров при линейном преобразовании Y = aX + b: среднее преобразуется целиком (E[Y] = a·E[X] + b), стандартное отклонение — только масштабом (σ_Y = |a|·σ_X), дисперсия — квадратом масштаба (Var[Y] = a²·Var[X]). Сдвиг нуля шкалы не меняет разброс. На этом различии кандидаты сыплются чаще, чем на самом переводе градусов.

Вариации. «Дисперсия зарплат в рублях известна — какая в долларах?» (умножить на квадрат курса), «изменится ли корреляция, если одну из величин перевести в другие единицы?» (нет: корреляция инвариантна к линейным преобразованиям с положительным масштабом), «какая доля дней уложится в ±2σ, если распределение нормальное?» (правило 68–95–99,7: около 95%).

Задача 10. Выручка упала на 15%. Действия?

По мотивам собеседований в Озоне и Самокате. Секция: кейс, паттерн — декомпозиция метрики и локализация.

Условие. Понедельник. Дашборд показывает: вчера выручка просела на 15% к тому же дню недели месяц назад. Что будете делать?

Решение. Каркас: проверить данные → декомпозировать → локализовать → свериться с внешним → сообщить.

1. Данные. Первое подозрение всегда на сам дашборд: не доехал ETL, сместился часовой пояс, задвоились или потерялись платежи. Половина «падений» оказывается багом данных, а проверка — самая дешёвая: сверить выручку с независимым источником, например платёжным шлюзом.
2. Декомпозиция. Выручка = пользователи × конверсия × средний чек. Какой множитель просел? Это сужает поиск с «что угодно» до конкретного участка.
3. Локализация. Резать просевший множитель по независимым осям: платформа, гео, канал трафика, категория товара, новые/старые пользователи. Обычно 80% падения сидит в одном сегменте: упал только iOS — смотрите свежий релиз; только платный трафик — рекламный кабинет.
4. Внешнее. Праздники, погода, распродажа конкурента, сбой платёжного провайдера на рынке.
5. Финал. Короткое сообщение команде: где локализовано, какая гипотеза, кто чинит, какой алерт ставим.

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

Ловушка. Остановиться на первой оси. Падение iOS может жить только в новых пользователях, а «найденная» причина — объяснять треть падения. Найденные причины обязаны в сумме объяснять падение целиком; расследование без проверки суммы не закончено.

Вариации. «DAU упал на 10%», «конверсия просела после релиза», «GMV растёт, а выручка падает» (расследовать take rate отдельно от оборота). Полный алгоритм с разбором на цифрах — в статье «Метрика упала»: алгоритм и разбор с цифрами, каталог разложений метрик по бизнес-моделям — в статье о декомпозиции.

Что общего у этих десяти задач

Каждая задача проверяет паттерн, а не заученный ответ. Антиджойн из задачи 1 встретится в двадцати формулировках, sessionization из задачи 3 — в любой компании с событийной аналитикой, переворот условной вероятности из задачи 8 — в каждом вопросе про тесты, фрод и алерты. Готовиться стоит так: решить задачу, назвать паттерн вслух, придумать две вариации самостоятельно. Третья вариация — та, что попадётся на собеседовании.

Источники

• Ron Kohavi, Diane Tang, Ya Xu. Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing. Cambridge University Press, 2020 — стандартный справочник по экспериментам: мощность, MDE, интерпретация результатов.
• Документация PostgreSQL, раздел Window Functions — LAG, SUM ... OVER и паттерны оконных вычислений: https://www.postgresql.org/docs/current/tutorial-window.html
• Itzik Ben-Gan et al. T-SQL Querying. Microsoft Press, 2015 — глава о задачах gaps and islands, к которым относится sessionization.
• Evan Miller. How Not To Run an A/B Test, 2010 — о подглядывании и раздувании ложноположительных: https://www.evanmiller.org/how-not-to-run-an-ab-test.html
• Gerd Gigerenzer. Calculated Risks: How to Know When Numbers Deceive You. Simon & Schuster, 2002 — метод натуральных частот для байесовских задач, включая пример с медицинским тестом.
• Daniel Kahneman. Thinking, Fast and Slow. FSG, 2011 — пренебрежение базовой частотой и задача про такси.
• Выступление Чамата Палихапитии о росте Facebook (2012), где прозвучала формула «7 друзей за 10 дней».

Тренировка

Эти десять задач — разминка. В каталоге задач — 899 авторских задач по мотивам реальных собеседований аналитиков: SQL, метрики, A/B, статистика, Python и кейсы, с разборами и подводными камнями к каждой. Первые 5 разборов бесплатны — возьмите задачу из незнакомой секции и проверьте, узнаете ли паттерн.