← Усі теми

Питання на співбесіді з NestJS з відповідями

Модулі, контролери й провайдери, впровадження залежностей, pipes, guards, interceptors і фільтри, валідація, TypeORM і Prisma, тестування, мікросервіси та GraphQL.

225 запитань для співбесіди з теми NestJS з відповідями й поясненнями - рівні Junior, Middle і Senior. Приклади запитань, онлайн-тести й задачі на код.

Запитання за рівнями

Приклади запитань

Кілька запитань із кожного рівня з правильною відповіддю й поясненням.

NestJS · Junior

  1. Що таке NestJS?

    Правильна відповідь: Фреймворк на Node.js для серверних застосунків на TypeScript з модулями, впровадженням залежностей і декораторами

    Nest дає структуровану архітектуру, натхненну Angular. Під капотом працює HTTP-фреймворк, Express за замовчуванням або Fastify, а Nest додає модулі, DI, pipes, guards тощо.

  2. Яку HTTP-платформу NestJS використовує за замовчуванням?

    Правильна відповідь: Express

    Express - адаптер за замовчуванням. Перейти на Fastify можна через @nestjs/platform-fastify заради продуктивності, і більшість коду лишиться без змін.

  3. Як створити новий проєкт NestJS?

    Правильна відповідь: npx @nestjs/cli new my-app (або nest new my-app, якщо CLI встановлений)

    CLI створює main.ts, кореневий AppModule, приклад контролера й сервісу та налаштування тестів. nest generate (nest g) додає модулі, контролери й сервіси.

  4. Яку мову переважно використовує NestJS?

    Правильна відповідь: TypeScript (звичайний JavaScript теж підтримується)

    Nest спирається на декоратори TypeScript і метадані типів для впровадження залежностей, тож TypeScript - природний вибір.

Усі 75 запитань з відповідями →

NestJS · Middle

  1. У якому порядку виконуються шари обробки запиту в Nest?

    Правильна відповідь: Middleware → guards → interceptors (до) → pipes → обробник → interceptors (після) → фільтри винятків (при помилці)

    Усередині кожного шару спершу виконуються глобальні, потім рівня контролера, потім рівня маршруту. Фільтри винятків обробляють помилки, кинуті будь-де на цьому шляху.

  2. Чому автентифікацію варто робити guard-ом, а не middleware?

    Правильна відповідь: Guard має ExecutionContext, тож знає, який обробник і які метадані (ролі, @Public()) застосовуються, і працює для HTTP, GraphQL і мікросервісів

    Middleware не знає, який обробник маршруту виконається. Guards призначені саме для рішень «чи може цей запит пройти далі?».

  3. Для чого ExecutionContext?

    Правильна відповідь: Він дає guards та interceptors поточний обробник, клас і запит і дозволяє одній реалізації працювати для HTTP, RPC і WebSockets

    Типові виклики: context.switchToHttp().getRequest(), context.getHandler(), context.getClass() і context.getType().

  4. Як interceptor може обгорнути кожну відповідь у { data: ... }?

    Правильна відповідь: return next.handle().pipe(map((data) => ({ data })))

    Interceptors - місце для наскрізних змін відповідей. Будьте послідовні: помилки формують фільтри винятків, а не interceptors.

Усі 75 запитань з відповідями →

NestJS · Senior

  1. Як Nest знає, що впровадити в constructor(private users: UsersService)?

    Правильна відповідь: TypeScript записує метадані design:paramtypes (з emitDecoratorMetadata), а Nest читає їх через reflect-metadata і шукає провайдери за класом-токеном

    Тому імпорти лише типів (import type) чи інтерфейси ламають впровадження: немає значення під час виконання, яке можна взяти за токен.

  2. Чому бандлер чи компілятор без підтримки метаданих декораторів може зламати Nest-застосунок?

    Правильна відповідь: Без design:paramtypes Nest не розв'яже залежності конструктора за типом, тож впровадження падає, якщо кожен параметр не має @Inject(token)

    esbuild, наприклад, не записує метадані декораторів. SWC підтримує їх за правильної конфігурації, тому Nest документує налаштування SWC.

  3. Як DI-контейнер організований між модулями?

    Правильна відповідь: Кожен модуль має власну область інжектора; провайдери видимі всередині модуля, а в модулях, що його імпортують, - лише якщо експортовані

    Через цю інкапсуляцію той самий клас у провайдерах двох модулів дає два екземпляри.

  4. Провайдер з областю REQUEST впроваджено в сервіс-синглтон. Що станеться?

    Правильна відповідь: Сервіс і його споживачі теж стануть request-scoped, тож увесь ланцюжок створюватиметься на кожен запит

    Область піднімається вгору. У навантаженому застосунку це може помножити виділення пам'яті на запит; для мультитенантності є durable-провайдери чи ALS.

Усі 75 запитань з відповідями →

Збірні тести з цією темою

Запитання з кількох тем одразу - як на співбесіді на конкретну вакансію.

Задачі на код

Напишіть рішення просто в браузері - тести перевірять його одразу. Класика співбесід на JavaScript (debounce, deepClone, Promise.all, LRU-кеш) і на React: компоненти й хуки на кшталт списку справ, вкладок, useDebounce та useInterval.

Відкрити задачі →