Собеседование на Data Engineer в Банки.ру

Проверь себя · 1/3разбор после ответа
Аналитик написал SELECT * FROM orders, users без WHERE и без JOIN ... ON. В orders 1000 строк, в users 500 строк. Что вернёт запрос?

Почему Банки.ру — особенный работодатель для DE

Банки.ру — крупный финтех-агрегатор: пользователь сравнивает кредиты, карты, вклады и страховки, оставляет заявку, а платформа передаёт эту заявку (lead) в банки-партнёры. Для Data Engineer это значит, что данные тут — не просто отчётность, а ядро бизнеса: качество и скорость lead-пайплайнов напрямую влияют на выручку.

Специфика домена — два переплетённых мира. Первый — lead-бизнес: заявки нужно собрать, обогатить, отскорить и доставить в банк без потерь и дублей. Второй — интеграционная нагрузка: платформа постоянно общается с десятками банковских API, у каждого свой формат, свои таймауты и свои сбои. Отсюда типичный стек DE: Spark для тяжёлой обработки, ClickHouse для быстрой аналитики, Kafka для потоков событий. Актуальные вакансии — на странице карьеры Банки.ру.

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

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

Ниже — типичная последовательность для DE в продуктовом финтехе. Конкретное число этапов и их порядок зависят от команды и грейда.

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

Знакомство и проверка базового соответствия. Обсуждают ваш опыт, стек (Spark / ClickHouse / Kafka), объёмы данных, с которыми работали, и мотивацию идти именно в финтех-агрегатор. Полезно за 90 секунд рассказать, какой пайплайн вы строили, какие объёмы он обрабатывал и какой бизнес-эффект дал.

2. SQL и техническое интервью (60-90 минут)

DE в Банки.ру пишет много SQL для аналитики и ETL, поэтому SQL проверяют предметно. Ждут уверенных оконных функций, CTE, дедупликации, работы с поздно приходящими данными (late-arriving) и понимания, как писать эффективные запросы под ClickHouse, а не под привычный PostgreSQL. Готовиться: SQL для DE, SQL-тренажёр.

3. Python, ETL и Spark (60-90 минут)

Живое кодирование или разбор вашего пайплайна. Смотрят на владение Python и Spark: как обрабатываете большие объёмы событий, как боретесь с перекосом данных (data skew), как организуете идемпотентную запись, чтобы повтор обработки не создавал дублей заявок. Плюс — понимание оркестрации (Airflow) и трансформаций (dbt).

4. System design (60-90 минут)

Ключевой этап для финтеха. Дают кейс из домена — спроектировать lead-пайплайн или интеграцию с банковским API — и смотрят, как вы рассуждаете о надёжности, ретраях, дедупликации и мониторинге. Здесь ценят не идеальную схему, а умение проговорить компромиссы и слабые места. Готовиться: data modeling, Kafka streaming, CDC.

5. Поведенческое интервью (45-60 минут)

Обсуждают работу в команде, взаимодействие с аналитиками и продуктом, сложные ситуации: сорванный дедлайн, инцидент с данными, спор по архитектуре. Отвечать удобно по схеме STAR — ситуация, задача, действие, результат.

Что Банки.ру ценит в DE

  • Spark на боевых объёмах. Обработка терабайтов событий, борьба с перекосом данных и оптимизация джобов — базовый навык, а не строчка в резюме.
  • ClickHouse не поверхностно. Понимание MergeTree, материализованных представлений и того, чем аналитический движок отличается от OLTP-базы.
  • Интеграционное мышление. Умение проектировать общение с внешними банковскими API: таймауты, ретраи, обработка ошибок, защита от дублей.
  • Lead-пайплайны. Понимание, что заявка — это деньги, и её нельзя потерять или доставить дважды. Идемпотентность и надёжность доставки.
  • A/B-инфраструктура. Готовность строить и поддерживать данные для экспериментов, ведь агрегатор постоянно тестирует форму заявки и ранжирование предложений.

