# React співбесіда: як підготуватися – теорія, live coding і архітектура

> Підготовка до React-співбесіди – це три різні вправи: пояснити, як працює React, написати компонент із типами й тестами та аргументувати архітектурні рішення. Розбираємо всі три з прикладами коду.

- Автор: Юра Скиба (https://cookiesoftware.io)
- Опубліковано: 2026-09-24
- Категорія: React і Frontend
- Canonical: https://cookiesoftware.io/blog/react-interview-guide

---

**Коротка відповідь.** Підготовка до 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](https://react.dev/learn) – розділи «State as a Snapshot» і «Queueing a Series of State Updates».

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

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

```tsx
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 днів](/blog/pidhotovka-do-tekhnichnoi-spivbesidy). А якщо ти ще на етапі «чи моє це взагалі» – почни з [маршруту входу в IT](/blog/yak-uviity-v-it).

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

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

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