Материал Эйч · Опубликовано 27 октября 2026
Middle/Senior: витрины данных, SQL/Python, Airflow, Spark, качество данных и пайплайны в масштабе e-commerce
Фишка: RWB — объединение Wildberries и Russ: высокие нагрузки маркетплейса, много источников (API, Excel, разные СУБД), сильный акцент на собственные пайплайны, витрины и контроль качества данных.
| Этап | Длительность | Что проверяют |
|---|---|---|
| Скрининг / HR | 30–45 мин | Опыт 3+ лет, мотивация, формат работы (гибрид, Москва), соответствие стеку SQL/Python/Airflow |
| Техническое интервью | 60–90 мин | SQL (окна, джойны, оптимизация), Python/pandas, задачи на логику данных, базовая статистика |
| Углублённое / с лидом | 60 мин | Пайплайны, Spark, моделирование таблиц, DQ-чекеры, кейсы переноса данных между системами |
| Финал (опционально) | 30–45 мин | Поведенческие вопросы, взаимодействие с разработкой и заказчиками, приоритизация ad hoc |
Обязательный минимум
Плюсом будет
Для каждого пользователя из Москвы вывести последний заказ и процент применённой скидки (orders: order_id, created_dt, user_id, price, discount; users: id, reg_date, city).
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_dt DESC). Процент: discount/price*100, если discount — сумма; уточни семантику полей.
Средний чек по городам и среднее число заказов на пользователя за первый квартал текущего года.
Фильтр по дате Q1, JOIN users+orders, GROUP BY city; средний чек = SUM(price-discount)/COUNT(orders) или по net; заказов на пользователя — COUNT/COUNT(DISTINCT user_id).
Как оптимизируешь тяжёлый запрос к витрине на Greenplum/ClickHouse?
Партиции, предагрегации, избегать SELECT *, фильтры по partition key, explain, распределение данных в MPP.
Ловушка: Путают price до/после скидки и считают процент скидки неверно — всегда проговори допущения.
Совет: На собесе полезно вслух: гранулярность результата, индексы/партиции, идемпотентность пересчёта витрины.
Напиши код на Python: средний чек по городам и среднее число заказов на пользователя за Q1 (те же таблицы).
pandas: merge, фильтр дат, groupby('city').agg; следи за timezone и границами квартала.
Как автоматизируешь загрузку из Excel/API в КХД?
Валидация схемы, staging, идемпотентность, логирование, Airflow task, обработка частичных сбоев.
Фишка: В вакансии явно: ad hoc автоматизации и внутренние решения — готовь 1–2 коротких примера из опыта (без персональных деталей на гайде: структура «проблема → скрипт/DAG → метрика успеха»).
Как устроен типичный DAG загрузки витрины?
extract → validate → transform → load → DQ checks → notify; зависимости, catchup, sensors.
Какие чекеры Data Quality настраивали?
row count vs источник, NULL в ключах, дубли по business key, freshness, аномалии метрик, кастомные SQL-правила.
Что делаете при падении ночной загрузки?
Алерт, root cause, backfill, коммуникация потребителям, postmortem, фикс идемпотентности.
Ловушка: Забывают про downstream-витрины и порядок пересчёта при backfill.
Когда выбираешь Spark вместо чистого SQL в СУБД?
Объём, сложные трансформации, несколько источников, необходимость распределённой обработки.
Типичные проблемы PySpark в проде?
Skew, shuffle, мелкие файлы, broadcast join размеров, партиционирование выхода.
OLTP vs OLAP, row-store vs column-store — когда что?
OLTP — транзакции; OLAP/ClickHouse — аналитика и агрегаты; MPP — распределённые запросы.
Как проектируешь витрину: ключи, гранулярность, партиционирование?
Один факт = одна гранулярность; surrogate keys; партиция по дате; SCD при необходимости.
Перенос данных между разными СУБД — на что смотришь?
Типы данных, timezone, кодировки, объём, incremental vs full, сверка контрольных сумм.
Ошибка первого и второго рода (α и β)?
I рода — ложный положительный (эффект есть, а его нет); II рода — пропустили реальный эффект. Мощность = 1−β.
Чем t-тест отличается от z-теста?
z — известная σ или большая n; t — малые выборки, оценка σ по выборке.
Если каждое значение выборки умножить на 5, как изменится дисперсия?
Var(5X) = 25·Var(X); среднее умножится на 5.
Как определяются длительность теста, размер выборки и дизайн эксперимента?
MDE, α, мощность, дисперсия метрики, стратификация, peeking и множественные сравнения.
Сколько будет 7% от 8?
0,56 — проверяют внимание к арифметике под давлением.
Совет: Связывай статистику с продуктом: какой риск бизнеса при α vs β для конкретной метрики.
Оцените, сколько сантехников в Москве (Fermi).
Население → доля квартир → частота вызова → норма на мастера; проговори допущения.
Оцените количество сантехников более простым методом.
Сверху вниз: число ЖК × среднее число подъездов × … или через справочник организаций.
Ловушка: Молчание хуже грубой оценки — структура важнее точности.
Как поступали задачи, кто декомпозировал, кто принимал решения? Пример задачи.
STAR: контекст, ваша роль, артефакты (ТЗ, спецификация), результат в метриках.
Как понимаешь роль аналитика в команде на примере кейса?
Связка бизнес-вопроса, данных и разработки; формализация требований и ограничений.
Какой документ делали для разработчиков при доработке интеграции?
Спецификация API/интеграции: контракт, поля, ошибки, примеры, нефункциональные требования.
Расскажите о своём опыте.
2–3 проекта: витрина/пайплайн, масштаб, стек, измеримый эффект; уложись в 3–5 минут.
Последний заказ москвича и % скидки
Таблицы orders (order_id, created_dt, user_id, price, discount) и users (id, reg_date, city). Для каждого пользователя из Москвы — последний заказ и процент скидки.
WITH r AS ( SELECT o.*, ROW_NUMBER() OVER (PARTITION BY o.user_id ORDER BY o.created_dt DESC, o.order_id DESC) rn FROM orders o JOIN users u ON u.id = o.user_id WHERE u.city = 'Москва' ) SELECT user_id, order_id, created_dt, price, discount, CASE WHEN price > 0 THEN 100.0 * discount / price END AS discount_pct FROM r WHERE rn = 1;
Сложность: O(n log n) на партицию user_id при сортировке в окне
Средний чек и заказы на пользователя по городам (Q1)
Посчитать средний чек по каждому городу и среднее число заказов на пользователя за первый квартал текущего года.
Агрегация после JOIN и фильтра created_dt BETWEEN start_q1 AND end_q1: по city — avg(net_check), sum(orders)/count(distinct user_id). В pandas — merge + groupby.
Сложность: O(n) по строкам заказов
Fermi: сантехники в Москве
Оценить порядок величины числа сантехников, работающих в Москве.
Например: ~13 млн жителей → ~5 млн квартир → X вызовов в год на квартиру → Y вызовов в день → Z мастеров при норме выработки. Альтернатива: число сервисных компаний × средний штат.
Сложность: —
Каркас ответа
3 дня
7 дней
14 дней
| Блок | Готов, если... |
|---|---|
| SQL и витрины | можешь без подсказок написать ROW_NUMBER для последней записи и объяснить партиционирование витрины по дате |
| Python / Airflow | можешь описать DAG от extract до DQ и как чинишь упавший task |
| Spark | можешь назвать 2 причины медленного job и что смотришь в Spark UI |
| Статистика | различаешь ошибки I/II рода и знаешь, как масштабируется дисперсия при умножении на константу |
| Поведение | есть один STAR-кейс про инцидент с данными и один про доставку витрины под дедлайн |
В день собеседования
