Frontend Engineer (Mobile, React Native, Fintech)

Frontend Engineer (Mobile)

Контекст продукта

Мы создаём некастодиальный криптокошелёк с дебетовой картой, KYC, пополнением в фиате и потоками транзакций в реальном времени. Мобильное приложение — основной клиент: онбординг, кошелёк (Privy), дашборд, карта, уведомления, а позже — токены/награды по мере расширения roadmap.

Реализация следует согласованным ID экранов, контрактам навигации и состояниям error / loading / empty, общим для дизайна и продукта (та же дисциплина, что и в формальной UX-спецификации).

Стек, на котором мы строим (ожидаемый)

• React Native + Expo (Prebuild + EAS Build / dev client)
• TypeScript (strict), ESLint + Prettier
• Expo Router или React Navigation — стеки, табы, deep links
• UniWind / NativeWind-style Tailwind-on-RN (или согласованный подход дизайн-системы) + Figma (дизайн-система D-001)
• TanStack Query — server state, кэширование, polling (например, статус выпуска карты)
• Zustand — клиентский UI-стейт (session UI, feature flags, Spend priority — без дублирования серверного кэша)
• Zod — runtime-валидация ответов BFF и форм; React Hook Form для сложных флоу
• Privy (`@privy-io/react-native`) — embedded wallet;
• viem + wagmi — взаимодействие с блокчейном, подключение RPC-провайдера (например, Alchemy), чтение on-chain состояния и исполнение транзакций
• Reanimated 3 (+ Gesture Handler где нужно)
• WebView-изолированные модули для KYC и любых PCI-sensitive флоу (hosted / partner SDK)
• expo-notifications + push; Sentry для ошибок и релизов
• Опционально e2e: Maestro или Detox для критических путей (онбординг, логин)

Архитектура клиента (как мы ожидаем оформлять код)

Мы не догматичны насчёт акронимов, но ожидаем дисциплинированную структуру по мере роста приложения (финтех + много флоу):

• Server state = TanStack Query (источник истины от BFF); не зеркалить его в глобальном сторе и не дублировать в деревьях `useState`.
• Local UI state = Zustand (или эквивалент) для того, что не является сервером: черновики, модалки, Spend priority, feature flags, UI, смежный с навигацией. Держать его небольшим и осознанным.
• API boundaries = Zod (или аналог) для валидации/парсинга ответов BFF и критичных payload форм в runtime — не «только TypeScript».
• MVVM-style = тонкие screen-компоненты; view-models как custom hooks (например, `useWalletDashboard`), которые объединяют queries, mutations и локальный стейт; избегать «экранов на 500 строк».
• High-stakes flows (KYC, движение денег, шаги карты с множеством ветвлений/таймаутов) = использовать явную модель состояний — например, state machine или строгие unidirectional шаги — чтобы переходы были тестируемыми и аудируемыми. Конкретное имя библиотеки заранее не требуем; требуем ясность там, где баги дорого стоят.
• Evolving complexity = начинать feature-first; при необходимости позже добавить более чёткие доменные границы (ports/adapters, общие pure TS-модули) для правил, которые переживают один экран — без big-bang rewrite.

Обязанности

• Реализовывать pixel-accurate, доступные UI по Figma (дизайн-система D-001+), в соответствии с согласованными спеками для состояний states, errors, loading и empty.
• Собирать и поддерживать онбординг (ONB-001…006+), auth (телефон/email, OTP, PIN, биометрия), создание кошелька через Privy, dashboard с реальными балансами (testnet/mainnet по окружению) и последующие флоу карты / KYC / top-up по мере выхода фаз.
• Интегрироваться с REST API от BFF; считать бэкенд источником истины; никогда не вшивать секреты (API keys, HMAC secrets) в приложение — использовать паттерны только через BFF.
• Реализовывать WebView-мосты для KYC и флоу карты/эмитента с ясным контрактом: start / success / cancel / error.
• Обрабатывать secure storage (Keychain / EncryptedSharedPreferences) для артефактов сессии по продуктовой политике; без PII и PAN в логах.
• Реализовывать deep links и роутинг push-уведомлений (например, открытие экрана транзакции или KYC).
• Работать с флоу, связанными с Apple Pay / Google Pay, в том виде, как их отдаёт эмитент (например, push provisioning), используя нативные возможности — EAS / config plugins; заранее согласовывать ограничения iOS/Android.
• Сотрудничать с дизайном по ограничениям React Native (вложенный скролл, модалки, жесты) — ловить проблемы до заморозки handoff.
• Писать поддерживаемый feature-код: custom hooks (ViewModel-style), тонкие экраны, тестируемые reducers/validators.
• Участвовать в гигиене сборок TestFlight / Internal testing, версионировании и release notes вместе с QA.

Требования

• Сильный продакшен-опыт с React Native (2+ года или эквивалентная глубина).
• Уверенный TypeScript — типы на границах, не только в props; комфорт с режимом `strict`.
• Подтверждённое использование современного state management (TanStack Query или явно эквивалентные паттерны + лёгкий глобальный стор).
• Опыт поставки iOS и Android из одной RN-кодовой базы; отладка в Xcode и Android Studio.
• Expo (managed workflow с prebuild / EAS) — понимание, почему Expo Go недостаточно для кастомных нативных модулей.
• Опыт интеграции REST; Zod или аналогичная runtime-валидация — плюс.
• Git, code review, CI-friendly подход (lint, typecheck, небольшие PR).
• Английский, достаточный для чтения документации API и SDK (Privy, эмитенты, KYC-вендоры).
• Осведомлённость о безопасности для финтеха: без секретов в репозитории, политика SSL pinning при необходимости, безопасное логирование.

Будет плюсом

• Опыт Web3 и Smart Wallet: интеграция с фреймворками Account Abstraction, такими как Kernel Wallet by ZeroDev (ZeroDev SDK) или Safe (Safe {Core} SDK).
• Опыт работы с blockchain RPC providers (например, Alchemy, Infura) для чтения on-chain состояния или исполнения транзакций.
• Предыдущий бэкграунд в мобильных приложениях финтеха, платежей или банкинга.
• Флоу KYC / WebView или в стиле 3DS.
• Maestro / Detox или snapshot-тестирование.
• Reanimated / UI с тяжёлыми жестами.
• Accessibility (screen readers, dynamic type, контраст).

Ожидания по финтеху и комплаенсу

• Вы уважаете PCI-границы: PAN/CVV карты не обрабатываются в сыром JS; используйте hosted или WebView/iframe флоу так, как требуют архитекторы и эмитенты.
• Вы не логируете PII или сырые payload провайдеров; используете только enums / безопасную диагностику по гайдлайнам product security.
• Вам комфортен строгий UX для денег: шаги подтверждения, error copy без утечки внутренностей, и поведение retry, согласованное с BFF.
• Вы координируетесь с бэкендом по ключам идемпотентности и кодам ошибок для критичных мутаций.

Чего мы ожидаем

• Тщательная, продуманная реализация: корректная обработка состояний loading / error / empty, разумные решения, когда экран описан не полностью, и раннее обозначение integration edge cases.
• Проактивная коммуникация, когда экранный флоу подразумевает зависимость от бэкенда или нативное ограничение платформы.
• Дисциплина по производительности (виртуализация списков, image assets, контроль re-render) и стабильности (чистый Sentry, crash-free sessions).
• Если сборку фичи блокирует недостающая деталь (API-контракт, нативные лимиты, тайминги), вы поднимаете это рано с PM/дизайном — без перекладывания на вас владения всем UX-артефактом.