Собеседование на системного аналитика в Яндекс Лавке

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

Яндекс Лавка — сервис быстрой доставки продуктов (q-commerce) внутри Яндекс Go. Для системного аналитика это одно из самых «горячих» мест по инженерной сложности, потому что почти всё здесь работает в реальном времени и на стыке множества систем.

Системный аналитик в Лавке проектирует API заказа, интеграцию с dark store (склад-магазин без покупателей: WMS для управления товаром, касса), трекинг курьеров в реальном времени и интеграцию с Яндекс Pay для платежей. Специфика в том, что заказ проходит через длинную цепочку сервисов за считанные минуты: собрать корзину, зарезервировать товар на складе, провести оплату, назначить курьера, отследить доставку, обработать отмену или возврат. Каждый шаг — это отдельный сервис, отдельный контракт API и отдельный сценарий отказа, который нужно продумать.

Отсюда и акценты собеса: real-time-мышление, надёжность распределённых сценариев, идемпотентность операций (чтобы повторный запрос не создал второй заказ или второе списание) и умение аккуратно описать интеграцию между сервисами.

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

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

1. Скрининг с рекрутером

Знакомство и проверка соответствия вакансии: опыт с интеграциями и API, за какие системы отвечали, мотивация. Заготовьте короткий рассказ о том, какие сервисы проектировали и какие задачи решали.

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

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

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

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

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

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

5. Кейс и системный дизайн

Открытая задача на проектирование интеграции или сценария end-to-end: как связать сервисы, где обеспечить надёжность и согласованность, что делать при сбое одного из звеньев.

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

Разбор ситуаций из опыта в формате STAR, работа в команде, культурное соответствие.

Что Яндекс Лавка ценит в SA

• Проектирование API. Уверенное владение REST и понимание, где выигрывает gRPC (внутренние синхронные вызовы между сервисами с жёстким контрактом). Идемпотентность, коды ошибок, версионирование.
• Real-time-мышление. Понимание, что данные о заказе и курьере меняются ежесекундно, и умение проектировать под это — статусы, события, обновления в реальном времени.
• Базы данных и SQL. Проектирование схемы под сценарий и уверенные запросы уровня middle–senior.
• Операционное мышление. Внимание к нештатным сценариям: отмены, возвраты, недоставка, товар закончился на складе. В q-commerce это не край, а повседневность.
• Понимание распределённых систем. Согласованность данных между сервисами, обработка частичных отказов, повторные попытки и их последствия.

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

• «API заказа: процесс end-to-end». Опишите путь заказа от корзины до доставки: какие сервисы участвуют, какие вызовы между ними, где границы транзакций.
• «Интеграция с dark store (WMS)». Как резервировать товар на складе, что делать, если позиции нет в наличии, как синхронизировать остатки.
• «Трекинг курьера в реальном времени». Как устроен поток обновлений геопозиции и статуса, как доставить его в приложение клиента с приемлемой задержкой.
• «Интеграция с Яндекс Pay». Проектирование платёжного сценария: авторизация, списание, возврат, и главное — идемпотентность, чтобы не списать дважды.
• «Cancellation flow (отмена заказа)». Один из любимых кейсов: как корректно откатить резерв товара, вернуть оплату и уведомить курьера, если клиент отменил заказ на разных стадиях.

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

1. API-дизайн. REST как основа плюс понимание gRPC: контракты, идемпотентность, коды ошибок, версионирование. Опора — проектирование REST API.
2. Базы данных и SQL. Проектирование схемы под заказ и статусы, уверенные запросы уровня middle–senior.
3. Распределённые системы. Согласованность между сервисами, частичные отказы, идемпотентность, паттерны надёжности.
4. BPMN. Тренируйтесь раскладывать сценарии на шаги, роли и ветвления, включая нештатные пути.
5. Real-time. Разберитесь, как проектировать сценарии с потоком событий и обновлениями в реальном времени.

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

• Слабый SQL. Путаться в join'ах и оконных функциях на middle–senior позиции — заметный минус.
• API без идемпотентности. Спроектировать создание заказа или платёж так, что повтор запроса создаёт дубль, — классическая ошибка. В q-commerce повторные запросы неизбежны (сеть, ретраи), и это надо закладывать в контракт.
• Игнорировать real-time и нештатные сценарии. Описать только happy path, забыв про отмены, недоставку и отсутствие товара, — значит показать, что не понимаете специфику Лавки.
• Проектировать интеграцию без учёта отказов. Считать, что все вызовы между сервисами всегда успешны, — в распределённой системе так не бывает.

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

• Собеседование на SA в Я.Go
• Собеседование на SA в Купер
• REST API на собесе SA
• Собеседование на PM в Я.Лавке
• Собеседование на DS в Я.Лавке

FAQ

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

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

Нужен ли опыт в q-commerce или доставке?

Желателен, но не обязателен. Важнее показать, что вы понимаете специфику real-time-систем и интеграций: идемпотентность, обработка отказов, нештатные сценарии. Опыт из финтеха, логистики или любых highload-интеграций хорошо переносится.

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

Middle–senior: join'ы, группировки, оконные функции, осмысленное проектирование схемы данных под сценарий. Ждут не отдельные SELECT'ы, а умение работать с моделью данных заказа целиком.

Что важнее — REST или gRPC?

Базой должен быть уверенный REST. gRPC полезно понимать как инструмент для внутренних синхронных вызовов между сервисами с жёстким контрактом и низкой задержкой. На собесе ценят не выбор «одного правильного», а умение объяснить, где какой протокол уместен.

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

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