На Middle-собеседовании аналитика данных в Betcore проверяли опыт продуктовых исследований, SQL, устройство аналитического контура, вероятность, A/B-тесты и действия при сбое данных. Кандидат уверенно начал рассказ о работе, но не смог раскрыть несколько процессов и потерялся на базовых вопросах заявленного уровня.
Как рассказать об опыте и продуктовом исследовании
Сильный ответ строится вокруг конкретного решения, а не списка задач. Например: «Продукт заметил падение повторных покупок. Я проверил воронку по когортам, нашёл провал после первой доставки, исключил ошибки трекинга и передал сегменты для исследования причин». Здесь понятны вопрос, метод, личное действие и следующий шаг.
Если задача приходит от нескольких ролей, стоит описать процесс приоритизации: кто формулирует бизнес-вопрос, кто принимает результат и как фиксируются критерии готовности. Фраза «задачи приходят от всех» заставляет сомневаться, что процесс действительно знаком кандидату.
Как связаны JOIN, UNION, WHERE, HAVING и окна
JOIN соединяет столбцы связанных таблиц. UNION ALL добавляет строки одного совместимого результата к другому, а UNION дополнительно удаляет дубликаты. Поэтому UNION ALL обычно дешевле, если дедупликация не нужна. Это различие закреплено в документации PostgreSQL.
WHERE отбирает строки до группировки. HAVING фильтрует уже сформированные группы, поэтому там удобно проверять COUNT(*) или SUM(amount). Оконная функция не схлопывает строки: она добавляет вычисление внутри окна.
Для последней записи по каждому id подходит:
WITH ranked AS (
SELECT
id,
name,
created_at,
-- Самая новая запись каждого id получает номер 1.
ROW_NUMBER() OVER (
PARTITION BY id ORDER BY created_at DESC
) AS row_num
FROM source_data
)
SELECT id, name, created_at
FROM ranked
WHERE row_num = 1;
Если одинаковые временные метки возможны, добавляем стабильный второй ключ сортировки. Без окон можно найти MAX(created_at) по id и соединить результат с исходной таблицей, но дубликаты максимальной даты тоже придётся обработать.
В финальной задаче со ставками важно было сначала исключить записи со статусом declined, затем посчитать количество непустых ставок и оборот по каждому пользователю. Для «трёх крупнейших покупок каждого пользователя» применяется похожий ROW_NUMBER() с сортировкой суммы по убыванию.
Чем таблица отличается от VIEW
Обычная таблица хранит строки. Представление VIEW хранит определение запроса и при обращении получает актуальный результат из исходных объектов. Материализованное представление отдельно сохраняет вычисленный результат и требует обновления.
VIEW помогает переиспользовать сложную логику и ограничивать доступ к столбцам, но не делает тяжёлый запрос быстрым автоматически. Перед соединением с представлением полезно посмотреть его определение и план выполнения. Официальный синтаксис и свойства собраны в разделе CREATE VIEW.
Что нужно знать про ClickHouse, Greenplum и Airflow
Когда данные идут из событийного ClickHouse в витрины Greenplum, аналитик должен видеть хотя бы четыре слоя: источник, преобразование, оркестрацию и контроль результата. Airflow описывает процесс как DAG из задач и зависимостей; это не транспорт данных сам по себе. Архитектура Airflow отделяет планирование, обработку DAG и выполнение задач.
DAG задаёт порядок работ, а компоненты Airflow планируют и выполняют отдельные задачи. Источник: Apache Airflow.
В ClickHouse выбор движка определяет хранение и слияние частей. Базовое семейство MergeTree использует ключ сортировки, партиции и фоновые слияния; варианты семейства решают отдельные задачи дедупликации и агрегации. Это подробно описано в документации ClickHouse.
Как решить задачу с перебросом кубика
После первого броска можно оставить значение или один раз перебросить. Ожидаемое значение второго броска равно 3,5. Значит, 1–3 выгодно перебросить, а 4–6 — оставить.
Половина первых бросков даёт среднее (4 + 5 + 6) / 3 = 5. В другой половине мы перебрасываем и в среднем получаем 3,5. Общий ожидаемый выигрыш:
0,5 × 5 + 0,5 × 3,5 = 4,25.
Сильный ответ включает и порог решения, и итоговое матожидание. Просто назвать среднее значение кубика недостаточно.
Что влияет на длительность A/B-теста
Сначала задают основную метрику, нулевую гипотезу, уровень значимости α, мощность 1 − β и MDE. Затем по базовому уровню и разбросу метрики считают необходимую выборку. Инструменты расчёта мощности и размера выборки собраны в statsmodels.
Тест длится дольше, когда:
- MDE меньше;
- разброс метрики выше;
- требования к мощности и значимости строже;
- трафика меньше или в эксперимент попадает только его часть.
Одного p-value мало: нужен доверительный интервал и оценка практической пользы. Статистически заметное изменение может быть слишком маленьким для бизнеса.
Как восстанавливать сломанную аналитику
Сначала проводится триаж: когда пришли последние данные, какие пайплайны упали, какие партиции пропущены и какие отчёты затронуты. Приоритет получают заказы, платежи, возвраты и справочники — без них нельзя восстановить деньги и обязательную отчётность. События кликов и воронки идут следом.
Дальше команда устраняет причину, запускает бэкфил, удаляет дубли и проверяет контрольные суммы, объёмы и свежесть. Только после этого обновляют дашборды и сообщают пользователям, какой период восстановлен.
Итог: почему кандидат не получил оффер
В исходном материале результат назван прямо: собеседование было провалено. Это согласуется с профессиональными ответами. Кандидат не знал UNION, разницу таблицы и VIEW, движки ClickHouse и факторы размера A/B-теста; задачу на матожидание решил только после подробных подсказок. Отдельные SQL-вопросы он закрывал хорошо, но для Middle-уровня пробелы оказались слишком широкими.
Зато план подготовки здесь конкретный: восстановить SQL-базу, руками собрать DAG с проверками качества, повторить устройство ClickHouse и решить серию задач по вероятности и экспериментам.
Источники
частые вопросы
Короткие ответы
Какой SQL должен знать Middle-аналитик данных?
JOIN, подзапросы и CTE, агрегаты, оконные функции, операции над множествами, NULL, порядок выполнения запроса и способы проверить результат.
Нужно ли аналитику знать движки ClickHouse?
Если ClickHouse указан как рабочая система, нужно понимать хотя бы семейство MergeTree, ключ сортировки, партиции и влияние движка на обновления и дедупликацию.
Как отвечать, если практического опыта с темой нет?
Честно обозначьте границу опыта, дайте известное определение и покажите ход проверки. Это лучше, чем приписывать себе процесс, который не получается объяснить.
