Співбесіда на Frontend: тренування з ШІ

Чим семантичні теги кращі за div і чому це важливо?

Що має бути в сильній відповіді:Теги на кшталт header, nav, main, article, button і label передають сенс: скрінрідер оголошує їх як landmarks і елементи керування, браузер дає вбудовану клавіатурну підтримку, а пошуковики краще розуміють структуру. Сильна відповідь згадує, що div з onClick не отримує фокус і не реагує на Enter без додаткового коду, тому для дій потрібен справжній button.

Як рахується специфічність CSS-селекторів?

Що має бути в сильній відповіді:Специфічність порівнюється як трійка: ID, потім класи, атрибути й псевдокласи, потім теги й псевдоелементи; інлайн-стилі сильніші за будь-який селектор, а !important перекриває звичайні правила. При рівній специфічності перемагає правило, яке стоїть пізніше. Добре додати, що :where() має нульову специфічність, а @layer дозволяє керувати пріоритетом без гонки специфічності.

Чим Flexbox відрізняється від Grid і коли що обрати?

Що має бути в сильній відповіді:Flexbox — одновимірна верстка: елементи вирівнюються в рядок або колонку, і розміри залежать від контенту. Grid — двовимірна: ви задаєте рядки й колонки, і елементи розставляються по сітці. Типовий вибір: Flexbox для навбару, кнопок і рядків карток, Grid для каркасу сторінки й складних сіток, причому їх часто поєднують.

Чим відрізняються let, const і var?

Що має бути в сильній відповіді:var має функціональну область видимості і піднімається зі значенням undefined, а let і const — блокові й до оголошення перебувають у temporal dead zone, тож звернення кидає ReferenceError. const забороняє перепризначення змінної, але об'єкт чи масив у ній можна змінювати. У сучасному коді var практично не використовують.

Що таке делегування подій?

Що має бути в сильній відповіді:Події спливають від цільового елемента до батьків, тому один обробник на контейнері може обробляти кліки по всіх дочірніх елементах, перевіряючи event.target, наприклад через closest(). Це економить обробники і працює для елементів, доданих пізніше. Варто згадати stopPropagation і те, що деякі події, як focus, не спливають (замість них є focusin).

Поясніть event loop: у якому порядку виконаються setTimeout, Promise.then і синхронний код?

Що має бути в сильній відповіді:Спочатку виконується весь синхронний код у call stack, потім браузер вичищає чергу мікрозадач (колбеки промісів, queueMicrotask), і лише після цього бере наступну макрозадачу на кшталт setTimeout. Між макрозадачами браузер може відрендерити кадр. Тому Promise.then завжди спрацює раніше за setTimeout(fn, 0), а нескінченний ланцюжок мікрозадач блокує рендеринг.

Що таке Core Web Vitals і як покращити INP?

Що має бути в сильній відповіді:Core Web Vitals — це LCP (швидкість появи головного контенту, добре до 2,5 с), INP (затримка реакції на взаємодію, добре до 200 мс, з 2024 року замінив FID) і CLS (стабільність верстки, добре до 0,1). INP покращують, розбиваючи довгі задачі на main thread, відкладаючи неважливу роботу, зменшуючи JS-бандл і кількість зайвих ре-рендерів. Сильна відповідь згадує вимірювання на реальних користувачах, а не лише в Lighthouse.

Що таке CORS і навіщо потрібен preflight-запит?

Що має бути в сильній відповіді:Браузер за same-origin policy не дає скрипту читати відповідь з іншого origin, якщо сервер явно не дозволив це заголовками Access-Control-Allow-*. Для «непростих» запитів, наприклад з методом PUT, JSON-тілом або кастомними заголовками, браузер спершу шле OPTIONS-preflight. Важливо сказати, що CORS — захист користувача в браузері, а не сервера: curl його ігнорує.

Як захиститися від XSS у фронтенд-застосунку?

Що має бути в сильній відповіді:Не вставляти недовірені дані як HTML: використовувати textContent і автоекранування фреймворків, а dangerouslySetInnerHTML чи v-html — лише з санітизацією, наприклад через DOMPurify. Додатковий рівень захисту — Content Security Policy, яка забороняє інлайн-скрипти й чужі джерела, та HttpOnly-cookie для сесії, щоб скрипт не міг її вкрасти.

Як ви вирішуєте, де зберігати стан у застосунку?

Що має бути в сильній відповіді:Спершу тримаю стан якнайближче до місця використання і піднімаю його лише коли він потрібен кільком компонентам. Серверні дані відокремлюю і віддаю бібліотеці на кшталт TanStack Query, яка кешує, дедуплікує і рефетчить; стан фільтрів і пагінації часто краще тримати в URL. Глобальний store (Redux Toolkit, Zustand, Pinia) — лише для справді спільного клієнтського стану.

Як би ви діагностували повільну сторінку в продакшні?

Що має бути в сильній відповіді:Почати з польових даних — RUM або CrUX, — щоб зрозуміти, яка метрика страждає, на яких сторінках і пристроях. Далі відтворити в DevTools Performance з тротлінгом: шукати довгі задачі, блокуючі ресурси, важкий LCP-елемент, layout shifts. Виправлення пріоритезувати за впливом і закріпити бюджетами продуктивності в CI, щоб регресії не поверталися.

CSR, SSR, SSG чи стрімінг: як обрати стратегію рендерингу?

Що має бути в сильній відповіді:SSG підходить для контенту, що рідко змінюється, і дає найшвидший TTFB з CDN; SSR — для персоналізованих чи часто оновлюваних сторінок, де важливі SEO і швидкий перший показ; CSR — для застосунків за логіном. Стрімінг SSR і Server Components дозволяють віддавати частини сторінки раніше й менше JS на клієнт. Сильна відповідь говорить про ціну: навантаження на сервер, вартість гідратації і складність кешування.

Коли мікрофронтенди виправдані, а коли ні?

Що має бути в сильній відповіді:Вони виправдані, коли кілька незалежних команд мають релізити свої частини продукту окремо і організаційні вигоди переважають технічну ціну. Ціна — дублювання залежностей, більший бандл, складність спільного стану, дизайн-системи і наскрізного тестування. Для однієї-двох команд зазвичай достатньо модульного моноліту в монорепозиторії з чіткими межами між модулями.

Як ви побудуєте стратегію тестування фронтенду?

Що має бути в сильній відповіді:Основа — швидкі unit- та інтеграційні тести компонентів через Testing Library, які перевіряють поведінку очима користувача, з моками мережі на рівні запитів, наприклад MSW. Поверх — невелика кількість e2e на Playwright для критичних сценаріїв: логін, оплата, ключові форми. Додати візуальні й a11y-перевірки, стежити за flaky-тестами і запускати все в CI на кожен pull request.

Як порівняти моделі реактивності React, Vue і Angular?

Що має бути в сильній відповіді:React перезапускає функцію компонента при зміні стану і порівнює дерево, тому мемоізація (вручну або через React Compiler) впливає на продуктивність. Vue відстежує залежності через проксі й оновлює лише те, що читає змінені дані. Angular перейшов від Zone.js до signals з точковими оновленнями і підтримує zoneless-режим. Сильна відповідь пояснює, як ця різниця впливає на продуктивність і ментальну модель команди.