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

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

Aviasales — крупный российский метапоиск авиабилетов. Системный аналитик проектирует интеграции с десятками OTA и авиакомпаний (S7, Аэрофлот, Booking), внутренние API для search-функционала, страховые сервисы, отельную дочку (Hotellook), B2B-предложения.

Особенность: метапоиск работает на скорости — пользователь видит сотни вариантов за 2-3 секунды. SA проектирует архитектуру, где десятки внешних API объединяются в единый response в реальном времени. Требования к latency, fallback, кешированию — критичны. Подробнее — на странице карьеры Aviasales.

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

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

Опыт, мотивация. Специфика:

• Был ли опыт с travel / метапоиском / интеграциями
• Знание SQL + теория БД
• Готовность к real-time-системам

2. Требования и BPMN (60 минут)

Сбор требований для интеграций, use cases.

3. API + интеграции (60-90 минут)

REST / gRPC, кеширование, fallback, идемпотентность. Архитектура интеграций с внешними OTA.

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

SQL deep, нормализация. Redis / Memcached для кешей.

5. Кейс-интервью (60 минут)

«Спроектируй интеграцию с новой OTA», «архитектура страхового добавления», «caching strategy для поиска».

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

STAR + стратегический разговор.

Что Aviasales ценит в SA

• API-design. REST / gRPC, latency, fallback.
• Caching. Redis / Memcached в реальном времени.
• БД. Уверенный SQL, понимание sharding.
• Distributed systems. CAP, eventual consistency.
• Travel-domain. Понимание тарифов, GDS, fare rules.

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

• «Интеграция с новой OTA: схема, обработка отказов»
• «Caching strategy для search results: invalidation, TTL»
• «Архитектура страхового cross-sell»
• «Fallback при недоступности OTA: что показывать пользователю»
• «Sharding базы для миллионов поисков в день»

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

1. API. REST + gRPC, кеширование, идемпотентность.
2. Caching. Redis, Memcached, TTL, invalidation.
3. БД. Sharding, репликация.
4. Distributed. CAP, eventual consistency.
5. Travel-domain. GDS, fare rules.

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

• API без latency budget. В метапоиске latency — критично.
• Caching поверхностно. Без понимания invalidation — слабо.
• Игнорировать fallback. Внешние OTA падают регулярно.
• Слабая SQL. Уверенный middle.

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

• Собеседование на SA в Яндекс
• CAP на собесе SA
• 2PC vs Saga на собесе SA
• REST API на собесе SA
• Собеседование на PM в Aviasales

FAQ

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

Обычно 4-5: рекрутер → BPMN → API → БД → кейс → поведенческое + финал. Срок 4-5 недель.

Нужен ли travel-опыт?

Желателен. Релевантным считается e-com, маркетплейс, real-time-системы.

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

Уверенный middle.

Спрашивают ли caching?

Да, в travel — это основа архитектуры.

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

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