Вопросы на собеседовании: Фронтенд-разработчик

Я отношусь к этому как к решению на основе данных, а не погоне за трендом.

• Сопоставляю реальные боли команды с тем, что фреймворк действительно решает, а не с его маркетингом.
• Строю небольшой прототип на самых рискованных точках интеграции; измеряю размер сборки, производительность в рантайме и удобство для разработчиков.
• Представляю эти данные вместе со стоимостью миграции, временем на обучение и зрелостью экосистемы.
• Если числа не оправдывают смену однозначно, улучшаю текущий стек инкрементально.

Я применил миграцию по паттерну strangler fig, которая шла параллельно обычной доставке.

• Новые фичи писались в целевой архитектуре, а общий адаптерный слой позволял старому и новому коду сосуществовать.
• Оба варианта работали параллельно за feature flag, поэтому QA независимо проверял каждый перенесённый раздел.
• За шесть месяцев все критические пути были перенесены, после чего адаптерный слой удалили.
• Доставка фич не останавливалась, потому что ни один спринт не был заблокирован миграцией.

Я предпочитаю композицию вместо конфигурации и проектирую вокруг реальных потребителей.

• Строю небольшие сфокусированные примитивы, которые пользователи собирают, а не один компонент с тридцатью пропсами.
• Беру первые два-три реальных потребителя как источник проектирования и выделяю общие интерфейсы в типы.
• Оставляю escape-hatches вроде renderProp или slot, чтобы потребители переопределяли поведение без форка.
• Прячу внутреннюю реализацию за стабильным публичным интерфейсом, чтобы рефакторить внутренности без поломки вызывающих сторон.

Я подбираю стратегию рендеринга под контент каждого роута, а не одну на всё приложение.

• SSR подходит для часто меняющегося, персонализированного контента, но добавляет серверные расходы и сложность кеширования.
• SSG выигрывает для в основном стабильного контента, потому что переносит работу на сборку и даёт очень быстрый TTFB.
• CSR хорош для аутентифицированных дашбордов, где SEO не важен, но ухудшает первую загрузку.

Я задаю конкретные числа, принуждаю их в CI и фиксирую обоснование.

• Определяю жёсткие лимиты, например 200 КБ сжатого начального JS-бандла и LCP менее 2,5 секунды на среднем устройстве.
• Встраиваю эти числа в CI, чтобы pull request, превышающий бюджет, не проходил сборку.
• Фиксирую обоснование в общем ADR, чтобы команды понимали, зачем существует лимит.
• Раз в квартал пересматриваю пороги по мере развития продукта.

Event loop выполняет по одной задаче, затем опустошает микрозадачи перед рендерингом, и это определяет, как я планирую работу.

• Длинные синхронные задачи блокируют loop и делают страницу неотзывчивой.
• Разбиваю дорогие вычисления на части через requestIdleCallback или scheduler.postTask.
• Откладываю некритичную работу в микрозадачи через Promise.resolve.
• Избегаю синхронных чтений и записей в DOM в одной задаче, чтобы не вызывать layout thrashing.

Я закладываю доступность с самого начала через ARIA Authoring Practices и тестирование на реальных скринридерах.

• Начинаю с ARIA Authoring Practices, чтобы определить ожидаемую навигацию по клавишам и семантику ролей для каждого паттерна.
• Каждому интерактивному компоненту задаю контракт управления фокусом: куда он попадает при открытии и закрытии.
• Тестирую сначала только с клавиатурой, затем с VoiceOver и NVDA, потому что спецификация ARIA и реальные браузеры расходятся.
• Требования к доступности вношу в story каждого компонента в Storybook как критерии приёмки, а не как отдельный аудит.

Я раскладываю состояние по категориям и держу границы чёткими; библиотека важна меньше, чем эта дисциплина.

• Серверный кеш идёт в React Query или SWR, глобальное UI-состояние в Zustand или минимальный Context, локальное эфемерное в useState.
• Чёткие границы предотвращают синхронизацию серверных данных в глобальный стор с ручным управлением устареванием.
• Производное состояние вычисляю, а не храню, что устраняет целые классы багов синхронизации.

Я строго следую semantic versioning и делаю любой breaking change легко усваиваемым.

• Любое удаление пропа или изменение поведения, это мажорный bump.
• В предыдущем минорном релизе отправляю deprecation-уведомление с кодмодом там, где это возможно.
• Веду CHANGELOG с руководствами по миграции, а не просто дифф.
• Для больших команд провожу office-hours сессию, чтобы потребители задали вопросы до апгрейда.

Я нахожу причину до любого исправления, двигаясь от профайлера вглубь.

• Начинаю в браузерном профайлере, чтобы понять, где узкое место: JavaScript, layout/paint или сеть.
• Если в JavaScript, открываю React DevTools Profiler, чтобы найти, что перерендеривается и почему.
• Типичные виновники: inline-объекты или функции, отсутствие мемоизации дорогих значений, или контекст, рассылающий обновления слишком многим потребителям.
• Исправляю причину, а не обматываю всё в memo как заплатку.

Я использую трёхуровневую систему токенов из единого источника истины.

