Коротка відповідь. Підготовка до React interview – це три різні вправи: пояснити, як працює React; написати невеликий компонент із типами й тестами; аргументувати архітектурні рішення. Якщо ти знаєш відповіді на сто теоретичних запитань, але губишся перед порожнім редактором – підготовка ще не закінчена. Нижче – як прокачати всі три навички, з робочим кодом і типовими пастками.

Що насправді перевіряють на React-співбесіді

Формат майже скрізь схожий: теоретичний блок, live coding і, для Middle+, розмова про архітектуру. Але оцінюють не «чи знаєш ти API», а три різні речі:

  1. Модель мислення. Чи розумієш ти, що відбувається між setState і оновленим екраном.
  2. Робочий код під тиском. Чи можеш ти за 30–40 хвилин написати компонент, який працює, з обробкою країв.
  3. Аргументацію. Чи вмієш пояснити, чому саме так, і які були альтернативи.

Готуватися варто до всіх трьох окремо – це і є план цієї статті.

Почни з моделі рендерингу

Мінімум, який треба вміти пояснити впевнено й своїми словами:

  • різниця між props і state, і чому props не можна мутувати;
  • навіщо потрібні keys у списках і що ламається без них;
  • що відбувається після оновлення state: re-render, порівняння, оновлення DOM;
  • чому state в React – це «знімок» на момент рендера, а не жива змінна.

Не обмежуйся визначеннями. Візьми список задач, додай сортування й фільтрацію, і спробуй передбачити, коли компонент перерендериться. Потім перевір свої очікування в React DevTools у вкладці Profiler. Розрив між «я думав» і «насправді» – це і є твій список для навчання. Деталі моделі найкраще пояснені в офіційній документації react.dev – розділи «State as a Snapshot» і «Queueing a Series of State Updates».

Розберися зі state updates – тут валиться більшість

Якщо новий стан залежить від попереднього, використовуй функціональне оновлення. Це не стилістична примха: воно явно виражає залежність і коректно працює з послідовними оновленнями. Класичний приклад – додати до списку нові елементи без повторів за id:

import { useState } from 'react';

type Item = { id: string; title: string };

function useItems() {
  const [items, setItems] = useState<Item[]>([]);

  function addItems(newItems: Item[]) {
    setItems((previous) => {
      const seen = new Set(previous.map((item) => item.id));
      return [
        ...previous,
        ...newItems.filter((item) => !seen.has(item.id)),
      ];
    });
  }

  return { items, addItems };
}

Цей код треба вміти не просто написати, а пояснити під запитаннями інтерв'юера:

  • Звідки береться previous? React передає актуальний стан на момент застосування оновлення – навіть якщо в черзі кілька оновлень підряд.
  • Чому немає мутації? Ми створюємо новий масив; мутація старого зламала б порівняння і React міг би не перерендерити.
  • Навіщо Set? Перевірка has за O(1) замість Array.includes за O(n) на кожен елемент.
  • Що станеться, якщо newItems сам містить дублікати? Ось це – важливий edge case: код прибирає збіги з попереднім станом, але не дублікати всередині самого newItems. Для production потрібен або інший алгоритм, або явно зафіксований контракт вхідних даних.

Останнє запитання – улюблене в сильних інтерв'юерів: воно показує, чи розумієш ти власний код, чи просто відтворюєш патерн.

І для балансу: функціональне оновлення потрібне, коли наступне значення залежить від попереднього. Якщо ти просто кладеш значення з інпута – setValue(event.target.value) без callback простіший і правильний.

Потренуйся на маленьких задачах

Типовий пул live coding задач невеликий:

  • список із пошуком і фільтрацією;
  • пагінація або «завантажити ще» з даними з API;
  • форма з валідацією;
  • стан завантаження, помилки і порожній стан для одного запиту.

Для кожної задачі одна й та сама дисципліна: сформулюй вимоги вголос → визнач типи TypeScript → напиши робочий happy path → додай edge cases → скажи, як би ти це тестував. Оптимізацію (useMemo, React.memo) додавай лише тоді, коли можеш назвати причину. «Про всяк випадок» на співбесіді звучить гірше, ніж чесне «тут оптимізація поки не потрібна».

Глибина залежить від рівня

Орієнтовна навчальна рамка (не стандарт найму – вимоги відрізняються між компаніями):

Рівень Що очікують
Junior Впевнена робота з компонентами, props/state, списками й формами; чистий JavaScript без «магії»
Middle Зв'язок стану, ефектів і асинхронності; тести; розуміння перформансу без карго-культу
Senior Аргументовані компроміси архітектури, performance, accessibility; межі відповідальності компонентів; командні рішення

Чесно визнач свій поточний рядок таблиці й готуйся до нього, а не до всіх одразу.

Міні-план на тиждень

  • День 1 – JavaScript і state: замикання, асинхронність, снапшот-модель стану.
  • День 2 – effects: залежності, cleanup, типові витоки.
  • День 3 – TypeScript: типізація props, подій і даних з API.
  • День 4 – live coding: дві задачі з таймером на 40 хвилин.
  • День 5 – тести: що і як перевіряти в компонентах.
  • День 6 – невеликий design exercise: структура сторінки з фільтрами й запитами.
  • День 7 – пробна співбесіда з розбором слабких місць.

Підлаштуй план під вимоги конкретної вакансії, а не виконуй механічно. Якщо співбесіда ширша за React – є окремий матеріал про системну підготовку за 30 днів. А якщо ти ще на етапі «чи моє це взагалі» – почни з маршруту входу в IT.

Найчастіші помилки на React-співбесідах

  1. Відповіді-визначення без прикладів: «useEffect – це хук для сайд-ефектів» і тиша.
  2. Мутація стану: items.push(...) перед setItems(items).
  3. useMemo на все підряд без розуміння, що саме дорого.
  4. Ігнорування станів завантаження й помилок у live coding: happy path є, решти немає.
  5. Мовчазне кодування: інтерв'юер не бачить хід думок і не може допомогти навідним запитанням.

Кожна з цих помилок лікується не читанням, а практикою з фідбеком: напиши, отримай розбір, перепиши.