Advanced Frontend Engineer Challenge

Искренне благодарим вас за время и внимание к этому челленджу и надеемся на долгосрочную совместную командную работу

Подписывайтесь на канал с новыми челленджами: @atls_challenges

Не забудьте сперва поставить Star. Спасибо!

Этот репозиторий — инженерный челлендж для кандидатов на frontend позиции

Задача узкая по продукту и широкая по инженерным решениям: нам важно увидеть не только верстку, а умение проектировать клиентскую часть под реальный backend

Контекст

Вам нужно взять любой понравившийся fork backend/fullstack-челленджа и реализовать под него frontend для 3 сценариев:

1. Регистрация
2. Авторизация
3. Восстановление пароля

Дизайн остается тем же: Figma-файл Orbitto Service Файл доступен для создания копии в ваш workspace, но права на редактирование исходного файла не выдаются Запросы на доступ к редактированию исходного файла не рассматриваются

Что важно

Решение должно демонстрировать инженерную зрелость:

• Декомпозиция интерфейса и переиспользуемость компонентов
• Управление состоянием и асинхронными сценариями
• Работа с контрактами backend (ошибки, edge-cases, нестабильные ответы)
• Доступность (a11y), UX-состояния и производительность
• Осознанная аргументация trade-offs

Просто сверстать макет не считается целевым уровнем решения для этого челленджа

Обязательные требования

1. UI и UX

• Реализуйте все экраны и состояния auth-флоу по дизайну
• Обработайте loading/error/empty/success-состояния
• Обеспечьте адаптивность минимум для desktop и mobile

2. Интеграция с backend

• Подключитесь к выбранному fork и его контрактам
• Обработайте реальные ответы сервиса, включая неуспешные сценарии
• Зафиксируйте в README предположения по контрактам

3. Архитектура frontend

• Покажите структуру слоев/модулей и границы ответственности
• Избегайте проекта в формате все в одном components/ и services/
• Опишите ключевые инженерные решения в README

4. Качество и надежность

• Добавьте тесты критичных пользовательских сценариев (unit/integration/e2e — на ваш выбор)
• Добавьте базовую защиту от типичных UX-проблем (повторные отправки, race conditions, устаревшие запросы)

5. Технологические решения

• Фреймворк и стек выбираете самостоятельно
• Ограничений по стеку нет: React, Vue, Angular, Svelte, WASM и любые другие варианты
• В README обязательно объясните выбор и альтернативы, которые рассматривали

Ограничения и анти-паттерны

Следующие подходы считаются слабым решением:

• Визуальный клон без инженерной структуры
• Игнорирование неуспешных ответов и ошибок backend
• Локальные хаки без объяснения trade-offs и последствий
• Полная завязка на конкретный фреймворк без аргументации

Что нужно сдать

1. Исходный код frontend в вашем fork
2. Обновленный README в вашем fork с:

• как запустить проект
• явной ссылкой на выбранный backend fork
• как устроена архитектура frontend
• какие trade-offs были приняты
• что бы вы сделали следующим шагом в production-версии
• ссылкой на демо или скринкаст основных сценариев (если есть)

3. Набор тестов и инструкции по запуску

Формат выполнения

1. Выберите backend fork, с которым хотите работать
2. Сделайте fork этого репозитория
3. Реализуйте frontend-решение под выбранный backend
4. Оформите результат в README
5. Отправьте в отклике:

• ссылку на ваш frontend fork
• ссылку на moodboard
• ссылку на anti-moodboard

Использование ИИ

• Использование ИИ-инструментов в рамках челленджа разрешено
• Если используете ИИ, добавьте в ваш fork папку .agents, чтобы было видно, как вы строили процесс решения

Критерии оценки

1. Качество архитектуры frontend и управляемость кода
2. Корректность auth-флоу и интеграции с backend
3. Качество UX-состояний, обработки ошибок и адаптивности
4. Тестируемость и надежность ключевых сценариев
5. Ясность инженерной аргументации в README

Бонусные сигналы

• Продуманная мини-дизайн-система или слой UI-kit внутри решения
• Стратегия типизации контрактов (например, codegen/typed clients)
• Базовая наблюдаемость фронта (telemetry/error tracking) с аргументацией, где это уместно
• Использование микрофронтов, если это уместно и инженерно оправдано
• Использование FSD с аргументацией границ и композиции слоев
• Следование SOLID в архитектуре клиентской части

Важно

Нас интересует не идеальный пиксель-перфект любой ценой, а качество инженерного мышления и способность строить устойчивый frontend под реальный backend