# Оценка: Aviasales — Frontend Developer (GEM / User Platform)

**Дата:** 2026-07-21
**Архетип:** Frontend Developer — фреймворк в JD не указан явно, домен (авторизация/профиль) хорошо пересекается с сильной стороной кандидата
**Балл:** 2.8/5
**URL:** https://www.aviasales.ru/about/vacancies/4288807
**Legitimacy:** Proceed with Caution
**PDF:** не создан (балл ниже порога 3.0) — на грани, стоит рассмотреть ручную генерацию через `/career-ops pdf aviasales-gem-frontend`, если кандидат готова закрыть разрыв по стажу в сопроводительном

---

## A) Резюме роли

| Поле | Значение |
|------|----------|
| Архетип | Frontend Developer — конкретный фреймворк (React/Vue/Angular) в тексте вакансии не назван, только "frontend developer" |
| Domain | User Platform — авторизация, уведомления, профиль и пользовательские данные |
| Function | Build — бизнес-логика и новые функции для профиля/авторизации, автотесты совместно с QA, работа с техдолгом |
| Seniority | "Опыт коммерческой продуктовой разработки frontend от 3-х лет" |
| Формат работы | **Полностью удалённо, "в любой точке мира"**, оплата в долларах — явно указано как принцип работы всей компании, не только этой команды |
| Размер команды | Не указан |
| Оформление | Не указано в JD (вероятно, GPH/самозанятость или зарубежный договор, учитывая "не привязываемся к локации, платим в долларах") — стоит уточнить формат оформления на собеседовании, так как это может влиять на социальные гарантии по сравнению с ТК РФ |
| TL;DR | Самая привлекательная вакансия партии по формату работы (remote-first, без бюрократии) и по доменному пересечению с сильной стороной кандидата (авторизация/профиль = RBAC-опыт), но стек не подтверждён явно и требуемый стаж (3+ года) на ~1-1.5 года превышает текущий опыт кандидата |

**Vibe команды:** JD прямо формулирует принципы работы — "без бюрократии: удобные процессы здорового человека, горизонтальные и открытые коммуникации, быстрое обсуждение идей и принятие решений" — сильный, явно сформулированный сигнал минимальной бюрократии и высокой автономии, редкий случай, когда это не инференс, а прямая цитата вакансии. Менторство и грейдовая сетка роста в тексте не упомянуты — недостаточно данных, стоит уточнить на собеседовании.

## B) Совпадение с CV

| Требование JD | Совпадение с CV |
|---|---|
| Опыт коммерческой продуктовой frontend-разработки от 3 лет | Частичный gap — у кандидата ~1,5-2 года коммерческого фронтенд-опыта (с ноября 2024), не 3+ |
| Чистый и понятный код | Совпадение (качественно неизмеримо в JD, но подтверждается практикой рефакторинга и фикса ~20+ багов на "Здесь Аптека" и РМК) |
| Функциональность профиля, авторизации | **Сильное совпадение** — прямая релевантность: кандидат самостоятельно спроектировала ролевую модель авторизации (RBAC) для ~20 пользователей в ЕКОМ, с разграничением по отделам, и объясняла бэкенд-команде принцип работы модели |
| Покрытие автотестами совместно с QA | Совпадение — Vitest (unit), Storybook, Playwright E2E на РМК |
| Работа с техдолгом | Совпадение — стабилизация legacy-проекта РМК (~20 багов, включая сложный кейс с замыканием в реактивной переменной) |
| Конкретный фреймворк (React/Vue/etc.) | **Не указан в JD** — нейтрально, не gap и не совпадение; требует уточнения на собеседовании |

**Пробелы:**
1. Стаж (3+ года vs ~1,5-2) — nice-to-have/soft blocker, не абсолютный: кандидат ведёт три продукта одновременно (веб с нуля, legacy, мобильное приложение), что может частично компенсировать разницу в календарном стаже глубиной ответственности.
2. Фреймворк не подтверждён — стратегия: явно спросить в сопроводительном/на собеседовании, какой стек использует команда GEM/User Platform, вместо того чтобы предполагать совпадение или несовпадение.
3. Нет данных о формате оформления (ТК РФ / GPH / зарубежный контракт) — важно для кандидата с гражданством РФ без опыта работы по иностранным контрактам.

## C) Уровень и стратегия

1. **Уровень в JD** — заявлен как "от 3 лет", но конкретных Senior-маркеров (архитектура, менторство, highload) в тексте нет — задачи описаны в терминах продуктовой разработки фич и техдолга, что ближе к Middle по сути задач, несмотря на формальный стажевый порог.
2. **Естественный уровень кандидата** — Middle для архетипа Frontend, что практически совпадает с фактическим уровнем задач в JD, только формальный стажевый ценз чуть выше.
3. **План "продать senior без обмана":** сделать акцент на широте ответственности (три продукта одновременно, RBAC-дизайн наравне с бэкенд-командой, самостоятельная UI/UX работа) — это компенсирует более короткий календарный стаж глубиной и разнообразием решаемых задач.
4. **План "если понизят":** маловероятен сценарий понижения при remote-найме без формальных грейдов — скорее вопрос "пройдёт/не пройдёт" отбор по стажу, стоит явно указать RBAC-проект как компенсирующий фактор в отклике.

## D) Компенсация и спрос

