Собеседование на Frontend-разработчика: вопросы, ответы и разбор

Сильный ответ

Замыкание возникает, когда внутренняя функция сохраняет доступ к переменным внешней функции даже после того, как та завершила выполнение. Я использовал это, когда делал debounce для поля поиска: внешняя функция хранила идентификатор таймера, а внутренняя при каждом вводе сбрасывала его и запускала заново. Ещё замыкания удобны для приватного состояния в модуле, когда счётчик или кэш не должны быть доступны снаружи. Из-за замыканий же бывают и баги: например, обработчик внутри useEffect держит устаревшее значение состояния, если забыть про зависимости.

Сильный ответ

Event loop берёт задачу из очереди только тогда, когда стек вызовов пуст. setTimeout с нулевой задержкой всё равно попадает в очередь макрозадач и ждёт, пока отработает весь синхронный код, а затем все микрозадачи, то есть колбэки промисов и queueMicrotask. Поэтому колбэк выполнится после текущего синхронного блока, а не мгновенно, и промис, созданный позже таймера, отработает раньше него. Я разбирался с этим, когда состояние в компоненте обновлялось не в том порядке, в каком приходили ответы, и порядок пришлось выстраивать явно, а не через таймер.

Сильный ответ

Виртуальный DOM это лёгкое представление дерева элементов в виде обычных JS-объектов. При изменении состояния React строит новое дерево, сравнивает его с предыдущим и применяет к реальному DOM только отличия, потому что операции с настоящим DOM дороже. Ключи нужны, чтобы React сопоставил элементы старого и нового списка по идентичности, а не по позиции. Если взять индекс массива и вставить элемент в начало, React решит, что изменились все элементы: переиспользует чужие DOM-узлы, и введённый текст в инпутах или состояние чекбоксов уедет к соседним строкам. Поэтому ключом беру стабильный идентификатор из данных.

Сильный ответ

Сначала записываю профиль во вкладке Profiler в React Developer Tools и смотрю, что перерисовывается на каждое нажатие клавиши и почему. Обычно причина в том, что состояние поля лежит слишком высоко и тянет за собой всё дерево, или в том, что на каждый ввод идёт тяжёлый расчёт либо запрос. Опускаю состояние поля вниз, к самому инпуту, тяжёлые соседние компоненты изолирую и мемоизирую вместе со стабилизацией пропсов, на запрос ставлю debounce и отменяю предыдущий через AbortController. Если тормозит длинный список подсказок, добавляю виртуализацию. После правок повторяю замер в профайлере и проверяю на слабом устройстве с троттлингом CPU, а не полагаюсь на ощущения.

Сильный ответ

Flexbox хорош для одномерной раскладки, когда элементы идут в строку или колонку и нужно распределить между ними свободное место: панель навигации, кнопки в футере карточки, ряд тегов с переносом. Grid удобен, когда важно контролировать и строки, и столбцы: каркас страницы с шапкой, сайдбаром, контентом и подвалом через grid-template-areas или адаптивная плитка карточек на repeat с auto-fill и minmax, которая сама меняет количество колонок без медиазапросов. На практике комбинирую: grid для общей структуры, flex внутри блоков. Отдельно слежу за тем, чтобы у flex-элементов был min-width, иначе длинный текст растягивает колонку и ломает раскладку.

Сильный ответ

У запроса всегда есть три состояния в интерфейсе: загрузка, успех, ошибка, и все три я предусматриваю сразу. В коде обрабатываю reject промиса, отдельно проверяю статус ответа, потому что fetch не считает 4xx и 5xx ошибкой. Различаю случаи: сеть недоступна, невалидные данные формы, истёк токен, упал сервер. Пользователю показываю понятный текст и действие, например кнопку «Повторить», а не текст исключения, ошибку отправляю в мониторинг вместе с контекстом запроса. Для идемпотентных запросов делаю повтор с ограничением числа попыток и увеличением паузы, а гонки при быстрых переключениях фильтров закрываю отменой предыдущего запроса через AbortController, чтобы устаревший ответ не перезаписал состояние.

Сильный ответ

Сначала спрашиваю, кому нужны эти данные. Состояние одного поля, открытая вкладка, ховер живут в самом компоненте через useState. Если данные нужны нескольким соседям, поднимаю состояние к ближайшему общему родителю. Контекст беру для редко меняющихся вещей: тема, локаль, текущий пользователь, потому что частые обновления в контексте перерисовывают всех потребителей. Серверные данные держу отдельно, в React Query или похожем инструменте, где уже есть кэш, повторные запросы и инвалидация, чтобы не хранить копию ответа руками. Глобальный стор оставляю для сквозного клиентского состояния, например корзины или незавершённой формы через несколько шагов. Ещё часть состояния, например фильтры и страницу списка, храню в URL, чтобы ссылку можно было переслать и не потерять контекст.

Сильный ответ

