Подготовка к собеседованию frontend с ИИ

Чем семантические теги лучше div и почему это важно?

Что должно быть в сильном ответе:Теги вроде header, nav, main, article, button и label передают смысл: скринридер объявляет их как landmarks и элементы управления, браузер даёт встроенную поддержку клавиатуры, а поисковики лучше понимают структуру. Сильный ответ упоминает, что div с onClick не получает фокус и не реагирует на Enter без дополнительного кода, поэтому для действий нужен настоящий button.

Как считается специфичность CSS-селекторов?

Что должно быть в сильном ответе:Специфичность сравнивается как тройка: ID, затем классы, атрибуты и псевдоклассы, затем теги и псевдоэлементы; инлайн-стили сильнее любого селектора, а !important перекрывает обычные правила. При равной специфичности побеждает правило, которое стоит позже. Хорошо добавить, что у :where() нулевая специфичность, а @layer позволяет управлять приоритетом без гонки специфичности.

Чем Flexbox отличается от Grid и когда что выбрать?

Что должно быть в сильном ответе:Flexbox — одномерная вёрстка: элементы выстраиваются в строку или колонку, и размеры зависят от контента. Grid — двумерная: вы задаёте строки и колонки, и элементы раскладываются по сетке. Типичный выбор: Flexbox для навбара, кнопок и рядов карточек, Grid для каркаса страницы и сложных сеток, причём их часто комбинируют.

Чем отличаются let, const и var?

Что должно быть в сильном ответе:У var функциональная область видимости и всплытие со значением undefined, а let и const блочные и до объявления находятся в temporal dead zone, так что обращение бросает ReferenceError. const запрещает переприсваивание переменной, но объект или массив в ней можно менять. В современном коде var практически не используют.

Что такое делегирование событий?

Что должно быть в сильном ответе:События всплывают от целевого элемента к родителям, поэтому один обработчик на контейнере может обрабатывать клики по всем дочерним элементам, проверяя event.target, например через closest(). Это экономит обработчики и работает для элементов, добавленных позже. Стоит упомянуть stopPropagation и то, что некоторые события, как focus, не всплывают (вместо них есть focusin).

Объясните event loop: в каком порядке выполнятся setTimeout, Promise.then и синхронный код?

Что должно быть в сильном ответе:Сначала выполняется весь синхронный код в call stack, затем браузер опустошает очередь микрозадач (колбэки промисов, queueMicrotask), и только потом берёт следующую макрозадачу вроде setTimeout. Между макрозадачами браузер может отрисовать кадр. Поэтому Promise.then всегда сработает раньше setTimeout(fn, 0), а бесконечная цепочка микрозадач блокирует рендеринг.

Что такое Core Web Vitals и как улучшить INP?

Что должно быть в сильном ответе:Core Web Vitals — это LCP (скорость появления главного контента, хорошо до 2,5 с), INP (задержка реакции на взаимодействие, хорошо до 200 мс, с 2024 года заменил FID) и CLS (стабильность вёрстки, хорошо до 0,1). INP улучшают, разбивая длинные задачи на main thread, откладывая неважную работу, уменьшая JS-бандл и число лишних ре-рендеров. Сильный ответ упоминает измерения на реальных пользователях, а не только в Lighthouse.

Что такое CORS и зачем нужен preflight-запрос?

Что должно быть в сильном ответе:Браузер по same-origin policy не даёт скрипту читать ответ с другого origin, если сервер явно не разрешил это заголовками Access-Control-Allow-*. Для «непростых» запросов, например с методом PUT, JSON-телом или кастомными заголовками, браузер сначала шлёт OPTIONS-preflight. Важно сказать, что CORS защищает пользователя в браузере, а не сервер: curl его игнорирует.

Как защититься от XSS во фронтенд-приложении?

Что должно быть в сильном ответе:Не вставлять недоверенные данные как HTML: использовать textContent и автоэкранирование фреймворков, а dangerouslySetInnerHTML или v-html — только с санитизацией, например через DOMPurify. Дополнительный уровень защиты — Content Security Policy, запрещающая инлайн-скрипты и чужие источники, и HttpOnly-cookie для сессии, чтобы скрипт не мог её украсть.

Как вы решаете, где хранить состояние в приложении?

Что должно быть в сильном ответе:Сначала держу состояние как можно ближе к месту использования и поднимаю его, только когда оно нужно нескольким компонентам. Серверные данные отделяю и отдаю библиотеке вроде TanStack Query, которая кэширует, дедуплицирует и перезапрашивает; состояние фильтров и пагинации часто лучше хранить в URL. Глобальный store (Redux Toolkit, Zustand, Pinia) — только для действительно общего клиентского состояния.

Как бы вы диагностировали медленную страницу в продакшене?

Что должно быть в сильном ответе:Начать с полевых данных — RUM или CrUX, — чтобы понять, какая метрика страдает, на каких страницах и устройствах. Дальше воспроизвести в DevTools Performance с троттлингом: искать длинные задачи, блокирующие ресурсы, тяжёлый LCP-элемент, layout shifts. Исправления приоритизировать по влиянию и закрепить бюджетами производительности в CI, чтобы регрессии не возвращались.

CSR, SSR, SSG или стриминг: как выбрать стратегию рендеринга?

Что должно быть в сильном ответе:SSG подходит для редко меняющегося контента и даёт самый быстрый TTFB с CDN; SSR — для персонализированных или часто обновляемых страниц, где важны SEO и быстрый первый показ; CSR — для приложений за логином. Стриминг SSR и Server Components позволяют отдавать части страницы раньше и меньше JS на клиент. Сильный ответ говорит о цене: нагрузка на сервер, стоимость гидратации и сложность кэширования.

Когда микрофронтенды оправданы, а когда нет?

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

Как вы построите стратегию тестирования фронтенда?

Что должно быть в сильном ответе:Основа — быстрые unit- и интеграционные тесты компонентов через Testing Library, которые проверяют поведение глазами пользователя, с моками сети на уровне запросов, например MSW. Сверху — небольшое число e2e на Playwright для критичных сценариев: логин, оплата, ключевые формы. Добавить визуальные и a11y-проверки, следить за flaky-тестами и запускать всё в CI на каждый pull request.

Как сравнить модели реактивности React, Vue и Angular?

Что должно быть в сильном ответе:React перезапускает функцию компонента при изменении состояния и сравнивает дерево, поэтому мемоизация (вручную или через React Compiler) влияет на производительность. Vue отслеживает зависимости через прокси и обновляет только то, что читает изменённые данные. Angular перешёл от Zone.js к signals с точечными обновлениями и поддерживает zoneless-режим. Сильный ответ объясняет, как эта разница влияет на производительность и ментальную модель команды.