# Що повинен знати Junior Frontend-розробник: реалістична матриця

> Чесна карта знань Junior Frontend без залякування: що обов’язково (must), що бажано (should), що лише плюс (nice to have) – із перевірочними питаннями й прикладами коду.

- Автор: Юра Скиба (https://cookiesoftware.io)
- Опубліковано: 2026-09-24
- Категорія: Старт в IT
- Canonical: https://cookiesoftware.io/blog/shcho-povynen-znaty-junior-frontend

---

**Коротка відповідь.** Junior Frontend повинен упевнено володіти основою: HTML/CSS з адаптивністю, JavaScript без фреймворка, базовий React, Git і вміння розібратися в чужому коді. Усе інше – TypeScript, тести, збірники, CI – бажані плюси, а не бар'єр входу. Проблема більшості списків «що має знати Junior» у тому, що вони описують Middle. Нижче – реалістична матриця з трьома рівнями пріоритету.

## Як користуватися матрицею

- **Must** – без цього на співбесіді буде важко майже скрізь.
- **Should** – помітно підсилює кандидата; часто саме це відрізняє «покликали» від «не відповіли».
- **Nice** – плюс у резюме, але не привід відкладати подачу заявок.

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

## Must: без чого не обійтись

| Тема | Що конкретно | Перевір себе питанням |
|---|---|---|
| HTML | Семантика, форми, посилання vs кнопки | Чому список навігації – це `nav > ul`, а не купа `div`? |
| CSS | Flexbox, grid, адаптивність, специфічність | Як розташувати картки сіткою 3×N, що на мобільному стає 1×N? |
| JavaScript | Типи, функції, масиви/об'єкти, замикання, this | Що виведе код із `var` у циклі з setTimeout і чому? |
| Асинхронність | Promise, async/await, fetch, обробка помилок | Чим відрізняється `catch` від другого аргумента `then`? |
| DOM | Події, делегування, зміна елементів | Як повісити один обробник на список із 100 елементів? |
| React базово | Компоненти, props, state, списки, форми | Навіщо потрібен key і чому індекс масиву – поганий key? |
| Git | commit, branch, push, pull request | Як відкотити локальні зміни в одному файлі? |

Поміть: тут немає жодного «знати напам'ять 50 методів масивів». Має значення розуміння механіки, а не енциклопедичність – докладніше про це в [розборі питань JavaScript-співбесід](/blog/javascript-interview-guide).

## Should: що помітно підсилює

- **TypeScript на рівні читання й базової типізації** – типи props, інтерфейси для даних з API.
- **Робота з API глибше**: стани loading/error/empty, а не лише happy path. Ось мінімальний еталон, який варто вміти написати без підказок:

```tsx
import { useEffect, useState } from 'react';

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

export function UserList() {
  const [users, setUsers] = useState<User[]>([]);
  const [status, setStatus] = useState<'loading' | 'error' | 'ready'>('loading');

  useEffect(() => {
    let cancelled = false;
    fetch('/api/users')
      .then((response) => {
        if (!response.ok) throw new Error(`HTTP ${response.status}`);
        return response.json();
      })
      .then((data: User[]) => {
        if (!cancelled) {
          setUsers(data);
          setStatus('ready');
        }
      })
      .catch(() => {
        if (!cancelled) setStatus('error');
      });
    return () => {
      cancelled = true;
    };
  }, []);

  if (status === 'loading') return <p>Завантаження…</p>;
  if (status === 'error') return <p>Не вдалося завантажити. Спробуй ще раз.</p>;
  if (users.length === 0) return <p>Поки нікого немає.</p>;

  return (
    <ul>
      {users.map((user) => (
        <li key={user.id}>{user.name}</li>
      ))}
    </ul>
  );
}
```

Якщо можеш пояснити, навіщо тут прапорець `cancelled` і чому перевіряється `response.ok`, – ти вже попереду значної частини кандидатів.

- **Доступність базово**: клавіатурна навігація, alt у зображень, label у полів, контраст.
- **DevTools**: вкладки Network і Console як щоденні інструменти, а не «щось страшне».
- **Розуміння HTTP**: методи, статуси, що таке CORS на побутовому рівні.

## Nice to have: плюси, а не бар'єри

Тести (хоча б розуміння, навіщо), збірники (Vite/Webpack на рівні «що це робить»), базовий CI, досвід із будь-яким UI-кітом, знайомство з Next.js. Якщо повного списку немає – це нормально; не відкладай подачу заявок до «ідеальної готовності», її не буває.

## Як закривати прогалини

1. Пройди таблиці вище й чесно постав кожній темі одну з оцінок: «пояснюю впевнено», «плаваю», «не знаю».
2. Для кожного «плаваю» – одна маленька практична вправа, а не перегляд ще одного відео. Тема з таблиці закривається за вечір-два.
3. «Не знаю» з колонки must – у пріоритет; nice to have ігноруй, поки не закритий must.
4. Раз на два тижні перевіряй прогрес на реальному коді: додай функціональність у власний проєкт, використовуючи тему, яку вчив. Як оформити ці проєкти – у статті про [портфоліо Junior-розробника](/blog/junior-developer-portfolio).

## Типова помилка: вчити вшир замість вглиб

Найчастіший патерн застрягання: людина «проходить» десяту технологію, не вміючи впевнено користуватися першими трьома. Роботодавцю цінніший кандидат, який глибоко розуміє JS + React + Git, ніж той, хто «бачив» іще Docker, GraphQL і три фреймворки. Повний маршрут навчання з правильною послідовністю – у статті [як стати frontend-розробником](/blog/yak-staty-frontend-rozrobnykom).

## Практичне завдання

Скопіюй таблиці must і should у нотатки й оціни кожен рядок. П'ять найслабших тем – це твій навчальний план на найближчі два тижні. Через два тижні повтори оцінку: рух по матриці і є найчесніша метрика прогресу, значно краща за кількість переглянутих курсів.