Собеседование на системного аналитика в РЖД

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

РЖД — крупнейший железнодорожный перевозчик страны и одна из самых больших ИТ-инфраструктур в России. Системный аналитик здесь проектирует очень разные вещи: API продажи билетов (через мобильное приложение, сайт и кассы одновременно), B2B-сервисы грузоперевозок, IoT-интеграции с подвижным составом, программы лояльности. Масштаб и разнородность систем — главная специфика роли.

Ключевая особенность — это enterprise-контур с сильным государственным регулированием и большим слоем legacy. Рядом с современными микросервисами работают системы, которым не один десяток лет, часть интеграций — на SOAP, а не REST. SA приходится не только проектировать новое, но и аккуратно встраиваться в существующий ландшафт, где нельзя «переписать с нуля». Плюс требования к безопасности и работе с персональными данными выше среднего по рынку. Актуальные вакансии и требования — на странице карьеры РЖД.

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

Процесс обычно занимает 5-6 этапов и растянут во времени — в крупной госкомпании согласования идут дольше, чем в продуктовом стартапе. Типичная последовательность:

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

Знакомство, обсуждение опыта, мотивации и формата работы. Проверяют базовое соответствие: с какими системами и интеграциями вы работали, знакомы ли с enterprise-контуром.

2. Моделирование процессов (BPMN)

Дают бизнес-процесс и просят его смоделировать или разобрать готовую схему. Оценивают, умеете ли вы формализовать сложный процесс с ветвлениями, ролями и исключениями — на транспорте таких процессов много (продажа, возврат, пересадка, перевозка груза).

3. Проектирование API

Основной технический этап. Просят спроектировать интерфейс под задачу вроде продажи билета или заказа грузоперевозки: методы, форматы, коды ошибок, идемпотентность. Важно, что здесь пригодится и REST, и понимание SOAP — legacy-системы РЖД часто общаются именно по SOAP.

4. Базы данных и SQL

Проверяют работу с данными: спроектировать схему под сущность, написать запрос, объяснить связи. Уровень обычно middle — JOIN, агрегации, понимание нормализации и индексов.

5. Прикладной кейс

Сквозная задача из транспортного домена: как устроить интеграцию, где узкие места, как обрабатывать сбои. Оценивают системное мышление и умение видеть решение целиком, а не по кускам.

6. Поведенческое интервью и финал

Разбор рабочих ситуаций по STAR и проверка умения работать со стейкхолдерами. Часто присутствует нанимающий руководитель.

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

• Проектирование API. REST для новых сервисов и понимание SOAP для интеграции с legacy — на транспорте без второго никуда.
• Работа с базами данных. Уверенный SQL и умение проектировать схему данных под сущности предметной области.
• Понимание транспортного домена. Логика билетов, тарифов, грузоперевозок, расписаний — специфика, которую не выучишь за вечер.
• Внимание к compliance. Работа с персональными данными по 152-ФЗ и требования безопасности (в том числе ФСТЭК) — не формальность, а часть проектирования.
• Навык работы со стейкхолдерами. В большой организации согласование требований между множеством сторон — половина работы аналитика.

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

• «API продажи билетов: единый интерфейс для приложения, сайта и касс»
• «B2B-логистика: сервис заказа и отслеживания грузоперевозок»
• «IoT-интеграция с подвижным составом: сбор телеметрии с поездов»
• «Программа лояльности "РЖД Бонус": начисление и списание баллов»
• «Миграция legacy-системы на современный стек без остановки сервиса»

В кейсах ждут не только «как сделать», но и «как не сломать существующее»: обработку ошибок, обратную совместимость, поведение при недоступности смежной системы.

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

1. API-проектирование. Разберите REST-дизайн и освежите основы SOAP — REST API на собесе SA.
2. Базы данных и SQL. Схемы данных, JOIN, агрегации, индексы — уровень middle.
3. Транспортный домен. Логика билетов, тарифов, грузоперевозок и расписаний.
4. Compliance. Базовое понимание 152-ФЗ и требований к защите данных.
5. BPMN. Умение моделировать процессы с ветвлениями, ролями и исключениями.

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

• Игнорировать legacy. Предлагать «просто переписать всё на микросервисы» без учёта существующих SOAP-интеграций и совместимости — нереалистично для РЖД.
• Слабый SQL. Не суметь спроектировать схему или написать запрос средней сложности.
• API без обработки ошибок. Проектировать «счастливый путь» без кодов ошибок, идемпотентности и поведения при сбоях смежных систем.
• Забывать про compliance. Проектировать работу с персональными данными, не упоминая требования 152-ФЗ и безопасности — в госконтуре это критично.

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

• Собеседование на SA в Ростелекоме
• Собеседование на SA в Аэрофлоте
• REST API на собесе SA
• Собеседование на PM в РЖД
• Собеседование на DS в РЖД

FAQ

Сколько этапов в собеседовании?

Обычно 5-6: скрининг, моделирование процессов (BPMN), проектирование API, базы данных и SQL, прикладной кейс, поведенческое интервью с финалом. В крупной госкомпании процесс растянут во времени из-за согласований, так что закладывайте несколько недель.

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

Желателен, но не всегда обязателен. Сильный опыт проектирования интеграций и API в других enterprise-доменах может перевесить. Однако логику билетов, тарифов и грузоперевозок стоит хотя бы в общих чертах разобрать заранее — это ускорит разговор в кейсах.

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

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

Зачем SA знать SOAP, если везде REST?

Потому что в РЖД много legacy-систем, которые общаются именно по SOAP. Новые сервисы проектируют на REST, но интегрироваться с существующим ландшафтом без понимания SOAP не получится. Умение работать с обоими стилями — прямое требование enterprise-контура.

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

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