Питання на співбесіді Frontend-розробника

var має функціональну область видимості й «піднімається» (hoisting) зі значенням undefined. let і const мають блочну область видимості і до оголошення перебувають у «тимчасовій мертвій зоні».

const забороняє переприсвоєння, але не робить об'єкт незмінним: const user = {} можна доповнити властивостями. На практиці використовують const за замовчуванням і let, коли значення справді змінюється.

Замикання — це функція разом із доступом до змінних області, де її створили, навіть після завершення зовнішньої функції.

function counter() {
  let n = 0;
  return () => ++n;
}
const next = counter();
next(); // 1
next(); // 2

Замикання використовують для приватного стану, фабрик функцій, обробників подій. На них же побудовані хуки React.

Flexbox — для розташування елементів в одному напрямку: рядок кнопок, навігація, вирівнювання по центру. Grid — для двовимірних макетів із рядками й колонками: сітка карток, макет сторінки.

Їх часто поєднують: Grid задає загальну структуру, а всередині комірок елементи вирівнюють через Flexbox.

key допомагає React зрозуміти, який елемент списку змінився, додався чи видалився, і не перемальовувати весь список.

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

JavaScript виконує код в одному потоці. Синхронний код іде першим, потім — усі мікрозадачі (проміси, queueMicrotask), і лише потім — наступна макрозадача (setTimeout, події).

console.log(1);
setTimeout(() => console.log(2));
Promise.resolve().then(() => console.log(3));
console.log(4);
// 1, 4, 3, 2

Розуміння цього пояснює, чому важкий синхронний код «заморожує» інтерфейс.

Спочатку виміряти: React DevTools Profiler покаже, що саме рендериться і скільки часу займає. Далі:

• тримати стан якомога ближче до місця використання;
• не створювати нові об'єкти й функції в пропсах без потреби;
• memo, useMemo, useCallback — там, де вимірювання показали проблему;
• для великих списків — віртуалізація.

У React 19 з'явився React Compiler, який автоматично мемоїзує компоненти, тож ручні useMemo поступово стають менш потрібними.

Дженерики дають змогу писати типобезпечний код, що працює з різними типами без втрати інформації про тип.

function first<T>(items: T[]): T | undefined {
  return items[0];
}
const n = first([1, 2]);   // number | undefined
const s = first(['a']);    // string | undefined

Типові приклади: відповіді API (ApiResponse<User>), хуки на кшталт useFetch<T>, утиліти. Також варто знати Partial, Pick, Omit, Record.

Основи, які перевіряють на співбесіді:

• семантичні теги: button для дій, a для переходів, правильні заголовки;
• підписи для полів форм (label) і alt для зображень;
• робота з клавіатури та видимий фокус;
• достатній контраст тексту;
• ARIA-атрибути лише там, де немає нативного елемента.

Перевіряють через Lighthouse, axe і навігацію з клавіатури або скрінрідера. У ЄС з 2025 року діє European Accessibility Act, тож для багатьох продуктів це вже юридична вимога.

Server Components рендеряться на сервері й не потрапляють у JavaScript-бандл клієнта. Вони можуть напряму читати дані (БД, API), а інтерактивні частини виносяться в клієнтські компоненти з директивою 'use client'.

Переваги — менший бандл і швидше перше відображення для контентних сторінок. Складнощі — межа сервер/клієнт, кешування, серіалізація пропсів. Добра відповідь — з розумінням, коли SSR/RSC не потрібні: наприклад, для внутрішньої адмінки за логіном звичайний SPA може бути простішим.

Метрики: LCP (швидкість появи основного контенту), INP (реакція на дії користувача, замінив FID) і CLS (стабільність макета).

• LCP: оптимізовані зображення (AVIF/WebP, fetchpriority), SSR, CDN, менше блокуючих ресурсів;
• INP: розбивати довгі задачі, менше JS на старті, переносити важке у Web Worker;
• CLS: задавати розміри зображень і місце під банери, обережно з веб-шрифтами.

Важливо відрізняти лабораторні дані (Lighthouse) від реальних (CrUX, RUM) і показувати результат у цифрах.

Варіанти — монорепозиторій (Nx, Turborepo) зі спільною дизайн-системою або мікрофронтенди (Module Federation), коли команди мають релізитися незалежно.

Мікрофронтенди додають складність: дублювання залежностей, узгодження версій, загальний UX. Тому спершу варто спробувати модульний моноліт із чіткими межами й власниками модулів. Обов'язково — спільні правила: дизайн-система, лінтери, контрактні тести API, бюджет розміру бандла в CI.

AI добре прискорює типовий код: компоненти за макетом, тести, типи з JSON, міграцію між версіями бібліотек. Але часто пропонує застарілі API (класові компоненти, старі версії Next.js), ігнорує доступність і генерує зайві залежності.

Правила в команді: код-рев'ю як для звичайного коду, перевірка доступності й продуктивності, контроль ліцензій і розміру бандла. Сильна відповідь — з конкретним прикладом, де AI заощадив час, і де ви знайшли в його коді помилку.