Материал Эйч · Опубликовано 21 июля 2026
Middle-аналитик в команду отельного метапоиска: SQL, A/B-тесты, дашборды и работа с данными в условиях неопределённости
Фишка: Команда Hotels — отдельный продуктовый юнит внутри Авиасейлс с высокой скоростью изменений: аналитик часто работает с новыми механиками отельного метапоиска, ad-hoc запросами от маркетинга и финансов, а также балансирует качество данных и скорость выкатки.
| Этап | Длительность | Что проверяют |
|---|---|---|
| Скрининг / HR | 30–45 мин | Мотивация, опыт 3+ лет в продуктовой аналитике, формат удалённой работы, ожидания по зарплате, интерес к travel-продуктам |
| Техническое интервью | 60–90 мин | SQL (сложные запросы, оконные функции, оптимизация), Python, A/B-тесты, ratio-метрики, ClickHouse vs OLTP |
| Продуктовое / кейсовое | 60 мин | Дизайн эксперимента, выбор метрик для отельного метапоиска, разбор падения конверсии, ad-hoc исследования при неполных данных |
| Финал с командой | 45–60 мин | Культурный fit, работа в кросс-функциональной команде Hotels, компромисс между качеством данных и time-to-market, вопросы к команде |
Обязательный минимум
Плюсом будет
Была ли необходимость оптимизировать запросы?
Опиши кейс: EXPLAIN, индексы, переписывание JOIN → CTE, денормализация, партиционирование. Для Авиасейлс релевантен ClickHouse.
В чём разница между ClickHouse и MySQL?
MySQL — OLTP, строковое хранение, транзакции. ClickHouse — OLAP, колоночное хранение, быстрые агрегации по большим объёмам. В метапоиске аналитика обычно на ClickHouse/аналогах.
Работал ли с ClickHouse?
Если да — примеры агрегаций, MATERIALIZED VIEW, работа с event-логами. Если нет — покажи понимание OLAP vs OLTP и готовность быстро освоить.
Совет: В travel-продукте часто работают с event-логами (поиск → выдача → клик → бронирование). Покажи, что умеешь строить воронки через SQL.
Ловушка: Не путай COUNT(DISTINCT user_id) и COUNT(*) при расчёте конверсий — это частая ошибка на техническом.
Какие A/B-тесты проводил?
Структура ответа: гипотеза → метрики (primary + guardrail) → дизайн (split unit, размер выборки) → результат → решение.
Как будешь находить статистическую значимость конверсии между группами A и B?
Z-test / chi-square для пропорций. Для ratio-метрик — bootstrap или delta-method, не простой t-test по пользователям.
Как будешь валидировать результат A/B теста?
Проверь: корректность split (SRM), длительность, сезонность, новизну эффекта, guardrail-метрики, сегменты, множественное тестирование.
Зависит ли числитель от знаменателя в ratio-метрике?
Да — это ratio (orders/sessions, revenue/users). Нельзя применять t-test к среднему ratio без bootstrap/delta-method.
В чём разница между ratio-метрикой и не ratio-метрикой для средних значений?
Средний чек на пользователя — ratio (sum/sum). Среднее время сессии — не ratio, можно t-test/Mann-Whitney.
Когда использовал Mann-Whitney вместо t-теста?
При ненормальных распределениях, выбросах, малых выборках. Для конверсий — z-test/chi-square, не t-test.
Достаточно ли того, что оба распределения нормальные?
Нет — нужна ещё независимость наблюдений, равенство дисперсий (или Welch), корректный unit of randomization.
Всегда ли вырастет конверсия, если она выросла в A/B тесте?
Нет — возможны Simpson's paradox, novelty effect, сезонность, неполный период, некорректный split.
Будешь делать split по чатам или по пользователям?
Unit of randomization = пользователь (или device/session для web). Split по сущности, на которую влияет фича.
Как реализуется дизайн теста?
MDE → power analysis → sample size → randomization → exposure window → primary metric → stopping rules.
Были ли стратегии принятия решения в последнем A/B тесте?
Pre-defined criteria: stat sig + практическая значимость + guardrails OK + нет негатива в сегментах.
Фишка: В Hotels команда активно проводит A/B-тесты новых механик метапоиска — жди глубоких вопросов по дизайну экспериментов.
Ловушка: Peeking (остановка теста при первой значимости) — частая ловушка. Объясни, как фиксируешь длительность заранее.
В чём разница между ARPPU и GMV?
GMV — общий объём транзакций (gross). ARPPU — средняя выручка на платящего пользователя. GMV ≠ revenue (комиссии, отмены).
Что такое CR1?
Conversion Rate первого шага воронки (например, search → results). Уточни определение CR на каждом этапе.
Для каждой ли метрики характерна сезонность?
Нет — DAU/конверсии в travel сильно сезонны (каникулы, праздники), технические метрики (latency) — нет.
В чём разница между приёмочной и информационной метрикой?
Primary (acceptance) — по ней принимаем решение. Informational — контекст, guardrails, не для go/no-go.
В чём разница между web-аналитикой и мобильной аналитикой?
Разные SDK, session model, attribution (install vs web cookie), offline events, push/deeplinks.
В чём разница между путём клиента в web и в мобильном приложении?
Web: cookie/session, referrer. App: install attribution, push, background sessions, deeplinks.
Будет ли относиться метка к каналу установки, если пользователь запустит сессию через 40 дней после установки?
Зависит от attribution window (обычно 7–30 дней). После окна — organic или last-touch.
В какой период проводится тест для DAU?
Минимум полный цикл (часто 1–2 недели), учитывая day-of-week эффект и сезонность.
Совет: Для отельного метапоиска ключевые метрики: search-to-click, click-to-partner, booking conversion, revenue per search, supplier coverage, price competitiveness.
Фишка: Travel — сильная сезонность. На собесе могут спросить, как учитываешь сезонность при анализе экспериментов и дашбордов.
Какие задачи решал на Python?
pandas/numpy: очистка event-логов, cohort analysis, bootstrap A/B, автоматизация отчётов, anomaly detection.
Совет: Базовый ML в вакансии — скорее сегментация, кластеризация, простые прогнозы. Не жди deep learning, но покажи pandas + scipy/statsmodels.
Как коммуницировать с разработкой при расхождении в данных?
Воспроизводимый кейс: SQL-запрос, sample rows, timeline, гипотеза (дубли, timezone, late events), приоритет vs time-to-market.
Фишка: В вакансии прямо указано: задачи по качеству данных будут, но не массово. Покажи опыт расследований без перфекционизма.
Совет: Ad-hoc от маркетинга и финансов — типичный сценарий. Покажи, как структурируешь запрос, уточняешь определения метрик и даёшь actionable ответ.
SQL: воронка отельного поиска
Есть таблицы: searches (search_id, user_id, ts, destination), results (search_id, hotel_id, position, price), clicks (search_id, hotel_id, user_id, ts), bookings (click_id, user_id, revenue, ts). Напиши SQL для расчёта конверсии search → click → booking за последние 7 дней с разбивкой по платформе (web/app).
WITH funnel AS (
SELECT s.search_id, s.platform,
MAX(CASE WHEN c.search_id IS NOT NULL THEN 1 ELSE 0 END) AS has_click,
MAX(CASE WHEN b.click_id IS NOT NULL THEN 1 ELSE 0 END) AS has_booking
FROM searches s
LEFT JOIN clicks c ON c.search_id = s.search_id
LEFT JOIN bookings b ON b.click_id = c.click_id
WHERE s.ts >= NOW() - INTERVAL '7 days'
GROUP BY s.search_id, s.platform
)
SELECT platform,
COUNT(*) AS searches,
SUM(has_click)::float / COUNT(*) AS cr_search_to_click,
SUM(has_booking)::float / COUNT(*) AS cr_search_to_booking
FROM funnel
GROUP BY platform;Сложность: O(n) с индексами на search_id, ts
A/B-тест: новая сортировка отелей
Продукт хочет изменить алгоритм сортировки отелей в выдаче. Primary metric — click-through rate (CTR) на первые 5 позиций. Guardrail — overall booking conversion и revenue per search. Как спроектируешь эксперимент?
1) Unit: user_id (sticky assignment). 2) Split 50/50, stratified по platform. 3) Primary: CTR top-5 = clicks_top5 / searches_with_results. 4) Guardrails: booking CR, revenue/search — не должны падать >2% относительно. 5) MDE ~3% для CTR, power 80%, α=0.05 → ~2 недели при текущем traffic. 6) Фиксированная длительность, без peeking. 7) Анализ: z-test для CTR (ratio → bootstrap), проверка SRM, сегменты web/app. 8) Rollout decision: primary sig + guardrails OK + нет негатива в mobile.
Сложность: N/A (дизайн)
Кейс: падение конверсии в бронирования
За последнюю неделю booking conversion упала на 15% при стабильном search volume. Как будешь расследовать?
1) Проверить data pipeline (late events, broken tracking). 2) Декомпозиция воронки: search→results→click→partner→book — где именно просадка. 3) Сегменты: platform, geo, supplier, new vs returning. 4) Корреляция с релизами, A/B-тестами, сезонностью. 5) External: supplier outages, price changes. 6) SQL + dashboard drill-down. 7) Actionable report с root cause и рекомендацией.
Сложность: N/A (анalytical case)
3 дня
7 дней
14 дней
| Блок | Готов, если... |
|---|---|
| SQL | можешь написать funnel query с JOIN/CTE и объяснить оптимизацию |
| A/B-тесты | можешь спроектировать эксперимент с primary/guardrail метриками и объяснить ratio-метрики |
| Метрики | различаешь GMV/revenue/ARPPU, понимаешь seasonality в travel |
| Python | можешь описать типовой pipeline: extract → clean → analyze → visualize |
| Кейсы | можешь структурированно расследовать падение конверсии за 5 шагов |
| Behavioral | есть 2 STAR-истории про A/B-тест и работу с данными в неопределённости |
В день собеседования