Типичные задачи и кейсы

  • Lead-пайплайн. Спроектировать поток от заявки пользователя до доставки в банк: сбор, обогащение, скоринг, отправка, подтверждение. Ключевые вопросы — дедупликация и гарантия доставки.
  • Интеграция с банковскими API. Как надёжно забирать и отправлять данные во внешние системы с нестабильными ответами: ретраи, идемпотентность, circuit breaker, мониторинг.
  • ClickHouse для аналитики. Построить витрину для продуктовой и бизнес-аналитики так, чтобы отчёты по воронке заявок считались за секунды, а не минуты.
  • A/B-инфраструктура. Организовать сбор и разметку событий для экспериментов над формой заявки и ранжированием предложений.
  • Spark на терабайтах событий. Обработать большой поток пользовательских событий, не упершись в перекос данных и не раздув стоимость кластера.
Готовься к собесу аналитика как в Duolingo
10 минут в день — SQL, Python, A/B, метрики. 1700+ вопросов в Telegram
Открыть Карьерник в Telegram

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

  1. Spark. Разберите модель выполнения, шаффл, перекос данных и типовые оптимизации. Умейте объяснить, почему джоб тормозит и как это чинить.
  2. ClickHouse. Движки семейства MergeTree, материализованные представления, отличия от OLTP. Потренируйтесь писать аналитические запросы под колоночную базу. ClickHouse и OLAP.
  3. DWH и моделирование. Слои данных (raw / staging / marts), идемпотентная загрузка, поздно приходящие данные. dbt и моделирование.
  4. SQL уровня middle. Оконные функции, дедупликация, оптимизация. Прогоните задачи в SQL-тренажёре.
  5. Интеграционное мышление. Проговорите вслух, как вы проектируете обмен с внешним API: ретраи, таймауты, дедупликация, доставка ровно один раз на уровне бизнес-ключа. Именно это отличает финтех-DE.

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

  • Слабый SQL. DE тут пишет аналитические запросы каждый день. Плавать в оконных функциях и дедупликации — сразу минус.
  • Интеграции без обработки ошибок. Проектировать обмен с банковским API в предположении, что он всегда отвечает быстро и корректно. Не заложить ретраи, таймауты и защиту от дублей — красный флаг для финтеха.
  • Поверхностный ClickHouse. «Слышал, что быстрый» — недостаточно. Ждут понимания движков и того, почему запросы под ClickHouse пишут иначе, чем под PostgreSQL.
  • Игнор идемпотентности. В lead-бизнесе повторно доставленная заявка — это реальные деньги и испорченная репутация у банка-партнёра. Не проговорить дедупликацию — провал system design.
  • Отсутствие продакшен-опыта. Только учебные проекты без боевых объёмов и инцидентов — на middle+ это заметно.

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

FAQ

Сколько этапов на собесе DE в Банки.ру?

Обычно 4-5: HR-скрининг, SQL и техническое интервью, секция по Python/Spark, system design и поведенческое. Точное число зависит от команды и грейда — иногда технические секции объединяют. Уточняйте у рекрутера.

Нужен ли опыт в финтехе?

Желателен, но не всегда обязателен. Гораздо важнее понимать логику lead-бизнеса: заявка = деньги, её нельзя потерять или доставить дважды. Если вы умеете рассуждать про надёжную доставку, дедупликацию и интеграции с внешними системами, отсутствие строчки «финтех» в резюме не критично.

Какие инструменты нужно знать?

Базовый стек — Spark, ClickHouse и Kafka, плюс SQL и оркестрация (Airflow). Spark нужен для тяжёлой обработки событий, ClickHouse — для быстрой аналитики, Kafka — для потоков. Конкретный набор отличается по командам.

Какой уровень SQL ждут?

Уверенный middle: оконные функции, CTE, дедупликация, работа с поздно приходящими данными и понимание, как писать эффективные запросы под ClickHouse. SQL здесь используют ежедневно, поэтому его проверяют предметно, а не для галочки.

Что чаще всего дают на system design?

Кейсы из домена агрегатора: спроектировать lead-пайплайн от заявки до доставки в банк или интеграцию с нестабильным банковским API. Ключевое, что хотят услышать, — как вы обеспечиваете надёжность: ретраи, идемпотентность, дедупликация по бизнес-ключу и мониторинг.

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

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