Собеседование на системного аналитика в Купер

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

Купер (бывший СберМаркет) — сервис доставки продуктов и товаров в составе экосистемы Сбера. Для системного аналитика это в первую очередь маркетплейс: между покупателем и его заказом стоит длинная цепочка участников — сам магазин-партнёр (Ашан, Метро, Лента и десятки других), сборщик, который ходит по торговому залу, курьер и служба поддержки. SA проектирует API и процессы, которые связывают всех этих участников в один сценарий «оформил заказ — получил пакеты у двери».

Главная особенность роли здесь — интеграции. Каждый ритейлер отдаёт свой каталог, остатки и цены в собственном формате, и SA придумывает, как привести это к единой модели: как часто синхронизировать остатки, что делать, когда товар кончился прямо во время сборки, как согласовать замену с покупателем. Плюс всё это real-time: статус заказа, геопозиция курьера и наличие товара меняются постоянно. Поэтому на собесе много внимания уделяют не «нарисуй REST-эндпоинт», а «опиши процесс целиком, с учётом сбоев на стороне партнёра».

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

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

Обычно 4–5 этапов. Точное число зависит от команды и грейда, но структура типовая для SA в крупном e-commerce.

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

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

2. Процессы и BPMN (45–60 минут)

Просят описать бизнес-процесс сквозь все системы: например, оформление заказа от корзины до передачи курьеру. Смотрят, умеете ли вы нотировать процесс (BPMN), выделять роли и шлюзы, обрабатывать альтернативные ветки — товара нет, оплата не прошла, курьер не вышел. Ключевое — не забыть про исключения, а не только про happy path.

3. Проектирование API (60 минут)

Дают кейс на интеграцию и просят спроектировать контракт: методы, форматы запроса и ответа, коды ошибок, идемпотентность, версионирование. Часто это REST, но у части ритейлеров интеграции исторически на SOAP, поэтому оба стиля стоит понимать. Отдельно спрашивают про обработку ошибок и таймаутов: что вернуть клиенту, если магазин не ответил вовремя.

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

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

5. Кейс + поведенческое и финал (60 минут)

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

Что Купер ценит в SA

• Проектирование API. Понимание REST и SOAP, контрактов, кодов ошибок, идемпотентности и версионирования — потому что интеграций много и они разные.
• SQL и модель данных. Уверенный middle: спроектировать схему под заказы и замены, написать нетривиальный запрос без подсказок.
• Маркетплейс-мышление. Держать в голове несколько сторон сразу: покупатель, ритейлер, сборщик, курьер — и понимать, что у каждой свои интересы и свои сбои.
• Операционное мышление. Думать про сбои и крайние случаи: партнёр не ответил, товар кончился при сборке, курьер не вышел. Проектировать так, чтобы система деградировала предсказуемо.
• Работа со стейкхолдерами. Умение собрать и согласовать требования от бизнеса, разработки и партнёров, оформить их так, чтобы команда однозначно поняла.

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

• «Интеграция с новым ритейлером». Как принять его каталог, остатки и цены, привести к единой модели, синхронизировать наличие и обработать расхождения.
• «Real-time трекинг курьера». Как передавать геопозицию и статусы, с какой частотой, что показывать покупателю при потере связи.
• «Процесс замены товара». Товара не оказалось при сборке: как предложить замену, согласовать с покупателем, пересчитать чек и не сломать оплату.
• «B2B-кабинет ритейлера». Какие данные и операции нужны партнёру, как разграничить доступ, что отдавать через API.
• «Возврат (refund) заказа». Как устроить отмену и возврат денег, чтобы состояния заказа и платежа не разъехались.

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

1. API. Повторите REST-контракты и разберите SOAP-интеграции: методы, коды ошибок, идемпотентность, версионирование, таймауты.
2. Базы данных и SQL. Прокачайте JOIN, агрегации и оконные функции, потренируйтесь проектировать модель под заказы и замены.
3. Маркетплейс-логика. Разберите, как устроены сценарии доставки продуктов: сборка, замены, отмены, трекинг.
4. BPMN. Научитесь описывать сквозной процесс с ролями, шлюзами и альтернативными ветками, а не только happy path.
5. Операционные сценарии. Продумайте частые сбои интеграций и как система должна вести себя при недоступности партнёра.

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

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

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

• Собеседование на SA в Самокат
• Собеседование на SA в МегаМаркете
• REST API на собесе SA
• Собеседование на PM в Купер
• Собеседование на DE в Купер

FAQ

Сколько этапов на собесе SA в Купер?

Обычно 4–5: скрининг с рекрутером, процессы/BPMN, проектирование API, базы данных и SQL, финальный кейс с поведенческими вопросами. Точное число зависит от команды и грейда.

Нужен ли опыт в food-delivery или e-commerce?

Желателен, но не обязателен. Плюсом будет любой опыт с интеграциями и маркетплейс-логикой: несколько сторон, real-time статусы, обработка сбоев на стороне партнёров.

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

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

REST или SOAP спрашивают?

В основном REST, но у части ритейлеров интеграции исторически на SOAP, поэтому стоит понимать оба стиля и уметь объяснить разницу и когда что уместно.

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

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