Співбесіда з Node.js: тренування голосом
Мок-співбесіда з Node.js для бекенд- і фулстек-розробників, які готуються на позицію junior, middle чи senior. ШІ-інтерв'юер питає про event loop, стріми, обробку async-помилок, масштабування, продуктивність і безпеку, а ви відповідаєте вголос, як на реальному дзвінку. Оберіть рівень або завантажте резюме чи опис вакансії й отримайте звіт з оцінками за технічною точністю, повнотою та зрозумілістю.
Про що питають на співбесіді з Node.js
Event loop і libuv
Фази event loop (timers, poll, check, close), де виконуються process.nextTick і мікротаски промісів, і яку роботу libuv віддає в пул потоків (fs, dns.lookup, crypto, zlib).
Стріми та backpressure
Readable, Writable, Duplex і Transform, highWaterMark, що робити, коли write() повертає false, і чому stream.pipeline кращий за ручні ланцюжки .pipe() для обробки помилок і очищення ресурсів.
Асинхронність і обробка помилок
Колбеки, проміси та async/await, Promise.all проти allSettled, скасування через AbortController і що робити з unhandledRejection та uncaughtException.
Worker threads, cluster і масштабування
Коли CPU-задачам потрібні worker_threads, як cluster чи process manager використовує всі ядра і чому в продакшені зазвичай масштабуються stateless-контейнерами за балансувальником.
Продуктивність і витоки пам'яті
Як помітити заблокований event loop, профілювання через --cpu-prof і Chrome DevTools, аналіз heap snapshot і типові джерела витоків: глобальні кеші, лісенери та замикання, які ніколи не звільняються.
Безпека
Ін'єкції та prototype pollution, валідація вводу, зберігання секретів, ризики залежностей і supply chain (npm audit, lock-файли), rate limiting і безпечні HTTP-заголовки.
HTTP, API та фреймворки
Middleware в Express, плагіни та валідація схем у Fastify, модулі й DI в NestJS, REST проти GraphQL, graceful shutdown і keep-alive з'єднання.
Тестування
Юніт- та інтеграційні тести з node:test, Jest або Vitest, моки таймерів і мережевих запитів, тести з реальною БД у контейнерах і як тримати тести швидкими та детермінованими.
Питання на співбесіді з Node.js за рівнями
Junior
Node.js виконує JavaScript в одному потоці. Як він обробляє тисячі одночасних запитів?
Що має бути в сильній відповіді:JavaScript виконується в одному потоці, але I/O неблокуючий: сокети Node передає ОС (epoll, kqueue, IOCP), а частину операцій, як-от роботу з файловою системою, у пул потоків libuv. Коли операція завершується, колбек стає в чергу, і event loop його виконує. Це добре працює для I/O-навантаження, але одна довга CPU-задача блокує всі інші запити.
Чим відрізняються process.nextTick, setImmediate і setTimeout(fn, 0)?
Що має бути в сильній відповіді:Колбеки process.nextTick виконуються одразу після поточної операції, раніше за мікротаски промісів і до продовження event loop. setTimeout(fn, 0) спрацьовує у фазі timers щонайменше через 1 мс, а setImmediate у фазі check одразу після poll. Усередині I/O-колбека setImmediate завжди спрацює раніше за таймаут, а в основному модулі порядок не гарантований. Рекурсивний nextTick може «заморити» I/O.
Чим відрізняються CommonJS і ES-модулі в Node.js?
Що має бути в сильній відповіді:CommonJS використовує require і module.exports, завантажується синхронно і є типовим для .js-файлів без "type": "module". ES-модулі використовують import/export, статично аналізуються, підтримують top-level await і вмикаються через .mjs або "type": "module". В ESM за замовчуванням немає __dirname і require (замість них import.meta.dirname чи import.meta.url), а свіжі версії Node вміють робити require() синхронних ES-модулів.
Як обробляти помилки в колбеках, промісах і async/await?
Що має бути в сильній відповіді:Колбеки в Node побудовані за принципом error-first, тому спершу перевіряєте аргумент err, а потім результат. У промісів є .catch, а з async/await обгортаєте await у try/catch або даєте помилці піднятися до централізованого обробника. Забутий await чи відсутній catch призводить до unhandled rejection, який з Node 15 за замовчуванням завершує процес.
Що таке middleware в Express і чому важливий їхній порядок?
Що має бути в сильній відповіді:Middleware це функція (req, res, next), яка виконується в порядку реєстрації і може змінити запит, завершити відповідь або викликати next(), щоб передати керування далі. Порядок важливий: парсери тіла й авторизація мають стояти перед роутами, а обробник помилок із чотирма аргументами (err, req, res, next) іде останнім. В Express 5 відхилені проміси з async-обробників автоматично потрапляють в обробник помилок.
Middle
Поясніть стріми та backpressure. Що буде, якщо ігнорувати backpressure?
Що має бути в сильній відповіді:Стріми обробляють дані частинами, а не вантажать усе в пам'ять. Backpressure це сигнал, що споживач повільніший за джерело: write() повертає false, коли буфер перевищує highWaterMark, і джерело має чекати події drain. Якщо це ігнорувати, дані накопичуються в пам'яті, і процесу може забракнути heap. stream.pipeline (або його версія з промісами) враховує backpressure, прокидає помилки й закриває всі стріми при збої.
Порівняйте Promise.all, Promise.allSettled, Promise.race і Promise.any. Коли що використовувати?
Що має бути в сильній відповіді:Promise.all резолвиться, коли всі успішні, і відхиляється на першій помилці, тож підходить, коли потрібен кожен результат. allSettled чекає на всі й повертає статус кожного, це зручно для пакетних задач, де часткова невдача допустима. race завершується першим промісом, що завершився, зазвичай для таймаутів, а any повертає перший успіх і падає, лише коли впали всі. Жоден із них не скасовує решту роботи, для справжнього скасування передають AbortSignal.
Що може заблокувати event loop і як це виявити та виправити?
Що має бути в сильній відповіді:Блокує синхронна CPU-робота: важкі цикли, JSON.parse чи stringify великих даних, синхронні виклики fs чи crypto і катастрофічний backtracking у регулярках. Виявляють через метрику затримки event loop (perf_hooks.monitorEventLoopDelay), APM або CPU-профіль. Виправляють винесенням CPU-роботи у worker threads чи окремий сервіс, розбиттям на частини, стрімінгом великих даних і асинхронними API.
Як знайти й виправити витік пам'яті в Node.js-сервісі?
Що має бути в сильній відповіді:Спочатку переконатися, що це витік: heap стабільно росте між циклами GC за сталого навантаження, а не виходить на плато. Далі зняти два-три heap snapshot з інтервалом (через --inspect, DevTools або --heapsnapshot-signal) і порівняти, які об'єкти ростуть і що їх утримує. Типові причини: необмежені кеші чи Map у пам'яті, лісенери, які не знімаються, замикання з великими об'єктами і неочищені таймери. Виправлення: обмежити кеш або додати TTL, знімати лісенери й перевірити навантажувальним тестом.
Як реалізувати graceful shutdown для HTTP-сервісу?
Що має бути в сильній відповіді:На SIGTERM припиняєте приймати нові з'єднання через server.close(), позначаєте сервіс як not ready, щоб балансувальник перестав слати трафік, і даєте завершитися поточним запитам. Потім закриваєте простоюючі keep-alive з'єднання, дочитуєте черги й закриваєте пули БД та інші клієнти. Жорсткий таймаут примусово завершує процес, якщо щось зависло, щоб оркестратор не вбивав його SIGKILL посеред запиту.
Senior
Коли використовувати worker_threads, cluster, child_process, а коли просто більше інстансів?
Що має бути в сильній відповіді:worker_threads виконують JavaScript паралельно в одному процесі з можливістю спільної пам'яті (SharedArrayBuffer, transferable-об'єкти) і підходять для CPU-задач на кшталт обробки зображень чи парсингу, зазвичай через пул. cluster форкає процеси зі спільним портом, щоб задіяти всі ядра, але в контейнерах простіше один процес на контейнер і горизонтальне масштабування. child_process для запуску зовнішніх програм або ізоляції ризикованої роботи. Вибір залежить від того, що є вузьким місцем: CPU, ізоляція чи пропускна здатність.
p99 затримки вашого Node.js API в продакшені різко зросла, а CPU в нормі. Як будете розбиратися?
Що має бути в сильній відповіді:Спершу подивлюся на затримку event loop і паузи GC, потім на зовнішні виклики через distributed tracing: чи не сповільнилися БД, кеш або сторонній API. Інші часті причини: вичерпаний пул з'єднань, переповнений пул потоків libuv (за замовчуванням 4) через fs, dns.lookup чи crypto і відсутні таймаути, через які запити стоять у черзі за повільними. Зіставлю з останніми деплоями й трафіком, відтворю під навантаженням і підтверджу фікс метриками.
Яка ваша стратегія щодо unhandledRejection і uncaughtException у продакшені?
Що має бути в сильній відповіді:Після необробленого винятку стан процесу невідомий, тому безпечно залогувати помилку з контекстом, скинути логи й метрики і вийти з ненульовим кодом, щоб супервізор перезапустив процес. Спроба працювати далі ризикує зіпсованим станом і витоком ресурсів. Unhandled rejection у сучасному Node і так завершує процес, а справжнє рішення в тому, щоб їх не допускати: коректні await, централізована обробка помилок і лінт-правила на кшталт no-floating-promises.
Як прокинути контекст запиту, наприклад trace ID, через усі async-виклики без ручної передачі?
Що має бути в сильній відповіді:Через AsyncLocalStorage з node:async_hooks: у middleware запускаєте сховище на кожен запит через als.run(), і будь-який код у цьому async-ланцюжку може його прочитати, наприклад логер. На цьому побудовані request-scoped логування і трейсинг в OpenTelemetry та фреймворках як NestJS. Сховище варто тримати маленьким, не перетворювати на приховану DI, і пам'ятати, що контекст може губитися в деяких бібліотеках на власних колбеках.
Як захистити Node.js API та його залежності?
Що має бути в сильній відповіді:На рівні коду: валідація вводу схемами, параметризовані запити, захист від prototype pollution при злитті об'єктів користувача, security-заголовки, rate limiting і нормальна автентифікація. Для supply chain: комітити lock-файл, ставити через npm ci, запускати npm audit чи сканер у CI, мінімізувати залежності й обережно ставитися до install-скриптів. У рантаймі: запуск не від root, секрети поза кодом і логами, підтримувана LTS-версія і, за потреби, permission model Node, щоб обмежити доступ до fs чи дочірніх процесів.
Як проходить мок-співбесіда з Node.js
- Оберіть Node.js (та інші технології зі свого стеку), свій рівень і мову співбесіди: українську, англійську або російську. Або завантажте резюме й опис вакансії.
- Відповідайте на кожне запитання голосом, як на справжній співбесіді.
- Отримайте оцінку кожної відповіді за точністю, повнотою та зрозумілістю і звіт зі слабкими місцями.
Як відповідати на питання з Node.js вголос
- →На питання про event loop називайте фази по порядку (timers, pending callbacks, poll, check, close) і кажіть, де місце nextTick і мікротасок промісів: чітка послідовність звучить впевненіше, ніж розмите «воно асинхронне».
- →Прив'язуйте кожне поняття до наслідку в продакшені: заблокований event loop означає зростання затримки для всіх користувачів, ігнорований backpressure означає ріст пам'яті, unhandled rejection означає впалий процес.
- →На питання «як би ви дебажили X» ідіть кроками: яку метрику дивитеся першою, який інструмент берете (CPU-профіль, heap snapshot, трейсинг) і як перевіряєте, що фікс спрацював.
- →Називайте конкретні API замість описів: stream.pipeline, AbortController, AsyncLocalStorage, worker_threads, server.close(). Це кількома словами показує практичний досвід.
- →У питаннях про фреймворки почніть із механізму Node.js, а потім скажіть, як його обгортає Express, Fastify чи NestJS: тоді відповідь працює, навіть якщо інтерв'юер має на увазі інший фреймворк.
Часті запитання
Чи треба писати код під час мок-співбесіди з Node.js?
Ні. Редактора для live coding немає: ШІ ставить усні питання, а ви відповідаєте голосом, пояснюючи концепції, компроміси і як би розв'язали задачу. Так тренується та частина співбесіди, де треба чітко розповісти про внутрішню роботу Node.js і архітектурні рішення.
Чи можна поєднати Node.js з TypeScript, PostgreSQL чи іншими технологіями?
Так. При виборі технологій можна обрати кілька, наприклад Node.js, TypeScript і PostgreSQL, і питання будуть змішані, як на звичайній бекенд-співбесіді. Також можна завантажити резюме або опис вакансії, щоб отримати питання під реальний стек позиції.
Чи будуть питання про Express або NestJS?
Питання про фреймворки з'являються там, де вони доречні, але фокус на самому Node.js: event loop, стріми, обробка async-помилок, продуктивність і безпека. Якщо в завантаженій вакансії згадано конкретний фреймворк, питання підлаштуються під нього.
Скільки коштує мок-співбесіда з Node.js?
Перша співбесіда до 5 питань безкоштовна. Далі оплата за кожну співбесіду, від $1.75, без підписки. В одній співбесіді може бути до 50 питань.