Материал Эйч · Опубликовано 27 октября 2026
Стажировка в продуктовой аналитике телеком-приложения с DAU 4–5 млн: SQL, Python, A/B-тесты и знакомство с ETL
Фишка: Контекст крупного телеком-оператора: большие объёмы пользовательских событий, продуктовая аналитика внутри «Мой МТС», внутренняя платформа MTS Ocean и гильдии инженеров — на собесе часто проверяют, сможете ли вы мыслить метриками приложения и корректно писать SQL под «грязные» срезы данных.
| Этап | Длительность | Что проверяют |
|---|---|---|
| Скрининг / HR | 20–30 мин | Мотивация, формат работы (гибрид/офис, Москва), сроки обучения, базовые ожидания по стеку (SQL, Python) |
| Техническое интервью | 60–90 мин | SQL на реальных телеком-сценариях (абоненты, продажи, интервалы действия записей), матстат и A/B, иногда продуктовые кейсы и логика |
| Финал / команда | 30–60 мин | Соответствие продукту «Мой МТС», рекомендации и поиск в приложении, готовность к стажёрским задачам |
Обязательный минимум
Плюсом будет
Таблицы product (категория продукта в интервале eff_dt–exp_dt) и sale (дата, продукт, цена, количество). Напишите запрос: выручка по каждой категории.
JOIN sale к product по prod_nm и условию sale_dt BETWEEN eff_dt AND exp_dt; выручка = SUM(price * cnt); GROUP BY prod_cat.
Как отнести продажи продуктов, не попавших ни в одну категорию, к категории «Прочее»?
LEFT JOIN + COALESCE(prod_cat, 'Прочее') или UNION с отдельным блоком для несматченных sale.
Как оставить только категории с суммарной выручкой больше 100?
GROUP BY + HAVING SUM(...) > 100; WHERE фильтрует строки до группировки, HAVING — группы после.
Какой символ после SELECT выбирает все столбцы?
Звёздочка: SELECT * FROM ...
Ловушка: Продукт мог менять категорию во времени — без проверки даты продажи в интервале действия категории суммы будут неверны.
Совет: Проговорите вслух: ключ джойна, условие на дату, формула выручки, затем агрегация.
Таблица abnt с полем raw_dt. Вернуть предпоследнюю по времени загрузки запись для каждого id.
ROW_NUMBER() OVER (PARTITION BY id ORDER BY raw_dt DESC), затем WHERE rn = 2.
История абонента: valid_from_dt, valid_to_dt; следующая запись начинается в день закрытия предыдущей. Найти записи с некорректной датой закрытия.
Сравнить valid_to_dt с LEAD(valid_from_dt) по id ORDER BY valid_from_dt; искать разрывы, пересечения и valid_to < valid_from.
Будут ли отличаться: LEFT JOIN ... ON A.id = B.id AND B.val = 'A' vs тот же JOIN с WHERE B.val = 'A'?
Да. Условие в ON сохраняет все строки A; в WHERE отфильтрует NULL справа и превратит LEFT JOIN в INNER по сути для отобранных.
Фишка: Типичный телеком-кейс МТС: msisdn, тариф, account_id и срезы по времени — проверяют умение работать с дедупликацией и версионностью.
Ловушка: Путают rn = 2 с OFFSET 1 без явного ORDER BY — порядок должен быть зафиксирован полем raw_dt.
Знаете ли математическую статистику и применяли A/B на практике? Какие виды средних знаете?
Среднее, медиана, мода; в A/B — гипотеза, метрика, α, MDE, длительность, проверка рандомизации, интерпретация p-value и CI, не подглядывать до конца теста.
Совет: Для «Мой МТС» уместно связать A/B с UI: баннер, поиск, рекомендация — одна первичная метрика и guardrail-метрики (отток, время загрузки).
Ловушка: Путать статистическую и практическую значимость; забывать про множественные сравнения при нескольких метриках.
Алгоритм определения дня рождения абонента только по журналу звонков и SMS (номера, время, длительность, тип).
Точной даты нет — только вероятность: всплески входящих в один календарный день по годам, исключение шума, скоринг дат; этика и отсутствие текста SMS.
По звонковому трафику и геолокации каждые 15 минут определить, живут ли два абонента вместе.
Совместные временные окна в одной геозоне + ночные совпадения; метрика доли совместных слотов; пороги и ложные срабатывания (работа, поездки).
Фишка: Проверяют не готовый ML, а декомпозицию: данные → признаки → правило/скор → ограничения и ошибки.
Три лампы и три выключателя снаружи, в комнату — один раз. Как сопоставить выключатель и лампу?
Включить один, подождать (нагрев), выключить, включить второй, зайти: горячая/горит/выкл.
Сосуды 3 и 5 литров, отмерить 4 литра.
Наполнить 5, перелить в 3 (остаётся 2), вылить 3, перелить 2 в 3, снова наполнить 5 и долить в 3 до верха — в 5 останется 4.
Два заключённых угадывают монету соседа. Стратегия на 100% выживания?
Классика: один называет результат второго так же, как свою монету; второй — противоположное своей.
Приходилось работать с Git?
Кратко: clone, branch, commit, push, merge/PR; зачем версионирование в аналитике (скрипты, SQL).
Совет: На головоломках озвучивайте допущения и план, а не молчите.
Выручка по категориям с интервалами
Даны product(prod_nm, prod_cat, eff_dt, exp_dt) и sale(sale_dt, prod_nm, price, cnt). Вернуть prod_cat и total_amt = сумма price*cnt по каждой категории с учётом актуальной категории на дату продажи.
SELECT p.prod_cat, SUM(s.price * s.cnt) AS total_amt FROM sale s JOIN product p ON s.prod_nm = p.prod_nm AND s.sale_dt BETWEEN p.eff_dt AND p.exp_dt GROUP BY p.prod_cat;
Сложность: O(n log n) при сортировке; линейно по объёму после join
Предпоследняя запись по raw_dt
Таблица abnt(id, msisdn, tarif_plan_id, account_id, raw_dt). Для каждого id вернуть строку с предпоследней датой загрузки.
WITH ranked AS ( SELECT *, ROW_NUMBER() OVER (PARTITION BY id ORDER BY raw_dt DESC) AS rn FROM abnt ) SELECT id, msisdn, tarif_plan_id, account_id, raw_dt FROM ranked WHERE rn = 2;
Сложность: O(n log n) на партицию
Некорректное закрытие периода абонента
Для каждого id цепочка [valid_from_dt, valid_to_dt]. Следующая запись начинается в день valid_to_dt предыдущей. Найти записи с ошибкой в датах.
WITH nxt AS ( SELECT *, LEAD(valid_from_dt) OVER (PARTITION BY id ORDER BY valid_from_dt) AS next_from FROM abnt ) SELECT * FROM nxt WHERE valid_to_dt < valid_from_dt OR (next_from IS NOT NULL AND valid_to_dt <> next_from);
Сложность: O(n log n)
3 дня
7 дней
14 дней
| Блок | Готов, если... |
|---|---|
| SQL и окна | можете за 15 мин написать выручку по категориям с датами и запрос с rn=2 без синтаксических ошибок |
| A/B и статистика | объясняете цель теста, одну primary-метрику и почему нельзя останавливать тест рано |
| Продуктовые кейсы | декомпозируете задачу на шаги и называете ограничения данных |
| Логика | решаете задачу с лампами и сосудами, проговаривая ход |
| Мотивация | связываете интерес с продуктовой аналитикой в крупном B2C-приложении |
В день собеседования
