Що повинен знати 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-співбесід.

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

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

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. Якщо повного списку немає – це нормально; не відкладай подачу заявок до «ідеальної готовності», її не буває.

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

Пройди таблиці вище й чесно постав кожній темі одну з оцінок: «пояснюю впевнено», «плаваю», «не знаю».
Для кожного «плаваю» – одна маленька практична вправа, а не перегляд ще одного відео. Тема з таблиці закривається за вечір-два.
«Не знаю» з колонки must – у пріоритет; nice to have ігноруй, поки не закритий must.
Раз на два тижні перевіряй прогрес на реальному коді: додай функціональність у власний проєкт, використовуючи тему, яку вчив. Як оформити ці проєкти – у статті про портфоліо Junior-розробника.

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

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

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

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