Начинаю с семантики: кнопка это button, ссылка это a с href, поля формы связаны с label, заголовки идут по уровням. Это бесплатно даёт фокус, обработку Enter и Space и правильное объявление в скринридере, тогда как div с onClick приходится чинить руками через tabindex и обработчики клавиш. В модальном окне удерживаю фокус внутри, закрываю по Escape и возвращаю фокус на элемент, который окно открыл. Динамические сообщения об ошибке и успехе помечаю aria-live, чтобы их зачитали. Слежу за видимым состоянием фокуса и контрастом текста. Проверяю так: прохожу сценарий одной клавиатурой, прогоняю страницу через axe DevTools и слушаю ключевые экраны скринридером.

Сильный ответ

Сначала измеряю: снимаю Lighthouse и смотрю в Performance, что происходит до первой отрисовки, какие метрики проседают, LCP или время до интерактивности. Дальше разбираю бандл анализатором и смотрю, что в него попало: обычно находится тяжёлая библиотека дат или графиков, подключённая целиком, или иконки, импортированные пакетом. Заменяю или импортирую точечно, разделяю код по маршрутам через динамический import и подгружаю редкие экраны лениво. Проверяю шрифты: подключаю с font-display swap и предзагружаю основной, у изображений первого экрана ставлю нужные размеры и современный формат, остальные загружаю лениво. Смотрю на количество запросов до отрисовки, лишние переношу за первый экран. После каждой правки повторяю замер и фиксирую результат, чтобы понимать, что именно помогло.

Сильный ответ

На прошлом проекте страница со временем начинала подтормаживать: у пользователей, которые не перезагружали вкладку весь день, интерфейс отвечал с задержкой. Симптом был плавающий, поэтому я воспроизвёл его сценарием с многократным переходом между разделами, снял несколько снапшотов памяти во вкладке Memory и сравнил их. Оказалось, что обработчики события resize и подписка на сокет не снимались при размонтировании компонента, ссылки на старые узлы оставались живыми. Добавил cleanup в useEffect, отписку в общем хуке, которым пользовались все экраны, и правило линтера на подписки без отписки. После этого повторил замер: рост памяти прекратился, задержки ушли.

Сильный ответ

Главный признак не длина файла, а количество ответственностей. Если компонент одновременно ходит за данными, хранит состояние формы, валидирует её и рисует сложную таблицу, я разделяю: запрос и логику выношу в хук, таблицу и её строку делаю отдельными компонентами, которые получают готовые данные. Проверяю себя вопросом, можно ли описать назначение компонента одним предложением без слова «и». Отдельно выделяю то, что уже понадобилось второй раз в интерфейсе, но не делаю «универсальный» компонент заранее: обычно из-за этого появляется десяток флагов в пропсах. Если после разбиения приходится прокидывать пропсы через три уровня, значит границы выбраны неудачно и лучше передать содержимое через children.

Сильный ответ

Оператор == приводит операнды к общему типу перед сравнением, из-за чего появляются неочевидные результаты: пустая строка равна нулю, строка с числом равна числу. Оператор === сравнивает и значение, и тип, поэтому результат предсказуем и код проще читать. Я использую === по умолчанию и привожу типы явно, например через Number или String, когда данные приходят из инпута или из параметров URL строкой. Единственное место, где сознательно пишу нестрогое сравнение, это проверка на null и undefined одновременно через == null, и такую строчку обычно поясняю комментарием или заменяю на явную проверку.

Сильный ответ

Дизайнер предложил анимацию списка, при которой на каждый кадр пересчитывался layout, и на бюджетных телефонах прокрутка заметно дёргалась. Я не стал спорить в чате: записал профиль во вкладке Performance, показал на созвоне падение частоты кадров и объяснил причину простыми словами, что браузер пересобирает раскладку на каждом шаге. Предложил вариант через transform и opacity, визуально близкий к задумке, собрал оба на тестовой странице, и мы проверили их на реальном слабом устройстве. Выбрали второй. С бэкендом похожая история была про формат ошибок: договорились о едином теле ответа с кодом и сообщением и записали это в описание API, чтобы не разбирать каждый эндпоинт отдельно.

Сильный ответ

Юнит-тестами покрываю чистую логику: утилиты, форматирование, расчёты в корзине, кастомные хуки. Компоненты тестирую через React Testing Library от поведения пользователя: нахожу элементы по роли и тексту, ввожу данные, проверяю, что показалось сообщение об ошибке, а не заглядываю во внутреннее состояние. Запросы подменяю на уровне сети через MSW, чтобы проверить ветки успеха, ошибки и пустого ответа. Один-два ключевых сценария, например авторизация и оформление заказа, покрываю end-to-end в Playwright и гоняю в CI на пул-реквестах. Покрытие не считаю целью: в первую очередь пишу тесты на то, что уже ломалось, и на код, который планируется рефакторить.