Вопросы, которые вас ждут на собеседовании по React

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

• Механика hooks: правила hooks, что должно быть в массиве зависимостей useEffect, функции очистки, и баг с устаревшим замыканием, когда effect или callback видит старое значение state.
• Rendering: что вызывает re-render, как reconciliation сравнивает деревья, и почему стабильные keys важны в списках.
• Проектирование state: подъём state вверх, контролируемые и неконтролируемые input, и когда уместнее context, а когда внешний store.
• Производительность: React.memo, useMemo, useCallback, и когда каждый из них — просто шум, а не помощь.

Интервьюеры докапываются до причины за каждым пунктом. Заученная фраза о том, что keys должны быть уникальными, не даёт баллов; объяснение того, что React делает с key при изменении порядка списка, — даёт.

Большинство собеседований по React включают создание небольшого компонента в реальном времени. Повторяющиеся задания стабильны от компании к компании:

• Загрузить список из API, отрендерить его и добавить текстовый фильтр.
• Добавить debounce к полю поиска и отменять устаревшие запросы.
• Собрать форму с валидацией и контролируемыми input.
• Написать счётчик или таймер, который корректно очищает свой effect.
• Вынести повторяющуюся логику в custom hook.

Например, front-end инженер на собеседовании на позицию продукта уровня middle может собрать список с загрузкой данных и фильтрацией, а затем получить дополнительные вопросы про состояния загрузки, состояния ошибки и то, что происходит, если компонент размонтируется посреди запроса. Именно эти расширения решают исход собеседования; базовое задание — лишь минимальное условие.

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

На собеседованиях уровня senior акцент смещается с механики на суждение. Ожидайте вопросов об архитектуре state: что должно жить в state компонента, что — в store, чем состояние сервера отличается от состояния UI, и на каком уровне размещать кеш. Вопросы о производительности rendering становятся конкретнее: как найти источник медленного взаимодействия, что выбрать — мемоизацию или реструктуризацию, и как читать flame graph из профилировщика.

Server-side rendering и hydration появляются, когда команда использует фреймворк поверх React: что такое hydration, почему возникают несовпадения, и что даёт перенос работы на сервер. Вопросы о тестировании сосредоточены на стратегии — что тестировать на уровне компонента, а что end to end — больше, чем на API конкретной библиотеки.

Форматы собеседований и то, как front-end процесс обычно выстраивает эти этапы, описаны в разделе о типах собеседований.

Просмотр туториалов создаёт узнавание, а не способность вспомнить, а собеседование проверяет именно способность вспомнить под наблюдением. Решение — повторения в реальной форме собеседования: собирать стандартные задания с пустого файла, проговаривать вслух во время печати и отвечать на вопросы, которые прерывают вас, не теряя нить рассуждения. Наборы вопросов по смежным стекам, включая основы обычного JavaScript, с которых до сих пор начинаются собеседования по React, собраны в разделе с банками вопросов.

Честное замечание: собеседования по React почти всегда проходят в общем редакторе или с видимым экраном, и всё, что на этом экране, видно интервьюеру. Ассистенту место в подготовке и практике, а не в самом собеседовании с демонстрацией экрана. Для легитимного использования в реальном времени оверлей SubcueAI остаётся локальным на вашем компьютере, и ни один бот не подключается к звонку; настройка тренировочных сессий описана на странице инструкции.