Собес в Альфа-Банк · Системный аналитик Senior
Материал Эйч · Опубликовано 27 октября 2026
Обзор
Сбор и формализация требований, интеграции, модель данных и архитектурные решения в финтех-контуре; на собесах часто смешивают классический SA-стек с вопросами по 1С/ERP и банковским кейсам.
Фишка: Сильный акцент на цифровой банкинг и сложные интеграции; культура роста (обучение, конференции). На интервью часто проверяют не только «учебник», а умение предложить компромисс (MVP) и объяснить trade-off между скоростью поставки и целостностью модели данных.
| Этап | Длительность | Что проверяют |
|---|---|---|
| Скрининг / HR | 30–45 мин | Мотивация, опыт 5+ лет, формат работы, зарплатные ожидания, соответствие гибриду/удалёнке |
| Техническое интервью | 60–90 мин | Интеграции, API, SQL, модель данных, нотации, разбор кейсов из практики аналитика |
| Углублённый блок (архитектура / домен) | 45–60 мин | Отказоустойчивость платёжных сценариев, проектирование структур данных, иногда 1С/ERP и нагрузочные объёмы данных |
| Поведенческое / командное | 30–45 мин | Взаимодействие с разработкой, бизнес-аналитиками, стейкхолдерами; фейлы и выводы; MVP и компромиссы |
Стек и темы
Обязательный минимум
- Сбор и документирование БТ/ФТ/НФТ, ТЗ, FSD
- BPMN, UML activity и sequence
- REST: проектирование и проверка в Postman/аналогах
- SOAP: структура запроса/ответа, SOAP UI
- Чтение XSD
- Синхронные и асинхронные интеграции
- Опыт с брокером (Kafka / RabbitMQ / IBM MQ)
- ER-модель, 1–3 НФ
- SQL: JOIN, UNION; отличия реляционных и NoSQL
- Идентификация vs аутентификация vs авторизация; шифрование vs хэширование
- Функциональное тестирование и сопровождение
- Использование LLM/AI в работе
Плюсом будет
- DDL в SQL (CREATE/ALTER/DROP)
- Глубокий опыт 1С: регистры, блокировки, формы
- Индексы БД и влияние на INSERT/UPDATE
- Архитектурные паттерны отказоустойчивости платежей
Моделирование и требования
Можешь предложить компромиссное решение для реализации MVP?
Минимальный сквозной сценарий, готовые компоненты, явные ограничения scope, критерии «достаточно для пилота» и план доработок.
Работал ли ты в связке с бизнес-аналитиком?
Разделение: BA — проблема и ценность, SA — границы системы, интерфейсы, НФТ, трассировка требований в backlog.
Как тебе комфортнее работать: с бизнес-аналитиком или самому общаться со стейкхолдерами?
Нет единственно верного ответа; важно показать навык интервью, фиксации решений и эскалации рисков.
Фишка: В Альфе ценят аналитика, который сам ведёт артефакты до разработки и тестирования, а не только рисует диаграммы.
Совет: На кейсах MVP всегда проговаривайте: что не делаем в первой версии и какие метрики успеха пилота.
Интеграции и API
Что такое двухзвенная и трёхзвенная архитектура? В чём плюсы и минусы?
2-tier: клиент ↔ БД (просто, плохо масштабируется). 3-tier: presentation / business / data — масштабирование и разделение ответственности.
Какие есть участники и компоненты брокера сообщений?
Producer, consumer, broker, очереди/топики, routing, persistence, consumer groups, DLQ, идемпотентность обработки.
Ловушка: Путают синхронный REST «для всего» с асинхронной обработкой долгих или пиковых нагрузок — на собесе ждут осознанный выбор.
Базы данных и SQL
Расскажи про составные индексы, в чём их особенность?
Порядок колонок важен для фильтра и сортировки; покрывающий индекс; leftmost prefix rule.
Расскажи про виды индексов подробнее (кроме уже названных)
B-tree, hash, GIN/GiST (контекст СУБД), clustered vs non-clustered, unique, partial, functional.
Почему операции UPDATE/INSERT выполняются дольше, если на поле навешан индекс?
Каждый индекс нужно обновить при изменении ключа; больше индексов — выше cost записи; trade-off read vs write.
Спроектируй структуру данных для банковской системы: клиент — несколько карт, к счёту карта, счета без карт. Три таблицы.
Clients; Accounts (ClientID FK); Cards (AccountID FK, тип карты). Счёт без карты = запись в Accounts без строки в Cards.
Совет: Для банковского ER проговорите идентификаторы (UUID/ bigint), статусы, историчность и разделение «продукт» vs «договор» vs «счёт».
1С и ERP (часто на собесах Альфы)
Привести пример, когда данные лучше хранить в регистре сведений, когда в регистре накопления.
Сведения — срезы/атрибуты на дату; накопление — остатки и обороты, движения во времени.
Пользователь просит добавить реквизит в документ, по нему потом построить отчёт. Почему это может быть плохой идеей?
Размывание модели, дубли, отчётность через регистры/витрины, производительность проведения документа.
Есть потребность загружать 5–7 млн записей в месяц из внешней системы в ERP. Куда лучше писать?
Регистр сведений (или отдельная витрина), не табличная часть документа; пакетная загрузка, индексы, регламентные задания.
Знаешь ли механизмы блокировок данных в 1С? Надо ли аналитику думать о блокировках?
Блокировки записей/объектов при конкурентном доступе; аналитик задаёт сценарии одновременного изменения и критичные сущности.
С управляемыми формами знаком? Чем отличаются от неуправляемых?
Управляемые — клиент-сервер, тонкий клиент, web; неуправляемые — устаревший thick UI; влияние на UX и производительность.
Фишка: Даже без глубокой разработки на 1С Senior SA в банке должен понимать метаданные и последствия постановок для учёта и отчётности.
Архитектура и отказоустойчивость
Спроектируй архитектуру отказоустойчивой системы обработки платежей, чтобы при падении банковского шлюза пользователи не видели 500, но платежи гарантированно обрабатывались
Очередь, асинхронный статус, idempotency key, retry с backoff, circuit breaker, outbox, saga, понятный UX «в обработке».
Ловушка: «Просто ретраить без лимита» — риск дублей и шторма; нужны идемпотентность и DLQ.
Задачи
Логика: арбуз и проценты
Арбуз весит 10 кг, на 99% состоит из жидкости. После усыхания жидкости стало 98%. Сколько теперь весит арбуз?
Сухая масса не меняется: 10 × 1% = 0,1 кг. После усыхания 0,1 кг — это 2% массы, значит общий вес = 0,1 / 0,02 = 5 кг.
Сложность: O(1)
Модель: клиент, счета, карты
Спроектируй три таблицы: у клиента несколько карт (дебет/кредит), карта привязана к счёту, у клиента могут быть счета без карт.
clients(client_id PK, …); accounts(account_id PK, client_id FK, account_type, …); cards(card_id PK, account_id FK, card_type, status, …). Связь card→account обязательна; account→client обязательна; счёт без карты — accounts без записи в cards.
Сложность: —
System Design
- Отказоустойчивая обработка платежей при недоступности внешнего шлюза
- Загрузка миллионов записей из внешней системы в ERP без деградации UI
- Проектирование REST-сервиса статусов заявки с синхронным и асинхронным каналами уведомлений
Каркас ответа
- Уточнить сценарии, SLA, объёмы, регуляторику
- Выделить границы сервисов и контракты (REST/SOAP/очередь)
- Модель данных и идемпотентность
- Схема sync vs async, очереди, retry, DLQ
- Наблюдаемость: логи, метрики, трассировка
- UX при деградации: статусы вместо 500
- План тестирования и rollout
Поведенческое
- Расскажи про запоминающийся фейл и что ты вынес
- Как выстраивал взаимодействие с командой разработки при жёстком дедлайне
- Пример, когда пришлось отстоять техническое решение перед бизнесом
- Как используешь LLM/AI в работе аналитика без потери качества требований
- Опыт функционального тестирования своих постановок
План подготовки
3 дня
- Повторить REST/SOAP/XSD и отличия sync/async
- Прорешать 5–10 SQL на JOIN/UNION и нормализацию до 3НФ
- Разобрать кейс платежей: очередь, идемпотентность, статусы для пользователя
- Подготовить 2 STAR-истории: фейл и успешная интеграция
7 дней
- Нарисовать BPMN и sequence для типового банковского сценария (открытие продукта / платёж)
- Повторить компоненты Kafka/RabbitMQ и паттерны consumer/producer
- Пройти блок 1С: регистры, блокировки, антипаттерн «реквизит в документ для отчёта»
- Составить чеклист артефактов ТЗ/FSD для одной выдуманной фичи
14 дней
- Системно повторить authn/authz и crypto basics
- Практика Postman + чтение чужого OpenAPI/XSD
- Мок-интервью: ER банка + MVP-компромисс + логическая задача с процентами
- Освежить опыт внедрения/сопровождения и FT
| Блок | Готов, если... |
|---|---|
| Интеграции | можешь нарисовать sequence для sync REST и async через брокер и назвать trade-offs |
| SQL и модель данных | спроектируешь клиент/счёт/карту и объяснишь влияние индексов на запись |
| 1С/ERP | объяснишь выбор регистра и риски постановки «поле в документ ради отчёта» |
| Архитектура | опишешь обработку платежа без 500 при падении шлюза |
| Поведение | есть 2–3 STAR-истории про стейкхолдеров, разработку и ошибки |
В день собеседования
- Иметь под рукой примеры диаграмм (BPMN/UML) в портфолио или описать устно
- Проверить связь и тихое место для технического этапа
- Держать лист для фиксации уточняющих вопросов по кейсу
- На архитектурных вопросах сначала уточнять требования, потом решение