Middle SA в команде ДМС: обмен персональными данными между страховщиком и медицинскими организациями, интеграции REST, документация и поддержка жизненного цикла фич
Фишка: Проект внутри экосистемы Сбера (ООО СК «Сбербанк страхование»): жёсткий фокус на ПДн и 152-ФЗ, интеграция с множеством внутренних и внешних систем участников ДМС. Компания активно продвигает GenAI-инструменты в работе аналитиков — интерес к ИИ будет плюсом.
| Этап | Длительность | Что проверяют |
|---|---|---|
| HR / рекрутер | 30–45 мин | Мотивация, опыт 3+ года как SA, формат гибрид (Москва, м. Проспект Мира), зарплатные ожидания, готовность к работе с ПДн и регуляторными требованиями |
| Техническое интервью с командой | 60–90 мин | Опыт интеграций и REST, проектирование API, SQL, UML/диаграммы, разбор кейса по обмену данными или инциденту, качество требований и критериев приёмки |
| Интервью с нанимающим менеджером / тимлидом | 45–60 мин | Коммуникация с внутренними и внешними разработчиками, демонстрация результатов заказчику, декомпозиция задач, оценка и приоритизация, защита архитектурных решений |
| Проверка службы безопасности / комплаенс | 1–3 недели | Стандартная для финансовой группы Сбера: проверка документов и бэкграунда перед оффером |
Обязательный минимум
Плюсом будет
Расскажи о себе
2–3 мин: текущая роль → ключевые проекты с интеграциями → почему SA и почему Сбер/ДМС. Без перегруза деталями, с акцентом на обмен данными между системами.
Расскажи про свой прошлый проект
Структура: контекст бизнеса → твоя зона ответственности → архитектура (монолит/микросервисы) → интеграции → артефакты (ТЗ, API-спеки) → результат.
Расскажи про свой опыт системной аналитики
Покрой цикл: сбор требований → декомпозиция → спецификация → приёмка → поддержка и инциденты.
Почему решил стать системным аналитиком
Логичная история перехода: интерес к стыку бизнеса и технологий, любовь к деталям и структурированию.
Почему решил сменить место работы
Позитивно: рост в интеграциях, домен страхования/финтеха, масштаб экосистемы Сбера. Без негатива о текущем работодателе.
Какая была архитектура проектов на прошлых работах
Опиши тип (монолит, SOA, микросервисы), способы интеграции (REST, очереди), плюсы и минусы для конкретного контекста.
В каком виде получал задачи на прошлом проекте
User story, эпики, заявки из Service Desk, письма заказчика — и как ты их трансформировал в спецификации.
На что обращаешь внимание при выборе работы
Домен, технологический стек интеграций, культура (Agile), возможности развития, стабильность компании.
Фишка: В Сбере на этом этапе часто оценяют не только опыт, но и способность чётко структурировать рассказ — практикуй ответы по схеме «контекст → действия → результат».
Совет: Подготовь один сильный кейс с интеграцией REST и обменом данными между внешней и внутренней системой — он закроет половину технических вопросов.
Какие знаешь атрибуты качества требований
Полнота, непротиворечивость, проверяемость, однозначность, трассируемость, модифицируемость, приоритизированность.
В чём разница между функциональными и нефункциональными требованиями
Функциональные — что система делает (бизнес-логика). Нефункциональные — как: производительность, безопасность, доступность, масштабируемость, совместимость.
Что такое User Story
Формат: «Как [роль], я хочу [действие], чтобы [ценность]». Критерии приёмки — отдельно. INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable.
Что такое SMART
Specific, Measurable, Achievable, Relevant, Time-bound — для целей и KPI в требованиях.
Для чего нужна диаграмма последовательности
Показывает порядок сообщений между участниками во времени: клиент → API → сервис → БД. Ключ для интеграционных сценариев и ТЗ.
Для чего используют BPMN
Моделирование бизнес-процессов: задачи, события, шлюзы, потоки. Помогает формализовать процесс до автоматизации.
В чём разница между BPMN и BPMS
BPMN — нотация (язык описания). BPMS — платформа, которая исполняет процессы (Camunda, ELMA и др.).
Расскажи про свой опыт декомпозиции задач
От эпика к story → подзадачи для dev/QA → зависимости → оценка. Пример с интеграционной фичей.
Расскажи про опыт работы с нефункциональными требованиями
Примеры: SLA ответа API < 500ms, RPS, шифрование TLS, аудит логов, retention данных по 152-ФЗ.
Расскажи про опыт работы с тестовой документацией
Тест-кейсы, чек-листы приёмки, участие в UAT, связь критериев приёмки с тестами.
Ловушка: Не путай user story с ТЗ — story для backlog, ТЗ/спецификация для разработки с техническими деталями.
Фишка: В вакансии явно указаны: декомпозиция, use case, sequence diagram, схемы данных, правила валидации и сопоставления атрибутов — это ядро рабочих артефактов.
Что такое API
Контракт взаимодействия между системами: endpoints, методы, форматы данных, коды ответов. REST — один из стилей поверх HTTP.
Что такое принцип REST
Ресурсы (URI), HTTP-методы (GET/POST/PUT/PATCH/DELETE), stateless, представления (JSON/XML), HATEOAS опционально. Не всё HTTP API — REST.
Что описывать в REST сервисе кроме данных
Методы и URI, headers (auth, content-type), query params, body schema, статус-коды и error model, версионирование, rate limits, idempotency, таймауты, аутентификация OAuth2.
Какие знаешь HTTP статус-коды
200 OK, 201 Created, 204 No Content, 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 409 Conflict, 422 Validation Error, 429 Too Many Requests, 500 Internal Error, 502/503.
Какие виды интеграций существуют
Синхронный REST/gRPC, асинхронный (очереди, Kafka), файловый обмен (SFTP), ETL, shared DB (антипаттерн), webhook, ESB.
Что такое SOAP
XML-based протокол с WSDL-контрактом. Строгая типизация, WS-Security. Часто в legacy и enterprise/страховании.
Что такое WSDL
XML-описание SOAP-сервиса: типы, операции, endpoints. Генерация клиентов из WSDL.
Есть ли опыт проектирования API
Опиши процесс: анализ сценария → ресурсы → endpoints → схемы → error handling → ревью с разработчиками → OpenAPI/Swagger.
Как передать бинарный файл в POST
multipart/form-data (поле file), или raw body с Content-Type (application/pdf, image/png), или base64 в JSON (не для больших файлов).
В чём разница между аутентификацией и авторизацией
Аутентификация — кто ты (логин, токен). Авторизация — что тебе разрешено (роли, scopes OAuth2).
Расскажи про опыт работы с Postman
Создание коллекций, переменные окружения, тесты ответов, моки, проверка OAuth2 flow.
Есть ли опыт работы с GraphQL
Если есть: один endpoint, клиент запрашивает нужные поля. Если нет — честно + понимание отличий от REST.
Фишка: Проект ДМС — обмен ПДн между страховщиком и МО: в спецификациях обязательны TLS, OAuth2, маскирование полей, аудит запросов.
Ловушка: При описании POST для обмена медицинских данных не забудь idempotency key и валидацию на входе — типичный вопрос на глубину.
Какие знаешь виды архитектур
Монолит, модульный монолит, SOA, микросервисы, event-driven, serverless. Выбор зависит от масштаба и команды.
Что такое микросервисная архитектура
Независимые сервисы с собственными БД, деплоятся отдельно, общаются через API/очереди. Плюсы: масштабирование. Минусы: сложность, distributed tracing.
Какие плюсы и минусы монолитной архитектуры
Плюсы: простота деплоя и отладки. Минусы: сложно масштабировать части, риск «большого релиза».
Какие плюсы и минусы микросервиса
Плюсы: независимый деплой, технологическая гибкость. Минусы: сетевые вызовы, консистентность, DevOps overhead.
Что такое сервис-ориентированная архитектура
SOA: бизнес-функции как сервисы с контрактами, часто через ESB. Предшественник микросервисов в enterprise.
Как работает брокер сообщений
Producer → exchange/topic → queue → consumer. Гарантии доставки (at-least-once, exactly-once), ack, dead letter queue.
С какими брокерами сообщений работал
Kafka (log, partitions), RabbitMQ (AMQP, routing). Для ДМС — асинхронная доставка событий (полис, гарантийное письмо).
Можно ли использовать Kafka как хранилище
Kafka — log с retention, не полноценная БД. Подходит для event sourcing и replay, но не для сложных запросов и транзакций.
Совет: На защите архитектурных решений используй схему: контекст → ограничения → варианты → выбор → риски.
Что такое нормализация БД
Устранение избыточности: 1NF (атомарность), 2NF (нет частичных зависимостей), 3NF (нет транзитивных). Денормализация для read-heavy сценариев.
В чём разница между концептуальной, логической и физической моделью данных
Концептуальная — сущности и связи для бизнеса. Логическая — атрибуты, ключи, нормализация. Физическая — типы колонок, индексы, партиции в PostgreSQL.
Какой уровень знаний реляционных баз данных
SELECT, JOIN (INNER/LEFT), GROUP BY, подзапросы, индексы, первичный/внешний ключ, транзакции ACID.
Какие знаешь виды нереляционных БД
Document (MongoDB), key-value (Redis), column (Cassandra), graph (Neo4j), time-series.
В чём разница между шардированием и партиционированием БД
Партиционирование — деление таблицы внутри одного сервера. Шардирование — распределение данных между несколькими серверами/нодами.
Какие типы данных лучше не использовать в PostgreSQL
CHAR вместо VARCHAR для переменной длины, JSON вместо нормализованных колонок без нужды, oversized VARCHAR, timestamp without timezone для глобальных систем.
Есть ли опыт масштабирования БД
Read replicas, партиционирование по дате, кэширование, индексы, connection pooling.
Фишка: В вакансии — PostgreSQL на уровне запросов: ждут JOIN по связанным сущностям (застрахованный ↔ полис ↔ медицинская услуга).
Базовые знания 152-ФЗ при работе с ПДн
Категории ПДн, согласие, цели обработки, локализация, уровень защищённости, уведомление Роскомнадзора, права субъекта, трансграничная передача.
Есть ли опыт шифрования данных
TLS в транспорте, шифрование at rest, хеширование паролей (bcrypt), маскирование в логах, tokenization для чувствительных полей.
Как обеспечить безопасность при интеграции с внешними МО
OAuth2/mTLS, whitelist IP, rate limiting, аудит, минимизация передаваемых полей, соглашения о обработке ПДн.
Ловушка: ПДн в логах и тестовых данных — табу. На собесе покажи, что знаешь про маскирование ФИО, СНИЛС, полис.
Фишка: Проект ДМС — центральная тема: обмен ПДн между страховщиком и клиниками. Это главный доменный контекст вакансии.
Есть ли опыт участия в оценке задач
Story points, t-shirt sizing, Planning Poker. Учёт рисков и зависимостей при оценке интеграционных задач.
Есть ли опыт учёта рисков задач
Технические риски (нестабильный API партнёра), регуляторные (ПДн), зависимости от других команд.
Кто занимался оценкой задач на прошлом проекте
Покажи понимание процесса: аналитик оценивает сложность спецификации, dev — реализацию, вместе на refinement.
Кто занимался приоритизацией задач на прошлом проекте
Product owner / заказчик + backlog grooming. Критерии: бизнес-ценность, риски, зависимости, регуляторные дедлайны.
Есть ли опыт работы с PlantUML
Текстовые диаграммы в Git: sequence, component, ER. Версионируются вместе с кодом.
Есть ли опыт прототипирования фронтенд-решений
Figma, mockups для согласования UI с заказчиком до разработки — плюс, не обязательное требование.
Совет: Сбер использует JIRA + Confluence + Git — подготовь примеры, как ты ведёшь спецификации и связь задач с документацией.
Спроектировать REST endpoint обмена данными застрахованного
Медицинская организация запрашивает данные застрахованного по номеру полиса для оформления гарантийного письма. Опиши: URI, метод, headers, body запроса и ответа (JSON Schema), статус-коды ошибок, требования безопасности (OAuth2, TLS). Учти 152-ФЗ: минимальный набор полей.
GET /api/v1/policies/{policyNumber}/insured или POST /api/v1/insured/lookup с body {policyNumber, moId}. Headers: Authorization: Bearer <token>, X-Request-Id. Response 200: {policyNumber, insuredId, fullName (masked), birthDate, programCode, status, validFrom, validTo}. Errors: 401 unauthorized, 403 mo not allowed, 404 not found, 422 invalid policy format. TLS 1.2+, OAuth2 client credentials, аудит каждого запроса. Передавать только поля необходимые для гарантийного письма.Сложность: O(1) по запросу, O(log n) с индексом на policyNumber
SQL: найти активные полисы ДМС с просроченной синхронизацией
Таблицы: policies (id, policy_number, status, valid_to), sync_log (policy_id, last_sync_at, partner_id). Найди полисы со status='ACTIVE' и valid_to > NOW(), у которых last_sync_at старше 24 часов или синхронизация отсутствует.
SELECT p.id, p.policy_number, p.valid_to, sl.last_sync_at FROM policies p LEFT JOIN sync_log sl ON sl.policy_id = p.id WHERE p.status = 'ACTIVE' AND p.valid_to > NOW() AND (sl.last_sync_at IS NULL OR sl.last_sync_at < NOW() - INTERVAL '24 hours');
Сложность: O(n) при full scan, O(log n) с индексами на status и last_sync_at
Кейс: классификация инцидента
МО сообщает: «При запросе данных пациента получаем ошибку 500, вчера работало». Опиши шаги анализа: воспроизведение, классификация (требование vs реализация vs данные), артефакты и критерии закрытия.
1) Собрать: policyNumber, timestamp, requestId, response body, МО id. 2) Воспроизвести в Postman с prod-like данными. 3) Проверить логи по X-Request-Id. 4) Классификация: если спека не описывала кейс — требование; если код падает на валидном запросе — дефект реализации; если данные неконсистентны — проблема данных. 5) Артефакт: баг-репорт с шагами, expected/actual, логи. 6) Критерии закрытия: 200 на воспроизведённом сценарии + регресс.
Сложность: Процессный кейс
Сопоставление атрибутов JSON ↔ XSD
Внутренняя система шлёт JSON {patientSnils, policyNum, serviceDate}, внешний партнёр ждёт XML по XSD с полями Snils, PolicyNumber, DateOfService. Опиши правила маппинга и валидации.
Mapping: patientSnils → Snils (regex ^\d{11}$), policyNum → PolicyNumber (alphanumeric 10-20), serviceDate → DateOfService (ISO 8601 → YYYY-MM-DD). Валидация до отправки: required fields, формат СНИЛС, дата не в будущем. При ошибке — 422 с полем и кодом VALIDATION_ERROR. Трансформация: JSON-to-XML middleware или шаблон. Логировать только masked значения.Сложность: O(1) на запись
Каркас ответа
3 дня
7 дней
14 дней
| Блок | Готов, если... |
|---|---|
| REST и интеграции | можешь описать endpoint с headers, body schema, error model и OAuth2 без шпаргалки |
| Требования | можешь за 2 минуты объяснить user story, критерии приёмки и атрибуты качества требований |
| UML | можешь нарисовать sequence diagram для интеграционного сценария с 3 участниками |
| PostgreSQL | можешь написать JOIN с фильтром по дате и NULL без подсказок |
| 152-ФЗ и ПДн | можешь перечислить меры защиты при обмене ПДн с внешней МО |
| Кейсы | можешь разложить инцидент 500 на шаги воспроизведения и классификации |
| Behavioral | есть 3 готовых STAR-истории: интеграция, инцидент, защита решения |
В день собеседования
