Собеседование на BI-разработчика в CloudPayments

Готовься к собесу аналитика как в Duolingo
10 минут в день — SQL, Python, A/B, метрики. 1700+ вопросов в Telegram
Открыть Карьерник в Telegram

Почему CloudPayments — особенный работодатель для BI

CloudPayments — российский провайдер интернет-эквайринга для бизнеса: десятки тысяч мерчантов, миллиарды рублей оборота, интеграции с маркетплейсами и сервисами доставки. Для BI-разработчика это работа в жёстко регулируемой fintech-среде с реальной денежной ответственностью: каждая цифра на дашборде касается money — ошибка стоит дорого.

BI в CloudPayments отвечает за дашборды для продактов, рисков, операционки, мерчантов (B2B-кабинет), продаж. Метрики: GMV (gross merchandise value), conversion, approve rate, chargeback rate, retention мерчантов, P&L по сегментам (маркетплейсы, ритейл, подписки), anti-fraud telemetry, средний чек. Главный челлендж — мерчанты видят часть дашбордов в личном кабинете; ошибка в цифре = clientская жалоба.

Стек: Power BI как основной BI-инструмент, ClickHouse + Greenplum для аналитики, dbt для трансформаций, real-time feature store на ClickHouse/Redis.

Что важно понимать про работодателя: CloudPayments — это не классический B2C-fintech и не маркетплейс, это инфраструктурный B2B-провайдер платежей. Это значит, что почти каждая цифра в дашборде касается денег конкретного мерчанта, и есть прямая клиентская видимость (мерчанты смотрят на свои данные в личном кабинете). Это иной режим работы BI-команды, чем в product-companies: цикл «опубликовать дашборд → найти ошибку → исправить» в fintech ограничен жёсткими SLA, потому что любая некорректная цифра у мерчанта — это потенциальный клиентский тикет или регуляторный риск. Параллельно — fintech регуляторика (ФЗ-115, ФЗ-161, ФЗ-152) требует особой работы с данными и compliance.

Актуальные вакансии — на hh.ru и сайте CloudPayments.

Информация основана на публичных источниках и опыте кандидатов. Команды CloudPayments используют разные процессы — уточняйте у рекрутера.

Этапы собеседования

Цикл — 4-5 этапов, 2-3 недели. Параллельно — проверка СБ (стандартно для fintech). Процесс достаточно компактный по меркам банковского сектора.

1. HR-скрининг (30-45 минут)

Рекрутер проверяет стек (Power BI, SQL, dbt — must, ClickHouse — большой плюс), опыт в fintech / payments. Если работал в Тинькофф, Сбер, ЮMoney, ЮKassa, Робокассе, СберПэй, MTS Pay — упомяни сразу, fintech-бэкграунд серьёзно ускоряет процесс. Параллельно: мотивация (почему именно платежи, готовность к проверке СБ, ответственность за money-цифры), компенсационные ожидания. Готовь питч на 90 секунд с конкретными кейсами.

2. SQL deep dive (60-90 минут)

Window functions (LAG, LEAD, RANK, running totals), агрегации транзакций (GMV по merchant, по сегменту, по способу оплаты), conversion-funnel (init → process → success → settled), дедупликация платежей (один transaction_id — одна строка, повторные попытки оплаты обрабатываются особо), real-time aggregations (текущий GMV на ClickHouse через AggregatingMergeTree). Сильный кандидат сразу обсуждает дедупликацию, потому что в payments повторные попытки оплаты — стандартная проблема, которая искажает метрики, если не обработать; обсуждает партиции по дате и оптимизацию запросов на event-stream таблицах.

Подготовка: SQL для BI.

3. Power BI (60 минут)

DAX (CALCULATE, FILTER, SUMX, time intelligence functions), модели данных (star schema, snowflake для транзакционных данных), RLS — критично для мерчант-кабинета: каждый мерчант видит только свои данные, и одна ошибка в RLS-правиле может привести к утечке данных одного мерчанта другому. Real-time refresh через DirectQuery на ClickHouse vs Import для исторических данных. Сильный кандидат глубоко понимает trade-offs DirectQuery vs Import, оптимизирует DAX для performance на больших датасетах, тестирует RLS на синтетических данных.

