Собеседование на системного аналитика в СберЗдоровье

Почему СберЗдоровье — особенный работодатель для SA

СберЗдоровье — medtech-направление Сбера: телемедицина, электронная медкарта, запись к врачу, аптечный маркетплейс, сервисы для страховых. Системный аналитик здесь проектирует не абстрактные интеграции, а системы, где на другом конце — здоровье человека и персональные данные особой категории. Это меняет планку: ошибка в API телеконсультации или в правах доступа к медкарте — это не потерянная конверсия, а нарушение врачебной тайны.

Ключевая специфика — стык двух миров. С одной стороны, продуктовая разработка в темпе Сбера: мобильное приложение, видеоконсультации, real-time-чат врача с пациентом. С другой — интеграция с государственными и страховыми системами: ОМС-полисы через СМЭВ, ДМС-программы страховых, электронные рецепты, обмен медицинскими документами. SA постоянно балансирует между «быстро выкатить фичу» и «пройти согласование по 152-ФЗ и медтайне». Актуальные вакансии — на карьерной странице Сбера.

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

Обычно 5–6 раундов, срок 3–6 недель. Точный набор зависит от команды (телемедицина, страховые сервисы, аптека), но каркас у SA-собеса стабильный.

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

Знакомство и проверка базовой совместимости. Расскажите про опыт SA: какие продукты вели, работали ли с интеграциями и чувствительными данными. Плюсом идёт любой medtech- или fintech-бэкграунд, потому что в обоих есть compliance и регуляторика. Заранее подготовьте питч на 90 секунд: продукт, ваша роль, самый сложный кейс интеграции.

2. BPMN и бизнес-процессы (45–60 минут)

Медицинские сценарии — это длинные процессы с ветвлениями: запись на приём, отмена и перенос, эскалация к дежурному врачу, выписка электронного рецепта. Вас попросят декомпозировать такой флоу в BPMN: показать шлюзы (gateway), события, обработку отмен (compensation). Смотрят, умеете ли вы находить «неочевидные» ветки — что происходит, если пациент не пришёл, если врач недоступен, если полис не подтвердился. Подготовка: BPMN и требования.

3. REST и SOAP API (60–90 минут)

Здесь встречаются оба стиля. Продуктовые сервисы — это REST/JSON, а обмен с государственными системами (ОМС через СМЭВ) исторически идёт по SOAP. Готовьтесь объяснить HTTP-методы и статус-коды, идемпотентность и ретраи, версионирование API, аутентификацию (OAuth2/OIDC), и когда оправдан SOAP вместо REST. Частый кейс: «Спроектируй API телеконсультации — какие эндпоинты, какой контракт, как передаём медицинские вложения». Подготовка: REST API design.

4. Базы данных и SQL (45–60 минут)

Уровень — крепкий middle. Спросят про моделирование данных под медкарту и историю приёмов, нормализацию, индексы, джоины, оконные функции. Отдельный акцент — хранение чувствительных данных: разделение PII и медицинских данных, маскирование, шифрование полей. Подготовьте ответ на вопрос «как спроектировать таблицы приёмов так, чтобы врач видел только своих пациентов». Потренировать SQL можно в SQL-тренажёре.

5. Архитектура и compliance (45–60 минут)

Главная особенность СберЗдоровья. Кроме обычного system design (как связать сервисы, где очередь, где кэш, как обеспечить консистентность), обязательно всплывёт регуляторика: 152-ФЗ о персональных данных, медицинская тайна (323-ФЗ), audit-trail на каждый доступ к медкарте. Хороший ответ показывает, что вы закладываете аудит и разграничение прав в дизайн с самого начала, а не «прикрутим потом». Подготовка: 152-ФЗ ПДн на собесе SA.

6. Поведенческое и финал

STAR-истории плюс культурный фит. Акцент — на работе с ограничениями: как согласовывали решение с безопасностью, как объясняли врачам или бизнесу технические компромиссы, как вели крупную интеграцию от идеи до прода.

Что СберЗдоровье ценит в SA

