Собеседование на Data Engineer в РЖД

Почему РЖД — особенный работодатель для DE

РЖД — крупнейший железнодорожный перевозчик страны, и данных здесь много и они очень разные. Data Engineer одновременно работает с продажами билетов, телеметрией с подвижного состава (датчики на локомотивах и вагонах), грузоперевозками, биллингом и программами лояльности. Это классический enterprise-масштаб плюс государственная инфраструктура: большие объёмы, длинное хранение и строгие требования к надёжности.

Две вещи делают роль особенной. Первая — масштаб и legacy: данные приходят из десятков систем разного возраста, часть из которых существовала задолго до современного стека, и их нужно аккуратно интегрировать, а не выбросить. Вторая — телеметрия с поездов: это, по сути, IoT-поток событий, который надо принимать, чистить и агрегировать, чтобы аналитика по состоянию парка и расписаниям работала на свежих данных. Из-за этого на собесе много спрашивают про Spark для больших батчей, потоковую обработку событий и продуманное хранение в DWH.

Актуальные вакансии и описание команд — на странице карьеры РЖД.

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

Обычно 5–6 этапов. Структура типовая для DE в крупном enterprise, но набор технических секций зависит от команды.

1. Скрининг с рекрутером (30–45 минут)

Знакомство и проверка соответствия: стек, объёмы данных, с какими pipeline работали, мотивация идти в транспортный домен. Полезно коротко описать один свой проект — источники данных, инструменты, ваш вклад и результат.

2. SQL и Python (60–90 минут)

Практический SQL уровня middle-senior: оконные функции, CTE, дедупликация, оптимизация запросов. Python — обработка данных, работа с pandas и написание простых ETL-скриптов. Часто это live coding: важно вслух проговаривать ход решения.

3. Spark (60 минут)

Ядро технической проверки: как устроены трансформации и action-и, как бороться с data skew, зачем нужны broadcast join и repartition, как читать план выполнения и не убить кластер широкими шафлами. Подготовиться поможет разбор Spark на собесе DE.

4. Хранилище и ClickHouse (45–60 минут)

Моделирование DWH и вопросы по ClickHouse: движки семейства MergeTree, партиционирование, материализованные представления, почему колоночное хранение быстрее для аналитики. Обсуждают, как разложить транспортные и биллинговые данные по слоям хранилища.

5. Архитектура и system design (60 минут)

Проектирование сквозного pipeline под кейс: например, приём телеметрии с подвижного состава или витрина продаж билетов. Смотрят, как вы выбираете батч или стриминг, где ставите Kafka, как обеспечиваете надёжность и повторную обработку при сбоях.

6. Поведенческое и финал (45 минут)

Вопросы про командную работу, инциденты в проде, работу со смежными командами и стейкхолдерами. Финал — с руководителем, обсуждение оффера и команды.

Что РЖД ценит в DE

• Spark. Уверенная работа с большими батчами, понимание трансформаций, шафлов и оптимизаций — основной инструмент для тяжёлых расчётов.
• Работа с IoT-данными. Поезда генерируют поток событий: нужно уметь принимать, чистить и агрегировать телеметрию, разбираться с опоздавшими и битыми событиями.
• DWH. Проектирование слоёв хранилища и витрин, понимание, как разложить разнородные данные под аналитику и отчётность.
• Требования регуляторов. Работа с гостайной и требованиями ФСТЭК по защите информации — часть инфраструктуры закрытая, и это влияет на архитектуру.
• Стабильность. Надёжные и предсказуемые pipeline важнее модных технологий: система должна переживать сбои и восстанавливаться без потери данных.

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

• «IoT-pipeline с подвижного состава». Приём телеметрии с датчиков, обработка опоздавших и дублирующихся событий, агрегация до состояния парка.
• «Pipeline продаж билетов». Сбор данных о продажах из разных каналов в единую витрину для отчётности и планирования.
• «Биллинг грузоперевозок». Расчёт и сверка начислений по перевозкам, где важна точность и воспроизводимость.
• «Хранение данных 5+ лет». Как организовать долгое хранение больших объёмов: партиционирование, сжатие, холодные и горячие слои.
• «Оптимизация Spark-джобы». Есть медленный расчёт — найти причину (skew, лишние шафлы, неоптимальные join) и ускорить.

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

1. Spark. Разберите модель выполнения, шафлы, broadcast join, борьбу с data skew и чтение плана выполнения.
2. IoT и потоковые данные. Поймите паттерны обработки событий: опоздавшие и дублирующиеся сообщения, идемпотентность, агрегация окнами.
3. ClickHouse и DWH. Повторите движки MergeTree, партиционирование, материализованные представления и слои хранилища.
4. Требования регуляторов. Освежите базовые понятия про защиту информации и требования ФСТЭК — хотя бы уметь про это осмысленно поговорить.
5. SQL. Доведите до уверенного middle-senior: оконные функции, дедупликация, оптимизация запросов.

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

• Слабый SQL. Плавать на оконных функциях и оптимизации запросов на позиции middle-senior — сразу минус.
• Поверхностно про IoT-данные. Не понимать, как обрабатывать поток событий с опозданиями и дублями, и говорить про телеметрию общими словами.
• Игнорировать требования регуляторов. Проектировать архитектуру, не учитывая закрытый контур и защиту информации, — в госинфраструктуре это критично.

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

• Собеседование на DE в Ростелекоме
• Собеседование на DE в Аэрофлоте
• Собеседование на DE в СДЭК
• Spark на собесе DE
• Собеседование на DS в РЖД

FAQ

Сколько этапов на собесе DE в РЖД?

Обычно 5–6: скрининг с рекрутером, SQL/Python, Spark, ClickHouse и DWH, архитектурный кейс, поведенческое и финал. Точный набор зависит от команды и грейда.

Нужен ли опыт в транспорте?

Желателен, но не обязателен. Плюсом будет любой опыт с большими объёмами, потоковыми/IoT-данными и enterprise-интеграциями — именно это ближе всего к задачам РЖД.

Какие инструменты главные?

Ядро стека — Spark, ClickHouse и Kafka: тяжёлые батчи на Spark, аналитическое хранение в ClickHouse, потоковые события через Kafka. Их и стоит готовить в первую очередь.

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

Middle-senior: уверенные оконные функции, CTE, дедупликация и умение оптимизировать запросы, а не только писать простые SELECT с JOIN.

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

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