Подготовка: Power BI.

4. Дашборд-кейс (90 минут)

«Спроектируй дашборд для мерчанта (B2B-кабинет)» или «дашборд анти-фрод-команды с real-time alerts». Жди вопросов про аудиторию (маркетплейс с millions транзакций vs SMB-мерчант с десятками — у них разные потребности), JTBD (мерчанту нужно: видеть сегодняшний GMV, conversion, проблемные транзакции, тренд за неделю), UX (real-time для high-volume merchants vs hourly для остальных), RLS (мерчант видит только свои данные — must), refresh-стратегию. Сильный кандидат сразу декомпозирует кейс: аудитория → JTBD → метрики → визуализации → data model → refresh → RLS → testing; обсуждает, что особенно важно в money-аналитике точность каждой цифры и аудируемость источника.

Подготовка: Dashboard design, data modeling для BI.

5. Поведенческое (45 минут)

STAR. Истории про конфликт с продактом/рисками по приоритетам, факап с дашбордом (например, ошибка в money-цифре!), спор о приоритетах. В fintech ответственность за каждую цифру намного выше, чем в product-компании, и BI-разработчик должен быть способен признать ошибку, быстро исправить, выстроить процесс, чтобы такое не повторилось. Жди вопроса «расскажи про случай, когда твой дашборд показал неправильную цифру мерчанту».

Особенности по командам

Merchant Analytics. Дашборды в B2B-кабинете мерчанта: сегодняшний GMV, conversion на каждом этапе оплаты, top reasons of declines, refund-метрики, аналитика по способам оплаты (карта, СБП, кошелёк). Аналитик строит дашборды, которые видит клиент-мерчант, и любая ошибка приводит к support-тикету. Подойдёт кандидату с интересом к customer-facing analytics и комфортом с высокой ответственностью за данные.

Risk / Anti-fraud Analytics. Дашборды операционного фрод-мониторинга: real-time alerts о подозрительных транзакциях, паттерны fraud (массовые попытки с одного IP, аномальные суммы), эффективность правил фрод-системы (precision/recall), chargeback rate по сегментам. Это real-time analytics 24/7 для команды операторов фрода. Подойдёт кандидату с интересом к risk-аналитике и комфортом с real-time data.

Product Analytics. Internal-дашборды для продактов CloudPayments: использование фич, conversion rates по продуктам (Pay, Invoice, Subscriptions), adoption новых интеграций. Это классическая B2B SaaS product analytics. Подойдёт кандидату с опытом в product-аналитике SaaS-компаний.

Sales Pipeline. B2B-воронка крупных мерчантов: pipeline coverage, sales velocity, win rate в enterprise-сегменте (маркетплейсы, крупные ритейлеры). Подойдёт кандидату с опытом в B2B-sales analytics.

Finance / FP&A. P&L по сегментам (маркетплейсы, ритейл, подписки, доставка), unit economics на merchant level, прогнозирование revenue. Тесная связка с финансовой командой. Подойдёт кандидату с интересом к financial reporting и unit economics.

Что CloudPayments ценит в BI

SQL уверенно. Window functions, real-time aggregations на ClickHouse, оптимизация запросов под high-volume transaction data (миллионы records в день). Слабый кандидат пишет SELECT GROUP BY; сильный — обсуждает партиции по дате, AggregatingMergeTree для предагрегации, sampling для аналитических запросов на большой выборке.

Power BI / dbt. DAX, RLS (must для мерчант-кабинета), real-time refresh через DirectQuery. dbt для трансформаций с тестами на качество (uniqueness, not_null, accepted_values) и на бизнес-инварианты (sum GMV в дашборде == sum payments в DWH). Слабый знает основы; сильный — настраивает CI/CD на dbt с автоматическими тестами на каждый PR.