| Показатель | Значение | Источник |
|---|---|---|
| Формат оплаты | В долларах, "не привязываемся к локации" | со страницы вакансии |
| Отзывы сотрудников Aviasales | Смешанные — хвалят стабильную зарплату, соцпакет (ДМС, компенсация английского/психотерапии, спорт), удалённый формат; отмечают сложности адаптации новичков в устоявшейся команде | [Dream Job — отзывы Aviasales](https://dreamjob.ru/employers/102629) |
| Общий диапазон Frontend-разработчика по РФ-рынку (для ориентира, не всегда применимо к валютной оплате) | 210 000–260 000+ ₽/мес эквивалент | [ГородРабот.ру](https://moskva.gorodrabot.ru/salaries/frontend-razrabotchik) |

Конкретная сумма в JD не указана. Оплата в долларах может как превышать, так и не совпадать с целевым диапазоном кандидата (140 000–160 000+ ₽/мес на руки) в зависимости от курса и структуры контракта — важно уточнить на первом контакте.

## E) План персонализации

| # | Раздел | Текущее состояние | Предлагаемое изменение | Почему |
|---|--------|--------------------|--------------------------|--------|
| 1 | Summary | Общий Vue3+Flutter профиль | Выдвинуть на первый план RBAC/авторизацию как ключевой проект | Прямое совпадение с доменом команды (User Platform: авторизация, профиль) |
| 2 | Опыт | Порядок пунктов ЕКОМ | Поставить RBAC-дизайн первым буллетом в разделе ЕКОМ | Самое релевантное достижение для этой конкретной вакансии |
| 3 | Сопроводительное | — | Явно адресовать разрыв в стаже (3+ лет vs ~1,5-2), сославшись на одновременное ведение трёх продуктов и самостоятельную RBAC-архитектуру | Превентивно закрывает единственный формальный blocker |
| 4 | Вопрос рекрутеру | — | Уточнить конкретный frontend-фреймворк команды и формат оформления (ТК РФ/GPH/иностранный контракт) | JD не раскрывает эти детали, критично для оценки соответствия и юридических гарантий |

## F) План собеседований

| # | Требование JD | История STAR+R | S | T | A | R | Reflection |
|---|-----------------|------------------|---|---|---|---|------------|
| 1 | Функциональность авторизации/профиля | RBAC-дизайн в ЕКОМ | Нужно было разграничить доступ ~20 пользователей офиса по отделам (логистика не видит заказы клиентского отдела и наоборот) | Спроектировать ролевую модель авторизации | Самостоятельно спроектировала модель ролей, опираясь на профильное ИБ-образование, и объяснила бэкенд-команде принцип работы и отличие от других моделей доступа | Модель внедрена и используется всеми ~20 пользователями | Ключевой урок: авторизация — это не только код, но и коммуникация модели нетехническим стейкхолдерам (отделам) |
| 2 | Работа с техдолгом | Стабилизация РМК (legacy) | Legacy-проект на 1200 точках, ~20 багов, включая сложный баг с замыканием (реактивная переменная в глобальном классе клавиатуры) | Найти и исправить причину, не сломав продакшн на 1200 точках | Диагностировала утечку через реактивные переменные, исправила биндинг | Клавиатура снова стабильно работает во всех точках | Reflection: в legacy-коде реактивность требует явного контроля жизненного цикла переменных, иначе накапливаются скрытые утечки |
| 3 | Покрытие автотестами с QA | Внедрение Playwright E2E на РМК | Не было E2E-покрытия критичного legacy-функционала | Внедрить Playwright тесты на этапе стабилизации | Внедрила E2E-тесты (на этапе раскатки) | Повышается уверенность в изменениях без ручной регрессии | Reflection: внедрение тестов на legacy эффективнее начинать с самых часто ломающихся сценариев, а не пытаться покрыть всё сразу |

**Рекомендуемый кейс:** RBAC-проект ЕКОМ — прямое пересечение с доменом команды (авторизация/профиль), плюс демонстрирует связку ИБ-образования и практики.

**Вопрос-ловушка и ответ:** "Почему стаж всего 1,5-2 года при требовании 3+?" → "За это время я вела три параллельных продукта (веб с нуля, legacy на 1200 точках, мобильное приложение), включая самостоятельное проектирование модели авторизации — глубина и разнообразие задач компенсируют более короткий календарный стаж."

## G) Легитимность вакансии

**Оценка: Proceed with Caution**

| Сигнал | Наблюдение | Вес |
|---|---|---|
| Freshness / apply-контрол | Активная кнопка "Откликнуться", защита ALTCHA от ботов на форме (стандартная практика, не признак фиктивности) | Positive |
| Качество описания | Умеренная специфичность — команда (User Platform/GEM) и зона ответственности названы конкретно, но фреймворк/стек не указан вовсе, что нетипично для качественной технической вакансии | Concerning (слабый сигнал) |
| Компания | Aviasales — известный, стабильно растущий продукт (агрегатор авиабилетов), публичные отзывы сотрудников подтверждают реальный remote-найм | Positive |
| Reposting | Одна запись в scan-history.tsv (2026-07-14), повторов не найдено | Neutral |

**Контекст:** Отсутствие указания фреймворка — не редкость для команд, где стек менее важен, чем продуктовое мышление ("умение понимать задачи бизнеса и пользователя" вынесено в JD на первый план перед конкретными технологиями) — типично для продуктовых команд зрелых компаний, не обязательно признак ghost job.

---

## Извлечённые ключевые слова

Frontend developer, User Platform, авторизация, профиль, уведомления, пользовательские данные, бизнес-логика, автотесты, QA, техдолг, remote, удалённо, продуктовая разработка, приоритизация, оценка трудозатрат, ДМС, психотерапия, GEM