Типичные ошибки на React-интервью: где теряют баллы и как отвечать сильнее

Введение

Ошибка на React-собеседовании редко выглядит как прямой провал. Гораздо чаще кандидат отвечает «почти правильно»: знает термины, помнит API, даже пишет рабочий код, но все равно теряет баллы. Причина обычно одна и та же. Ответ не показывает инженерное мышление. Он звучит как пересказ документации, а не как решение задачи с ограничениями.

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

Почему хорошие разработчики все равно отвечают слабо

На интервью время сжато. Вопрос звучит широко, а отвечать нужно точно. В этот момент кандидат часто скатывается в безопасный шаблон:

1. дает определение;
2. называет знакомый инструмент;
3. не проговаривает ограничения;
4. не показывает, как проверил бы гипотезу.

Такой ответ не обязательно технически неверный. Но интервьюер слышит другое: человек знает названия, однако не демонстрирует, как принимает решение в рабочей системе. Именно поэтому слабый ответ и сильный ответ могут содержать один и тот же термин, но давать совершенно разный эффект.

Ошибка 1: отвечать API, а не механизмом

Это самый частый сбой. Вопрос «почему компонент ререндерится?» получает ответ «потому что меняется state». Формально правда. Практической пользы почти нет.

Слабый ответ:

Компонент ререндерится, когда меняется state.

Что слышит интервьюер:

• кандидат знает базовый триггер;
• кандидат не различает источники обновления;
• кандидат не умеет диагностировать проблему.

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

Я сначала проверю источник обновления: локальный state, props, context или ререндер родителя. Потом подтвержу это через React Profiler. Если проблема в слишком широкой границе обновления, вынесу состояние ближе к месту использования или отделю горячий участок дерева.

Разница в том, что сильный ответ сразу показывает ход мысли: триггер, способ проверки, направление решения. Для этой базы полезны разбор reconciliation и материал о том, когда компонент действительно перерисовывается.

Архитектурный разбор: где в ответе ломается логика, когда речь заходит о реальном экране

Типовой кейс на интервью: каталог товаров, фильтры, сортировка, пагинация, рекомендации. Вопрос звучит просто: «Как организовать состояние, чтобы не получить каскад ререндеров?»

Где отвечает слабо кандидат

Обычно так:

• «Подниму все состояние наверх».
• «Сделаю общий Context».
• «Оберну список в memo».

Проблема в том, что такой ответ перепрыгивает через архитектуру. В нем нет границ ответственности.

Что ожидают услышать

Более зрелый ответ раскладывает экран по слоям:

• URL хранит фильтры и пагинацию, которые должны переживать навигацию и шаринг ссылки.
• Локальная форма фильтра живет внутри FiltersPanel, пока пользователь не нажал «Применить».
• Data-layer отвечает за запросы, отмену и кэширование.
• ProductsList получает уже готовые данные и не знает, откуда они пришли.
• Recommendations не подписывается на каждое изменение фильтра, если это не требуется бизнес-логикой.

Такой ответ показывает, что вы не лечите симптомы точечными memo, а сначала строите корректный поток данных. Если хочется добрать теорию по границам состояния, полезен разбор Context API и когда его использовать.

Где кандидат обычно теряет баллы

На точке отказа. Интервьюер почти всегда мысленно продолжает ваш ответ вопросом: «Что будет при медленном API, быстрой смене фильтров и сетевой ошибке?» Если вы не проговорили отмену устаревших запросов, деградацию и fallback, ответ остается учебным, а не production-ориентированным.

Ошибка 2: превращать useEffect в универсальный инструмент

На React-интервью очень видно, кто действительно понимает useEffect, а кто повторяет паттерны из старых проектов. Самая распространенная ошибка: показать загрузку данных, но не учесть отмену запроса, гонки ответов и устаревшие данные.

import { useEffect, useState } from "react";

type User = { id: string; name: string };

export function UsersBad({ query }: { query: string }) {
  const [users, setUsers] = useState<User[]>([]);

  useEffect(() => {
    fetch(`/api/users?q=${encodeURIComponent(query)}`)
      .then((r) => r.json())
      .then((data) => setUsers(data));
  }, [query]);

  return <UserList items={users} />;
}

Такой пример часто проходит в учебном приложении и так же часто валит кандидата на интервью. Если пользователь быстро меняет query, медленный старый ответ может перезаписать новый.

Более сильный вариант:

import { useEffect, useState } from "react";

type User = { id: string; name: string };