Fintech / payments domain. Знание GMV, conversion (init → 3DS → process → success), approve rate, chargeback rate, refund rate, средний чек, MID/TID (merchant ID, terminal ID), 3DS, settlement, dispute. Если fintech-опыта нет — за 2 недели до собеса прочитай про работу payment gateways, изучи документацию основных провайдеров (CloudPayments, ЮKassa, ЮMoney) и пойми, чем различается их подход.

Точность. Money — нельзя ошибаться. Слабый: «дашборд показывает плюс-минус»; сильный: «каждая цифра аудируема через lineage в dbt, есть автотесты на инварианты (sum GMV == sum по способам оплаты), есть QA-процесс перед публикацией метрики в мерчант-кабинете». В fintech-BI это не nice-to-have, это base requirement.

RLS / compliance. Понимание ролевого доступа к данным: мерчант видит только свои данные, внутренняя команда — только то, что ей нужно по роли, аудит доступа в SIEM. ФЗ-152, ФЗ-115 — базовое понимание регуляторных требований. Сильный кандидат глубоко знает RLS в Power BI и понимает связь с compliance.

Готовься к собесу аналитика как в Duolingo
10 минут в день — SQL, Python, A/B, метрики. 1700+ вопросов в Telegram
Открыть Карьерник в Telegram

Как готовиться: план

За 4-6 недель до планируемого собеса:

  1. Неделя 1-2 — SQL + dbt. Real-time aggregations. Параллельно — прорешай вопросы по Python, ML и SQL в Карьернике: 1500+ задач с разбивкой по темам, по 10-15 минут в день закрывают пробелы перед собесом. SQL для BI.
  2. Неделя 3 — Power BI. RLS deep dive. Power BI.
  3. Неделя 4 — Dashboard design. Dashboard design.
  4. Неделя 5 — Data modeling. Data modeling.
  5. Неделя 6 — Mocks + behavioral.

Частые ошибки

Слабый SQL. Без window functions, без понимания дедупликации payment-данных — провал. Что работает: за неделю прогнать 30-40 SQL-задач (cohort retention, funnel-аналитика, real-time aggregations), разобраться с ClickHouse-партициями и AggregatingMergeTree.

Power BI поверхностно. Слабо: «нарисую график, формулы знаю». Сильно: «RLS на уровне merchant_id с тестированием на синтетических данных, оптимизированный DAX с CALCULATE и FILTER, real-time refresh через DirectQuery с фильтрацией по дате, кеширование Aggregations для популярных запросов». Что работает: Power BI deep-dive за 2 недели, особенно DAX, RLS и performance optimization.

Без fintech domain. Не знаешь GMV/conversion/chargeback/approve rate — провал на дашборд-кейсе. Что работает: за 2 недели до собеса прочитать документацию основных payment-провайдеров (CloudPayments docs, ЮKassa docs), посмотреть, как они объясняют conversion-воронку, изучить 3DS, settlement, dispute lifecycle.

Без точности. Слабый кандидат говорит «ну плюс-минус 1% не критично»; для money-аналитики это red flag. Сильный: «каждая цифра аудируема через dbt lineage, есть тесты на инварианты, есть QA-процесс перед публикацией, ошибки логируются и анализируются». Что работает: разобраться с dbt-тестами (uniqueness, not_null, accepted_values + custom tests на бизнес-инварианты).

Перегруз чартами. Кандидат строит дашборд с 15-20 чартами «чтобы всё было видно». В merchant cabinet это особенно плохо, потому что мерчанту нужны 4-6 ключевых метрик в одном экране без скролла. Что работает: понимать «1 дашборд = 1 JTBD», использовать дриллдауны вместо нагромождения, начинать с того, какое решение пользователь должен принять.

Связанные темы

FAQ

Удалёнка в CloudPayments для BI?

Гибрид и удалёнка распространены.

Зарплатные вилки 2026?

Middle BI: 220-310k. Senior: 310-450k. Fintech платит выше рынка.

Английский нужен?

Базовый — желательно.

Сколько этапов?

4-5 этапов, 2-3 недели. Дополнительно — проверка СБ.

Это официальная информация?

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