• Уверенный API-дизайн. REST для продукта и понимание SOAP для обмена с ОМС через СМЭВ. Умение спроектировать чистый контракт и объяснить, почему именно такой.
• MedTech-домен. Понимание, как устроены телемедицина, ОМС/ДМС, электронные рецепты и медкарта. Даже базовое знание предметной области сильно упрощает разговор.
• Крепкий SQL и моделирование. Данные пациентов надо не только хранить, но и правильно разграничивать по доступу.
• Compliance как часть работы. 152-ФЗ и врачебная тайна — не «вопрос к безопасникам», а требование к архитектуре, которое SA учитывает сам.
• Audit-trail мышление. Любой доступ к медданным должен быть залогирован и восстановим. Это закладывается в дизайн, а не добавляется постфактум.

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

• API телеконсультации. Спроектировать флоу от записи к врачу до видеозвонка и чата: эндпоинты, статусы приёма, обработка отмен и переносов.
• Интеграция с ОМС через СМЭВ. Описать обмен с государственной системой: проверка полиса, формат сообщений, обработка таймаутов и недоступности внешнего сервиса.
• ДМС-сервис для страховых. Как связать программу страховой с записью к врачу и оплатой, где границы ответственности систем.
• Audit-trail доступа к медданным. Спроектировать журнал доступа: кто, когда и к какой записи обращался, чтобы это выдержало проверку.
• Аптечная интеграция. Электронный рецепт и заказ лекарств: как передать назначение из телемедицины в аптечный сервис без потери целостности.

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

1. API: REST + SOAP. Отработайте проектирование REST-контракта и разберитесь, зачем в госинтеграциях до сих пор SOAP. REST API design.
2. SQL и моделирование данных. Джоины, оконные функции, разграничение доступа к чувствительным полям. SQL-тренажёр.
3. Compliance. 152-ФЗ, медицинская тайна, маскирование PII. 152-ФЗ ПДн на собесе SA.
4. MedTech-домен. Разберитесь, как работают телемедицина, ОМС/ДМС, электронный рецепт — хотя бы на уровне пользовательских сценариев.
5. BPMN. Потренируйтесь декомпозировать медицинский процесс со всеми ветками отмен и эскалаций. BPMN и требования.
6. STAR-истории. Крупные интеграции, согласования с безопасностью, объяснение компромиссов бизнесу.

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

• Игнорировать compliance. Ответ «за персональные данные отвечает служба безопасности» проваливает этап. SA обязан закладывать 152-ФЗ и медтайну в архитектуру сам.
• Слабый SQL. На уровне «сделаю простой SELECT» здесь не проходят — нужны джоины, агрегаты и понимание, как разграничить данные пациентов.
• API без audit-trail. Проектировать доступ к медкарте без журналирования — красный флаг. В медицине важно не только «кто может», но и «кто получил доступ и когда».
• Забыть про отказоустойчивость внешних систем. ОМС/СМЭВ может тормозить или падать — если в дизайне нет таймаутов, ретраев и деградации, это заметят.

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

• Собеседование на SA в Сбере
• Собеседование на SA в Ростелекоме
• REST API на собесе SA
• 152-ФЗ ПДн на собесе SA
• Собеседование на PM в СберЗдоровье

FAQ

Сколько этапов в СберЗдоровье для SA?

Обычно 5–6: HR → BPMN → API → БД → архитектура и compliance → фит. Общий срок — 3–6 недель, зависит от команды и загрузки нанимающих.

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

Желателен, но не обязателен. Ценится любой опыт с чувствительными данными и интеграциями — fintech, госсектор, страхование. Главное — показать понимание, что медданные требуют особого обращения.

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

Крепкий middle: джоины, агрегаты, оконные функции, понимание индексов и того, как разграничить доступ к данным пациентов на уровне модели.

Обязательно ли знать СМЭВ и ОМС?

Знать детально протокол не требуют, но понимать, что интеграция с ОМС идёт через государственную систему СМЭВ (часто по SOAP) и требует обработки таймаутов и недоступности — большой плюс.

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

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

Тренируйте системный анализ — откройте тренажёр с 1500+ вопросами для собесов.