• Примитивные токены кодируют сырые значения вроде цветов и отступов; семантические токены отображаются на роли вроде background-primary; компонентные ссылаются на семантические.
• Темы меняют только семантический слой, так что тёмная тема переопределяет семантические токены, а примитивы остаются неизменными.
• Токены генерирую из одного источника, обычно Figma Variables или JSON-схемы.
• Распространяю их как CSS custom properties или платформенные константы через автоматизированный шаг сборки.

Я делю по роутам и лениво гружу тяжёлые зависимости, опираясь на анализ бандла.

• Анализирую бандл с webpack-bundle-analyzer, чтобы найти крупные зависимости, не нужные на начальном роуте.
• React.lazy и Suspense разделяют каждый роут в отдельный чанк.
• Тяжёлые сторонние библиотеки вроде библиотеки графиков прячу за dynamic import внутри использующего их компонента.
• Слежу за раздуванием общих чанков: если каждый роут тянет одну большую вендорную библиотеку, пересматриваю ленивую загрузку или замену.

E2E держу тонкими, детерминированными и только для критических флоу.

• Ограничиваю E2E критическими флоу вроде аутентификации и оформления заказа; остальное покрываю более быстрыми юнит- и интеграционными тестами.
• Запускаю каждый тест против детерминированного окружения с засеянными данными, чтобы он не зависел от внешних сервисов.
• Проверяю только наблюдаемые результаты, никогда детали реализации.
• Нестабильные тесты немедленно карантинизирую, потому что известные падения приучают команду игнорировать красные сборки.

Мои главные инструменты, документация с видимыми доказательствами и превращение правильного пути в путь по умолчанию.

• Чтобы продвинуть accessibility-first работу, я провёл двухчасовой воркшоп с реальными демо скринридеров, затем опубликовал краткое руководство в общей вики.
• Сделал соответствие лёгким, добавив ESLint jsx-a11y правила в общий конфиг, так что правильный путь стал путём по умолчанию.
• Отслеживал принятие неформально и отмечал команды, выпускавшие доступные компоненты.
• Это создало социальный импульс без обязательных требований.

Я работаю с каждой метрикой отдельно и отслеживаю их через реальный пользовательский мониторинг, а не только Lighthouse.

• Для LCP предзагружаю главное изображение через link rel=preload, подаю в современном формате вроде AVIF и никогда не гружу лениво.
• Для CLS резервирую явные размеры каждого изображения и embed и избегаю вставки динамического контента над существующим.
• Для INP профилирую длинные задачи во время взаимодействий и разбиваю их или откладываю некритичную работу.
• Отслеживаю все три в реальном пользовательском мониторинге, потому что лабораторные и полевые оценки часто расходятся.

Я приоритизирую долг по масштабу ущерба и стоимости исправления сейчас против позже.

• Долг в горячем пути, блокирующий доставку или несущий риски безопасности и доступности, устраняю в текущем квартале.
• Изолированный, хорошо понятый долг, дорожающий незначительно, документирую в бэклоге с чётким триггером срочности.
• Сопротивляюсь кампаниям по долгу в отрыве от продуктовой работы, потому что они редко завершаются и вызывают болезненное переключение контекста.

Инстинкт на граничные случаи я вырабатываю через повторение, а не одну лекцию.

• Разбираю конкретный PR вместе, прося их вслух описывать своё мышление.
• Пробел обычно не в знаниях, а в привычке спрашивать, что может пойти не так, до написания счастливого пути.
• Даю структурированное упражнение по отладке на основе прошлого баг-репорта, чтобы выработать этот инстинкт.
• В последующих ревью указываю на упущенный граничный случай и прошу тест до мержа.

Cascade layers дают управляемую иерархию специфичности через правило @layer.

• Стили в слое, объявленном позже, побеждают более ранние слои, а стили вне слоёв по умолчанию побеждают любые слоёные.
• Это управляет приоритетом без хаков специфичности через лишние селекторы или !important.
• Использую слои при интеграции стороннего reset или UI-библиотеки, помещая их стили в низкоприоритетный слой.
• Так мои стили компонентов всегда побеждают без посекторальных переопределений.

Micro-frontends решают автономию команд и независимый деплой, а не производительность.

• Рекомендую их только когда несколько команд действительно нуждаются в независимом деплое и координация в монорепо вызывает измеримые проблемы.
• Цена реальна: дублирование бандла, конфликты общих зависимостей, сложность интеграционного тестирования и оверхед оркестрации.
• Для трёх-пяти фронтенд-разработчиков хорошо организованное монорепо с чёткими границами владения даёт ту же автономию без операционной сложности.

Пайплайн идёт поэтапно с гейтами и держится под восемью минутами.

• Этапы: установка и кеш зависимостей, проверка типов, юнит- и интеграционные тесты, сборка, визуальная регрессия через Chromatic или Percy, деплой на preview-URL.
• Каждый этап должен пройти перед следующим.
• Preview-деплои автоматичны на каждый pull request, чтобы рецензенты проверяли UI без локальной проверки кода.
• Main автоматически деплоится в staging; продакшн-продвижение требует ручного подтверждения.