export function UsersGood({ query }: { query: string }) {
  const [users, setUsers] = useState<User[]>([]);
  const [error, setError] = useState<string | null>(null);

  useEffect(() => {
    const controller = new AbortController();
    setError(null);

    fetch(`/api/users?q=${encodeURIComponent(query)}`, {
      signal: controller.signal,
    })
      .then((r) => {
        if (!r.ok) throw new Error("Request failed");
        return r.json();
      })
      .then((data: User[]) => setUsers(data))
      .catch((e: Error) => {
        if (e.name !== "AbortError") {
          setError("Не удалось загрузить список");
        }
      });

    return () => controller.abort();
  }, [query]);

  if (error) return <p>{error}</p>;
  return <UserList items={users} />;
}

Здесь важно не просто показать код, а озвучить, зачем он нужен:

• отмена запроса защищает от устаревшего ответа;
• ошибка не растворяется в консоли, а отображается в UI;
• поведение компонента остается предсказуемым при быстром вводе.

Если эта тема часто проседает, разберите сложные вопросы по useEffect отдельно.

Ошибка 3: рекомендовать глобальный Context по умолчанию

Вопрос «где хранить состояние формы или экрана?» очень часто получает ответ «вынесу в Context». Это звучит аккуратно, но обычно сигнализирует о слабом понимании стоимости решения.

Что в таком ответе не так:

• контекст обновляет всех подписчиков в своей зоне;
• локальное состояние без причины становится глобальным;
• повторное использование компонентов усложняется;
• диагностика ререндеров становится мутнее.

Интервьюер ждет более приземленного ответа:

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

Если нужно сравнить подходы без лозунгов, есть Redux vs Zustand vs Context.

Сравнение слабых и сильных ответов

Ситуация	Слабый ответ	Сильный ответ	Что оценивает интервьюер	Где обычно ошибаются
Почему компонент ререндерится	«Потому что state меняется»	«Проверяю state, props, context, parent и подтверждаю через Profiler»	Диагностика, а не угадывание	не называют источник обновления
Когда нужен useMemo	«Почти всегда для оптимизации»	«Только если есть измеримое узкое место или нужна стабильная ссылка»	Понимание цены оптимизации	мемоизация до замеров
Где хранить состояние формы	«В Context, так удобнее»	«Локально, наверх поднимаю только то, что влияет на URL/API»	Границы ответственности	делают глобальным то, что локально
Почему важен key	«Чтобы React не ругался»	«Key определяет идентичность элемента и влияет на сохранение локального state»	Понимание reconciliation	сводят тему к предупреждению в консоли
Как чинить гонки запросов	«Поставлю loading»	«Отменю старые запросы, учту порядок ответов, добавлю защиту от stale response»	Production-мышление	считают, что индикатора загрузки достаточно
Когда выбирать SSR или CSR	«SSR быстрее»	«Смотрю на SEO, стоимость hydration, серверный бюджет и тип экрана»	Архитектурные компромиссы	делают универсальный вывод

Ошибка 4: считать useMemo универсальным ускорителем

Эта ошибка особенно заметна на middle-интервью. Кандидат слышит слово «производительность» и сразу предлагает useMemo и useCallback.

Слабый пример:

import { useMemo } from "react";

export function Products({ items }: { items: Product[] }) {
  const sorted = useMemo(() => items.sort(sortByPrice), [items]);

  return <List items={sorted} />;
}

Здесь две проблемы:

• sort() мутирует исходный массив;
• сама мемоизация может быть бесполезной, если узкое место вообще в другом.

Более аккуратный вариант:

import { useMemo } from "react";

export function Products({ items, sortOrder }: Props) {
  const sorted = useMemo(() => {
    const copy = [...items];
    copy.sort((a, b) => {
      return sortOrder === "asc" ? a.price - b.price : b.price - a.price;
    });
    return copy;
  }, [items, sortOrder]);

  return <List items={sorted} />;
}

Но и он не делает ответ сильным автоматически. Сильным его делает пояснение: сортировку стоит мемоизировать только тогда, когда стоимость вычисления или стабильность ссылки действительно важны. Иначе это просто лишняя сложность. Для этой темы уместен отдельный разбор React.memo, useMemo и useCallback.

Ошибка 5: путать корректность и косметику в теме key

Ответ «ключ нужен, чтобы React не ругался» почти всегда режет впечатление. Интервьюер ждет понимания идентичности элементов.

Что важно проговорить:

• key помогает React сопоставлять элементы между рендерами;
• нестабильный key может переносить локальное состояние между строками списка;
• индекс как key ломает корректность при вставке, удалении и сортировке;
• это влияет не только на производительность, но и на поведение интерфейса.

Если нужно освежить тему детально, есть разбор типичных ошибок с key.

Ошибка 6: отвечать про производительность без диагностики

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

Рабочая рамка ответа:

1. назвать симптом: медленный ввод, долгий commit, лаг при скролле, тяжелая hydration;
2. назвать возможный источник: сеть, render phase, commit phase, крупная клиентская сборка, слишком широкий Context;
3. сказать, как проверяете: Profiler, Web Vitals, анализатор сборки, воспроизводимый сценарий;
4. предложить минимально достаточное решение;
5. проговорить цену решения.

Если вы отвечаете сразу «добавлю оптимизацию», интервьюер не видит инженерной дисциплины. Он видит угадывание. Для глубины по этой части полезен разбор оптимизации на middle-интервью.

Ошибка 7: говорить об архитектуре лозунгами

Фразы вроде «SSR всегда лучше», «RSC это новый SSR», «вынесем все на сервер» звучат уверенно, но почти всегда вредят. В 2026 году React-интервью заметно чаще включает server-first темы, и здесь быстро вскрывается поверхностное понимание.

Слабый ответ:

SSR быстрее, поэтому его лучше использовать.

Почему это плохо:

• не названы ограничения среды;
• не учтена стоимость hydration;
• не проговорена цена серверного рендера;
• не видно различия между SSR, CSR и RSC.

Более сильный ответ:

Выбор зависит от типа экрана. Для публичной страницы с SEO я смотрю на SSR или server-first схему. Для закрытой админки после логина CSR может быть дешевле и проще. Если хочу уменьшить клиентский bundle и оставить часть дерева на сервере, думаю в сторону RSC. Дальше уже сравниваю цену hydration, серверную нагрузку и объем интерактивности.

Если эта зона плавает, доберите SSR vs CSR vs RSC и Server Components в React.

Практики, которые делают ответы сильнее

Архитектурные практики

• отделяйте локальное состояние от экранного и глобального;
• не смешивайте запросы, нормализацию данных и JSX в одном компоненте на сотни строк;
• проговаривайте сценарии деградации при медленном API и сетевых ошибках.

Практики кода

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

Практики наблюдаемости

• упоминайте React Profiler и Web Vitals;
• описывайте воспроизводимый сценарий проверки;
• для сложных экранов говорите не только «как починить», но и «как заметить проблему заранее».

Практики rollout и rollback

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

Как отвечать на React-интервью сильнее

Рабочий шаблон ответа:

1. Уточнить контекст экрана и ограничения.
2. Назвать симптом, который видит пользователь или команда.
3. Объяснить механизм React, который к нему приводит.
4. Сказать, как проверите гипотезу.
5. Предложить решение.
6. Проговорить компромиссы.

Пример:

Я бы не начинал с useMemo. Сначала проверю, где узкое место: в сети, ререндерах списка или в слишком высоко поднятом состоянии. Если Profiler показывает дорогие повторные commit, локализую состояние фильтра, стабилизирую горячую границу дерева и только потом подумаю о мемоизации. Если это публичный экран, дополнительно сравню клиентскую и server-first схему по цене hydration и объему JavaScript.

В таком ответе интервьюер слышит не набор терминов, а структуру принятия решения.

FAQ

Какая ошибка чаще всего проваливает ответ на React-интервью?

Самая частая ошибка: отвечать терминами без причинно-следственной связи. Интервьюеру нужен не список API, а объяснение, почему проблема возникла, как ее проверить и какое решение уместно в этом контексте.

Нужно ли всегда предлагать useMemo и useCallback на собеседовании?

Нет. Без диагностики это выглядит как шаблон. Сначала нужно показать источник проблемы и способ проверки. Только после этого мемоизация звучит как инженерное решение, а не как рефлекс.

Почему ошибка с key так важна на React-интервью?

Потому что это вопрос корректности, а не косметики. Неправильный key ломает идентичность элементов, переносит локальное состояние между строками и делает поведение списка непредсказуемым.

Что интервьюер хочет услышать в ответе про ререндеры?

Источник обновления, способ проверки и границу решения. Ответ уровня «меняется state» слишком короткий: он не показывает, умеете ли вы диагностировать реальную проблему.

Стоит ли junior учить архитектурные темы для React-интервью?

Да. Junior+ уже полезно понимать, где хранить состояние, почему опасно делать все глобальным и как не смешивать запросы, данные и UI в одном компоненте.

Итоги

Типичные ошибки на React-интервью связаны не с тем, что кандидат «забыл API». Чаще проблема в другом: ответ не показывает ход мысли. Он не связывает симптом, механизм, проверку и решение.

Сильный ответ на React-интервью почти всегда устроен одинаково: сначала контекст, затем диагностика, потом решение и только после этого компромиссы. Если вы привыкнете отвечать именно так, уровень интервью заметно вырастет даже без радикального расширения теоретической базы.