Skip to main content

Node.js Fundamentals

Node.js Runtime Environment​

  • Кратко: Node.js — это среда выполнения JavaScript, позволяющая запускать JS-код на стороне сервера, вне браузера. Она не является ни языком, ни фреймворком.
  • Почему спрашивают на собеседовании: Проверяет базовое понимание роли Node.js в экосистеме, отличает от JavaScript как языка и фреймворков.
  • Хитрости/подводные камни: Иногда путают с JavaScript или Express.js; важно подчеркнуть, что это именно "runtime environment".
  • Что важно не забыть:
    • Позволяет JavaScript работать на сервере.
    • Использует V8 движок.
    • Обеспечивает управление памятью и ввод/вывод.
    • Отличается от браузерного окружения (нет DOM, window, но есть request/response, server, data, database objects).
  • Быстрый чек-лист ответа синьора:
    • V8 JavaScript engine.
    • Среда выполнения (не язык, не фреймворк).
    • Серверная сторона.
    • Взаимодействие с системными ресурсами (файловая система, сеть).
  • Приоритет на собесе: Высокий
  • Сложность: Базовая
  • Уверенность в корректности (по материалам): 100%

V8 Engine​

  • Кратко: V8 — это JavaScript-движок с открытым исходным кодом, разработанный Google на C++, который используется в Chrome и Node.js для преобразования JavaScript-кода в эффективный машинный код.
  • Почему спрашивают на собеседовании: Понимание, почему Node.js работает быстро и как JS-код исполняется на сервере, а также его связь с браузерными технологиями.
  • Хитрости/подводные камни: Не просто "движок JavaScript", а именно оптимизирующий компилятор (JIT), который напрямую конвертирует в машинный код.
  • Что важно не забыть:
    • Разработан Google.
    • Написан на C++.
    • Конвертирует JS в машинный код (JIT-компиляция).
    • Используется Node.js для скорости выполнения на сервере.
    • Позволил JavaScript работать вне браузера.
  • Быстрый чек-лист ответа синьора:
    • Google Chrome.
    • C++.
    • JIT-компиляция.
    • Повышение производительности.
  • Приоритет на собесе: Высокий
  • Сложность: Базовая
  • Уверенность в корректности (по материалам): 100%

Event Loop (Цикл событий)​

  • Кратко: Event Loop — это механизм, позволяющий Node.js выполнять неблокирующие операции ввода/вывода, несмотря на то, что JavaScript является однопоточным языком. Он постоянно опрашивает очередь событий и отправляет задачи на выполнение.
  • Почему спрашивают на собеседовании: Ключевой концепт для понимания асинхронности, производительности и архитектуры Node.js.
  • Хитрости/подводные камни:
    • Не все операции, отложенные в Event Loop, исполняются "быстро"; блокирующие операции (CPU-intensive) в единственном потоке JavaScript могут остановить весь Event Loop.
    • Существуют различные фазы Event Loop (таймеры, poll, check, close callbacks, nextTickQueue, microtaskQueue), и порядок их выполнения важен.
    • Event Loop — это цикл, который продолжает существовать на протяжении всей жизни приложения, пока есть слушатели или активные задачи; если их нет, процесс завершается (System.exit).
  • Что важно не забыть:
    • Обеспечивает неблокирующий I/O.
    • Работает с очередями событий (Event Queue).
    • Является основой асинхронности в Node.js.
    • Имеет несколько фаз (timers, poll, check, etc.).
    • Позволяет выполнять конкурентные операции в однопоточном JS.
    • Может быть заблокирован "тяжелыми" синхронными задачами.
  • Быстрый чек-лист ответа синьора:
    • Non-blocking I/O.
    • Single-threaded JavaScript.
    • Phases (NextTick, Microtasks, Poll, Check).
    • Event Queue.
    • Libuv (под капотом).
  • Приоритет на собесе: Высокий
  • Сложность: Продвинутая
  • Уверенность в корректности (по материалам): 100%

Однопоточность Node.js​

  • Кратко: JavaScript в Node.js является однопоточным, что означает, что основной поток выполнения работает с одним потоком. Однако Node.js достигает конкурентности и неблокирующего I/O за счет Event Loop и вспомогательных механизмов.
  • Почему спрашивают на собеседовании: Проверяет понимание фундаментального ограничения и способов его преодоления в Node.js.
  • Хитрости/подводные камни:
    • Не путать с синхронностью: Однопоточная программа может быть как синхронной, так и асинхронной.
    • Блокировка: Тяжелые (CPU-intensive) операции в основном потоке JS полностью блокируют Event Loop и все входящие запросы.
    • ⚠️ Разночтения: Источник заявляет, что Node.js "kind of augments" single-threaded JS, позволяя concurrent operations через Event Loop. Источник также говорит, что "Node like JavaScript is a single threaded program". Однако, источник утверждает, что сам Event Loop однопоточный, за исключением дочерних процессов, и что Libuv (с worker threads) отвечает за обработку сложных асинхронных задач.
  • Что важно не забыть:
    • JavaScript по своей природе однопоточен.
    • Event Loop работает в одном потоке.
    • Конкурентность достигается через неблокирующие I/O и Event Loop.
    • CPU-bound задачи следует выносить в Worker Threads.
    • Блокировка приводит к снижению производительности и уязвимостям (DoS).
  • Быстрый чек-лист ответа синьора:
    • JavaScript — однопоточный.
    • Event Loop.
    • Неблокирующий I/O.
    • Worker Threads для CPU-intensive.
    • Libuv (под капотом).
  • Приоритет на собесе: Высокий
  • Сложность: Продвинутая
  • Уверенность в корректности (по материалам): 90%

Асинхронное и Синхронное Программирование​

  • Кратко: Синхронное программирование выполняет задачи последовательно, ожидая завершения каждой перед началом следующей (блокирующий подход). Асинхронное программирование позволяет инициировать задачи и не ждать их завершения, переходя к следующим (неблокирующий, конкурентный подход).
  • Почему спрашивают на собеседовании: Фундаментальное понимание принципов работы Node.js, его преимуществ и ограничений.
  • Хитрости/подводные камни:
    • Синхронность: Приводит к низкой производительности и "блокирующему" поведению.
    • Асинхронность: Несмотря на использование одного потока, Node.js позволяет выполнять задачи конкурентно.
    • Callback Hell: Проблема при чрезмерном использовании колбэков для управления асинхронным потоком. Решения: Promises, async/await, модульность.
  • Что важно не забыть:
    • Node.js использует асинхронный, неблокирующий подход.
    • Синхронные операции блокируют Event Loop.
    • Асинхронность достигается с помощью Event Loop.
    • Преимущества асинхронности: производительность, неблокирующее выполнение.
    • Инструменты: Callbacks, Promises, async/await.
  • Быстрый чек-лист ответа синьора:
    • Блокирующее/неблокирующее.
    • Event Loop.
    • Конкурентность/параллельность.
    • Promises/Async-await.
    • Callback Hell (проблема и решения).
  • Приоритет на собесе: Высокий
  • Сложность: Базовая
  • Уверенность в корректности (по материалам): 100%

Core Node.js Concepts

Модули в Node.js​

  • Кратко: Модуль — это кусок функциональности, обычно представленный одним JavaScript-файлом, который может быть повторно использован в приложении Node.js.
  • Почему спрашивают на собеседовании: Понимание организации кода, разделения ответственности и использования библиотек.
  • Хитрости/подводные камни:
    • Module Wrapper Function: Node.js оборачивает каждый модуль в функцию, что предоставляет локальную область видимости и скрывает детали реализации.
    • Типы модулей: Встроенные (core), локальные (пользовательские), сторонние (third-party).
    • Проблемы с зависимостями: Вложенные зависимости, конфликты версий, "node_modules" как потенциальная "боль" (по мнению Райана Даля).
  • Что важно не забыть:
    • Инкапсуляция функциональности.
    • require/module.exports/exports.
    • Три типа модулей (Built-in, Local, Third-party).
    • package.json и node_modules.
    • Module Wrapper Function.
  • Быстрый чек-лист ответа синьора:
    • require/module.exports.
    • Виды модулей.
    • package.json.
    • Module Wrapper.
    • Проблемы с зависимостями (NPM audit, циклические зависимости).
  • Приоритет на собесе: Высокий
  • Сложность: Базовая
  • Уверенность в корректности (по материалам): 95%

Worker Threads (Воркеры / Дочерние процессы)​

  • Кратко: Механизм в Node.js, позволяющий создавать новые экземпляры движка V8 для выполнения CPU-интенсивных задач в отдельных потоках, не блокируя основной Event Loop.
  • Почему спрашивают на собеседовании: Проверяет понимание решения проблемы блокирующих CPU-bound операций в однопоточном Node.js.
  • Хитрости/подводные камни:
    • Не путать с потоками Libuv: Worker Threads — это механизм, предоставляемый Node.js API, в то время как потоки Libuv (thread pool) используются для асинхронного I/O.
    • Межпотоковая коммуникация: Требует обмена сообщениями между основным потоком и воркерами.
    • Не панацея: Не всегда подходят для I/O-bound задач.
  • Что важно не забыть:
    • Для CPU-intensive задач.
    • Создают новые экземпляры V8.
    • Не блокируют основной Event Loop.
    • Являются частью Node.js API.
    • Позволяют распараллелить вычисления.
  • Быстрый чек-лист ответа синьора:
    • CPU-intensive.
    • Non-blocking Event Loop.
    • Новые V8 instances.
    • Обмен сообщениями.
    • Вертикальное масштабирование (в рамках одного процесса).
  • Приоритет на собесе: Высокий
  • Сложность: Продвинутая
  • Уверенность в корректности (по материалам): 95%

Event Emitters (Излучатели событий)​

  • Кратко: Event Emitters — это способ реализации паттерна "Наблюдатель" (Observer) в Node.js, позволяющий создавать decoupled-код. Объект диспатчит событие, а зарегистрированные функции-слушатели (listeners) реагируют на него.
  • Почему спрашивают на собеседовании: Понимание асинхронной коммуникации внутри одного сервиса и принципов событийной архитектуры.
  • Хитрости/подводные камни:
    • Ограниченная область: События Event Emitters ограничены пределами одного локального сервиса/процесса. Для межсервисной коммуникации используются другие паттерны (например, Pub/Sub, брокеры сообщений).
    • Порядок регистрации: Слушатели должны быть зарегистрированы до того, как событие будет излучено, иначе оно будет пропущено.
    • Утечки памяти: Если слушатели не отменяются, это может привести к утечкам. (не было в источниках, но важно для синьора).
  • Что важно не забыть:
    • Паттерн Наблюдатель.
    • on/emit.
    • Декапсулированный код.
    • Асинхронная коммуникация.
    • Локальный скоуп (внутри одного процесса).
    • Могут передавать аргументы событиям.
  • Быстрый чек-лист ответа синьора:
    • Паттерн Observer.
    • EventEmitter класс.
    • on/emit методы.
    • Decoupled communication.
    • Event arguments.
  • Приоритет на собесе: Высокий
  • Сложность: Базовая
  • Уверенность в корректности (по материалам): 100%

Колбэки и Callback Hell​

  • Кратко: Колбэки — это функции, передаваемые в качестве аргументов другим функциям (обычно асинхронным), которые будут вызваны позже, по завершении операции. Callback Hell — проблема вложенности колбэков, усложняющая читаемость и поддержку кода.
  • Почему спрашивают на собеседовании: Понимание исторического подхода к асинхронности в JavaScript/Node.js и эволюции решений.
  • Хитрости/подводные камни:
    • Неопределенное время вызова: Время вызова колбэка обычно недетерминировано.
    • Callback Hell: Приводит к нечитаемому и трудноподдерживаемому коду.
    • Потеря контекста this: В старых реализациях без стрелочных функций. (не было в источниках, но важно для синьора).
  • Что важно не забыть:
    • Асинхронные операции.
    • Функции как аргументы.
    • Проблема Callback Hell.
    • Решения Callback Hell: async/await, Promises, модульность, библиотеки управления потоком, генераторы.
  • Быстрый чек-лист ответа синьора:
    • Асинхронный паттерн.
    • Function as a first-class citizen.
    • Callback Hell (проблема).
    • async/await (решение).
    • Promises (решение).
  • Приоритет на собесе: Средний
  • Сложность: Базовая
  • Уверенность в корректности (по материалам): 100%

Потоки данных (Streams)​

  • Кратко: Streaming — это способ обработки больших объемов данных по частям (чанками) без необходимости загружать их полностью в память, что помогает обойти ограничения по памяти.
  • Почему спрашивают на собеседовании: Понимание эффективной работы с большими файлами или сетевыми данными, оптимизации потребления ресурсов.
  • Хитрости/подводные камни:
    • Сложность обработки ошибок: Обработка ошибок в потоках может быть сложной.
    • Управление потоком: Необходимо правильно управлять скоростью чтения/записи (backpressure), чтобы отправитель не перегружал получателя.
    • Типы потоков: Читаемые (Readable), записываемые (Writable), дуплексные (Duplex), трансформирующие (Transform). (не было в источниках, но важно для синьора).
  • Что важно не забыть:
    • Работа с данными по частям (chunk by chunk).
    • Экономия памяти.
    • Node.js core libraries (like Event Emitters) are built around streams.
    • Применимы для больших файлов, сетевого обмена.
  • Быстрый чек-лист ответа синьора:
    • Memory constraints.
    • Chunked processing.
    • Non-blocking.
    • Backpressure (не было в источниках, но важно для синьора).
    • fs.createReadStream, http.request (не было в источниках, но важно для синьора).
  • Приоритет на собесе: Средний
  • Сложность: Базовая
  • Уверенность в корректности (по материалам): 90%

process.nextTick vs setImmediate​

  • Кратко: Обе функции позволяют отложить выполнение кода, но process.nextTick исполняется в конце текущей фазы Event Loop, до перехода к следующей фазе, а setImmediate — в фазе "check" следующего цикла Event Loop.
  • Почему спрашивают на собеседовании: Проверяет глубокое понимание Event Loop и тонкостей планирования асинхронных задач.
  • Хитрости/подводные камни:
    • nextTick приоритет: process.nextTick имеет более высокий приоритет и исполняется сразу после текущей операции, до любых I/O или таймеров, что может привести к starvation для других операций, если используется чрезмерно.
    • Бесконечный цикл: Чрезмерное использование process.nextTick без ожидания I/O может создать бесконечный цикл, не давая Event Loop перейти к другим фазам. (не было в источниках, но важно для синьора).
  • Что важно не забыть:
    • Обе откладывают выполнение.
    • nextTick исполняется раньше (в той же фазе).
    • setImmediate исполняется в следующей фазе Event Loop (фаза "check").
    • Важно для управления порядком выполнения.
  • Быстрый чек-лист ответа синьора:
    • Event Loop phases.
    • Микро/макротаски (NextTick — микротаска, setImmediate — макротаска).
    • Приоритет выполнения.
    • Блокировка/starvation.
  • Приоритет на собесе: Средний
  • Сложность: Продвинутая
  • Уверенность в корректности (по материалам): 90%

Web Development

RESTful API​

  • Кратко: REST (Representational State Transfer) — это архитектурный стиль для распределенных систем, использующий HTTP-протокол для обмена данными между клиентом и сервером. Он основан на принципах клиент-серверной архитектуры, stateless-операций, кэширования и унифицированного интерфейса.
  • Почему спрашивают на собеседовании: REST является доминирующим стандартом для построения веб-сервисов и API, его понимание критично для бэкенд-разработчика.
  • Хитрости/подводные камни:
    • Over-fetching/Under-fetching: Клиент может получать либо слишком много данных, либо недостаточно, требуя множества запросов.
    • Тайм-ауты: Ограничения на время выполнения запроса могут быть проблемой для долгоживущих операций.
    • Неоднозначность HTTP методов: Разные трактовки PUT/PATCH/POST для обновления.
    • Микросервисы и REST: Межсервисная коммуникация по HTTP может быть "болезненной" из-за тайм-аутов и сетевых проблем.
    • Передача смысла на транспорт: Использование HTTP-методов (GET, POST) для передачи смысла действия вместо тела сообщения.
  • Что важно не забыть:
    • Архитектурный стиль.
    • HTTP-протокол.
    • Принципы REST (stateless, кэширование, унифицированный интерфейс и т.д.).
    • Over-fetching/under-fetching (проблема).
    • Ограничения по тайм-аутам.
    • Использование для веб-приложений и мобильных клиентов.
  • Быстрый чек-лист ответа синьора:
    • Принципы (Stateless, Cacheable, Client-Server).
    • URL (Resources).
    • HTTP Methods.
    • Over-fetching/Under-fetching (проблемы).
    • Тайм-ауты (ограничение).
  • Приоритет на собесе: Высокий
  • Сложность: Базовая
  • Уверенность в корректности (по материалам): 100%

GraphQL​

  • Кратко: GraphQL — это язык запросов для API, который был создан для преодоления недостатков REST, позволяя клиенту запрашивать только те данные, которые ему нужны, с одного endpoint’а.
  • Почему спрашивают на собеседовании: Проверяет знание современных подходов к API, их преимуществ и компромиссов.
  • Хитрости/подводные камни:
    • Over-fetching/Under-fetching: GraphQL решает эту проблему, позволяя клиенту точно определять структуру ответа.
    • Сложность кэширования: Кэширование на стороне браузера может быть сложным, так как запросы GraphQL часто являются POST-запросами.
    • Сложность поддержки (Maintenance): Требует более глубокого погружения команды в детали работы GraphQL.
    • N+1 проблема: Может возникнуть при неоптимизированном извлечении данных (не было в источниках, но важно для синьора).
    • ⚠️ Разночтения: Источник указывает на личный негативный опыт с React и GraphQL из-за проблем со state-менеджером, требующих "велосипедов". Однако, это может быть связано с неверной реализацией.
  • Что важно не забыть:
    • Язык запросов для API.
    • Решает проблемы over-fetching/under-fetching.
    • Один endpoint для разных запросов.
    • Уменьшает сетевую нагрузку.
    • Применяется для мобильных приложений, IoT.
    • Может быть сложным для кэширования и поддержки.
  • Быстрый чек-лист ответа синьора:
    • Query language.
    • One endpoint, varied responses.
    • Over-fetching/under-fetching solution.
    • Network load reduction.
    • Caching challenges (POST requests).
  • Приоритет на собесе: Средний
  • Сложность: Продвинутая
  • Уверенность в корректности (по материалам): 90%

WebSockets​

  • Кратко: WebSockets обеспечивают двунаправленную (bidirectional) связь между клиентом и сервером через одно постоянное соединение, позволяя серверу отправлять данные клиенту без предварительного запроса.
  • Почему спрашивают на собеседовании: Понимание технологий для реализации real-time приложений.
  • Хитрости/подводные камни:
    • Сохранение состояния: В отличие от REST, WebSockets могут требовать сохранения состояния на сервере. (не было в источниках, но важно для синьора).
    • Масштабирование: Требует специфических решений для масштабирования (sticky sessions, message brokers). (не было в источниках, но важно для синьора).
    • Обработка ошибок и переподключение: Более сложная логика на клиенте для обработки ошибок и восстановления соединения. (не было в источниках, но важно для синьора).
  • Что важно не забыть:
    • Real-time features.
    • Bidirectional communication.
    • Постоянное соединение (long-lived connection).
    • Сервер может пушить данные.
    • Используется для чатов, онлайн-игр, коллаборативных инструментов.
  • Быстрый чек-лист ответа синьора:
    • Real-time.
    • Bidirectional.
    • Single persistent connection.
    • Server-sent events.
    • Chat, gaming applications.
  • Приоритет на собесе: Средний
  • Сложность: Базовая
  • Уверенность в корректности (по материалам): 100%

HTTP Module​

  • Кратко: Встроенный модуль Node.js, который предоставляет функциональность для создания HTTP-серверов и клиентов. Позволяет слушать порты, принимать запросы и отправлять ответы.
  • Почему спрашивают на собеседовании: Понимание базовых строительных блоков для веб-сервисов в Node.js.
  • Хитрости/подводные камни:
    • Низкоуровневый API: Для сложной логики маршрутизации и обработки запросов обычно используются фреймворки (Express.js, NestJS), которые являются "оберткой" над HTTP модулем.
    • Ручное управление: Требует ручной обработки заголовков, тела запроса/ответа, статусов.
  • Что важно не забыть:
    • Создание HTTP-сервера.
    • Прослушивание портов.
    • Обработка запросов (request).
    • Отправка ответов (response).
    • Базовый строительный блок для фреймворков.
  • Быстрый чек-лист ответа синьора:
    • createServer.
    • listen.
    • request/response objects.
    • TCP/IP (под капотом).
    • Middleware (для Express).
  • Приоритет на собесе: Средний
  • Сложность: Базовая
  • Уверенность в корректности (по материалам): 100%

HTTP Status Codes (Статусы HTTP)​

  • Кратко: Цифровые коды, которые сервер отправляет клиенту в ответе HTTP, указывая на результат обработки запроса (например, 200 OK, 404 Not Found, 500 Internal Server Error).
  • Почему спрашивают на собеседовании: Понимание стандартов веб-коммуникации, обработки ошибок и взаимодействия с клиентами.
  • Хитрости/подводные камни:
    • Нестандартные/кастомные статусы: Некоторые компании используют свои собственные расширения или кастомные статусы (например, 418 I'm a Teapot), что может упростить унификацию ответов, но требует хорошей документации.
    • Google-подход: Некоторые компании (например, Google) предпочитают всегда возвращать 200 OK и помещать детали ошибки в тело ответа.
    • Бизнес-ценность: Важно понимать, какую пользу для бизнеса приносит выбор конкретного статус-кода и его унификация (упрощение тестирования, отладки, интеграции).
  • Что важно не забыть:
    • Группы статусов (1xx, 2xx, 3xx, 4xx, 5xx).
    • Указывают результат запроса.
    • Обработка ошибок.
    • Унификация ответов.
    • Возможны кастомные статусы.
  • Быстрый чек-лист ответа синьора:
    • Standard groups (2xx, 4xx, 5xx).
    • Semantics of each group.
    • Custom status codes (use cases, trade-offs).
    • Consistency across API.
    • Impact on client-side logic.
  • Приоритет на собесе: Средний
  • Сложность: Продвинутая
  • Уверенность в корректности (по материалам): 100%

Аутентификация и Авторизация (Токены, Куки, JWT)​

  • Кратко: Методы подтверждения личности пользователя (аутентификация) и определения его прав доступа (авторизация). Часто реализуются с использованием токенов (например, JWT), хранящихся в куках или локальном хранилище.
  • Почему спрашивают на собеседовании: Критически важная часть любого веб-приложения, требующая глубокого понимания безопасности.
  • Хитрости/подводные камни:
    • Передача паролей: Пароли не следует передавать в открытом виде (query params). Используются хеширование, передача в теле запроса (Body) или заголовках (Headers) через HTTPS.
    • Хранение токенов: Куки с флагами Secure, HttpOnly считаются более безопасными, чем Local Storage.
    • Refresh/Access токены: Используются для обеспечения безопасности и удобства пользователя (Access Token короткоживущий, Refresh Token для получения нового Access Token).
    • Недействительность токенов: Механизмы для принудительного отзыва токенов (например, "черный список" токенов в базе данных).
    • CSRF-токены: Для защиты от Cross-Site Request Forgery атак.
    • JWT: Третья часть токена не должна содержать открытые секретные данные (например, пароли), но может содержать ID пользователя.
  • Что важно не забыть:
    • Пароли (хеширование, соль).
    • JWT (JSON Web Tokens).
    • Access/Refresh токены.
    • Cookies vs Local Storage (Secure, HttpOnly).
    • CSRF токены.
    • Защита от перехвата (HTTPS).
    • Инвалидация токенов (черные списки).
  • Быстрый чек-лист ответа синьора:
    • JWT structure and use.
    • Access/Refresh token flow.
    • Cookie flags (Secure, HttpOnly).
    • CSRF protection.
    • Token invalidation mechanisms (blacklist).
  • Приоритет на собесе: Высокий
  • Сложность: Продвинутая
  • Уверенность в корректности (по материалам): 100%

Фреймворки Node.js (Express, NestJS, Koa, Fastify)​

  • Кратко: Фреймворки (Express.js, NestJS, Koa, Fastify) — это обертки над средой выполнения Node.js (runtime environment), которые упрощают разработку веб-приложений и API, предоставляя структурированный набор инструментов, библиотек и лучшие практики.
  • Почему спрашивают на собеседовании: Проверяет знание популярных инструментов, понимание их различий, преимуществ и когда какой фреймворк использовать.
  • Хитрости/подводные камни:
    • Express.js: Низкоуровневый, непредвзятый (unopinionated), дает больше контроля, но может требовать больше boilerplate-кода для больших приложений. Изначально имел проблемы с асинхронностью (Callback Hell), но потом были добавлены решения.
    • NestJS: Высокоуровневый, предвзятый (opinionated), вводит продвинутые концепции (Dependency Injection, декораторы), предлагает структуру кода, подходит для больших и поддерживаемых приложений. Может использовать Express.js или Fastify под капотом.
    • Koa: Создан на основе генераторов для улучшения асинхронности, когда Express.js имел проблемы с Callback Hell.
    • Fastify: Создан для высокой производительности, может использоваться с NestJS.
  • Что важно не забыть:
    • Express.js (микрофреймворк, непредвзятый).
    • NestJS (высокоуровневый, предвзятый, DI).
    • Koa (генераторы, async).
    • Fastify (производительность).
    • Роль фреймворков: упрощение разработки, структура, API.
  • Быстрый чек-лист ответа синьора:
    • Express vs Nest (opinionated, DI, structure).
    • When to use each (small vs large apps).
    • Middleware concept (Express).
    • Async handling in frameworks.
    • Performance (Fastify).
  • Приоритет на собесе: Высокий
  • Сложность: Базовая
  • Уверенность в корректности (по материалам): 100%

Валидация данных​

  • Кратко: Процесс проверки входящих данных (например, от клиента) на соответствие определенным правилам и форматам, чтобы предотвратить ошибки, уязвимости или некорректное поведение приложения.
  • Почему спрашивают на собеседовании: Критически важно для безопасности и надежности приложения.
  • Хитрости/подводные камни:
    • Невалидные данные от клиента: Могут вызвать ошибки парсинга (например, JSON.parse) или привести к инъекциям.
    • Серверная валидация: Всегда необходима, даже если есть клиентская, так как клиентские данные могут быть подделаны.
    • Инструменты: Использование библиотек (Joi, Zod, class-validators) или JSON-схем.
    • Pipeline-трансформации: В NestJS есть механизм трансформации и валидации данных в пайплайнах.
  • Что важно не забыть:
    • Проверка входящих данных.
    • Защита от ошибок и уязвимостей.
    • Библиотеки (Joi, Zod, class-validators).
    • Обработка ошибок валидации (exception classes).
    • Серверная валидация обязательна.
  • Быстрый чек-лист ответа синьора:
    • Server-side validation.
    • Libraries (Zod, Joi).
    • Error handling for invalid data.
    • Transformation pipelines (NestJS).
  • Приоритет на собесе: Средний
  • Сложность: Базовая
  • Уверенность в корректности (по материалам): 100%

Основы HTTP​

  • Кратко: HTTP (Hypertext Transfer Protocol) — это протокол прикладного уровня, используемый для передачи данных в World Wide Web. Он определяет формат запросов и ответов между клиентом и сервером.
  • Почему спрашивают на собеседовании: Фундаментальное понимание работы веб-приложений.
  • Хитрости/подводные камни:
    • Модель OSI: HTTP находится на прикладном уровне OSI модели, а TCP/IP на транспортном и сетевом соответственно.
    • HTTPS: Использование TLS/SSL для шифрования, но не снимает полностью проблему MitM-атак, если злоумышленник контролирует сертификаты.
    • HTTP/1.1, HTTP/2, HTTP/3 (QUIC/UDP): Различия в производительности, мультиплексировании, Head-of-Line Blocking и протоколах (TCP vs UDP).
    • Структура запроса: Метод, URL, заголовки, тело.
    • Методы и тело запроса: Не все HTTP-методы могут иметь тело запроса (например, GET, OPTIONS).
  • Что важно не забыть:
    • Прикладной уровень.
    • Запросы (Method, URL, Headers, Body).
    • Ответы (Status, Headers, Body).
    • Версии (1.1, 2, 3).
    • HTTPS (шифрование).
    • TCP vs UDP (доставка пакетов).
  • Быстрый чек-лист ответа синьора:
    • OSI Layer (Application).
    • Request/Response structure.
    • HTTP Methods (GET, POST, PUT, PATCH, DELETE).
    • HTTPS (TLS/SSL).
    • Versions (HTTP/1.1, HTTP/2, HTTP/3 with QUIC/UDP).
  • Приоритет на собесе: Средний
  • Сложность: Базовая
  • Уверенность в корректности (по материалам): 100%

Databases

Реляционные (SQL) и Нереляционные (NoSQL) базы данных​

  • Кратко: Реляционные БД (например, PostgreSQL, MySQL) хранят данные в структурированных таблицах со строками и столбцами, используют SQL для запросов и поддерживают ACID-транзакции. Нереляционные БД (например, MongoDB) хранят данные в более гибких форматах (ключ-значение, документы, графы) и часто предлагают более высокую масштабируемость и гибкость схемы.
  • Почему спрашивают на собеседовании: Проверяет понимание различных парадигм хранения данных, их преимуществ и недостатков, а также способность выбрать подходящую базу данных для конкретной задачи.
  • Хитрости/подводные камни:
    • MongoDB и транзакции: Исторически MongoDB не поддерживала полноценные транзакции, но в последних версиях они были добавлены.
    • Выбор базы: Зависит от требований микросервиса, типа данных (структурированные/неструктурированные), важности данных, необходимости быстрых запросов.
    • Переезд между базами: Сложности при смене типа базы данных (например, с MongoDB на PostgreSQL) в случае жесткой привязки к конкретной реализации.
    • Составные индексы: Могут быть эффективны для оптимизации сложных запросов, но требуют ресурсов и могут быть дорогими.
  • Что важно не забыть:
    • PostgreSQL/MySQL (SQL, таблицы, ACID).
    • MongoDB (NoSQL, документы/key-value, гибкая схема).
    • Когда что использовать (структура, транзакции, гибкость).
    • Транзакции в MongoDB (недавно добавлены).
    • ACID-свойства.
  • Быстрый чек-лист ответа синьора:
    • Relational vs Non-relational (structure, schema).
    • ACID properties (for SQL).
    • Scalability vs Consistency (NoSQL trade-offs).
    • Use cases for each (structured data, financial vs flexible, analytics).
    • Transactions in MongoDB (recent feature).
  • Приоритет на собесе: Высокий
  • Сложность: Базовая
  • Уверенность в корректности (по материалам): 100%

Оптимизация баз данных (Индексы, Шардирование, Репликация, Кэширование)​

  • Кратко: Комплекс мер по повышению производительности СУБД, включая создание индексов для ускорения поиска, шардирование для горизонтального разделения данных, репликацию для обеспечения доступности и масштабирования чтения, а также кэширование для быстрого доступа к часто используемым данным.
  • Почему спрашивают на собеседовании: Проверяет способность проектировать и поддерживать высокопроизводительные и отказоустойчивые системы.
  • Хитрости/подводные камни:
    • Отсутствие индекса: Поиск по неиндексированным полям в больших коллекциях может быть очень медленным и блокировать базу данных.
    • Составные индексы: Эффективны для сложных запросов, но требуют больше ресурсов.
    • Новые индексы на больших таблицах: Могут быть дорогими (требуют нового оборудования).
    • Репликация (Master-Slave/Master-Master): Master-Master может привести к конфликтам. Master-Slave используется для масштабирования чтения и отказоустойчивости.
    • Шардирование/Партиционирование: Разделение данных по разным коллекциям/серверам для распределения нагрузки и улучшения производительности.
    • Кэширование: Redis используется как временное хранилище. Важно управлять стратегиями кэширования (по времени, по частоте использования). CDN (Content Delivery Network) для глобального кэширования.
    • Оптимизация запросов: Уменьшение количества джоинов, получение только необходимых данных, использование вложенных запросов или агрегаций.
    • Оптимизация типов данных: Изменение типа колонки (например, VARCHAR(128) на INT) для уменьшения объема данных и ускорения поиска.
    • Сжатие данных: Включение GZ на уровне базы данных для уменьшения объема.
    • ClickHouse: Колоночная база данных для аналитики и быстрых запросов.
    • Пул соединений: Увеличение количества соединений с БД для обработки большего числа параллельных запросов.
  • Что важно не забыть:
    • Индексы (по Client ID, по статусу).
    • Репликация (Master-Slave, балансировщик).
    • Шардирование/партиционирование.
    • Кэширование (Redis, CDN).
    • Оптимизация запросов (джоины, агрегации, вложенные запросы).
    • Оптимизация типов данных.
    • Сжатие данных.
    • ClickHouse.
    • Пул соединений.
  • Быстрый чек-лист ответа синьора:
    • Indexes (impact on read/write).
    • Replication (Master-Slave, read scaling).
    • Sharding/Partitioning (horizontal scaling).
    • Caching strategy (Redis).
    • Query optimization (join reduction, aggregation).
    • Data type optimization for storage.
  • Приоритет на собесе: Высокий
  • Сложность: Продвинутая
  • Уверенность в корректности (по материалам): 100%

ORM/ODM (Object-Relational/Document Mapper)​

  • Кратко: ORM (для реляционных баз, например, TypeORM) и ODM (для документо-ориентированных, например, Mongoose/Prisma) — это библиотеки, которые позволяют взаимодействовать с базами данных, используя объектно-ориентированные концепции языка программирования, без написания чистого SQL.
  • Почему спрашивают на собеседовании: Проверяет знание инструментов для работы с базами данных, понимание их преимуществ (безопасность, абстракция) и потенциальных недостатков (производительность).
  • Хитрости/подводные камни:
    • Безопасность: ORM/ODM помогают предотвратить SQL-инъекции, автоматически экранируя параметры.
    • Производительность: Иногда ORM/ODM могут быть медленнее, чем ручной SQL, но это часто является компромиссом ради удобства и безопасности.
    • "Сырой" SQL внутри ORM: Использование чистого SQL внутри ORM/ODM не рекомендуется, так как может отменить преимущества ORM по безопасности.
    • Миграции: ORM/ODM часто предоставляют инструменты для управления миграциями схем базы данных.
    • Привязка к ORM: Сильная привязка бизнес-логики к конкретному ORM может усложнить его замену.
  • Что важно не забыть:
    • Абстракция над базой данных.
    • Безопасность (SQL-инъекции).
    • Миграции.
    • Схемы/модели.
    • Примеры: Mongoose, TypeORM, Prisma.
    • Паттерн Репозиторий для изоляции.
  • Быстрый чек-лист ответа синьора:
    • Object-oriented interaction with DB.
    • SQL Injection prevention (prepared statements).
    • Schema definition and migrations.
    • Trade-offs (performance vs security/convenience).
    • Repository pattern for decoupling.
  • Приоритет на собесе: Высокий
  • Сложность: Базовая
  • Уверенность в корректности (по материалам): 100%

ACID (Атомарность, Согласованность, Изолированность, Долговечность)​

  • Кратко: Аббревиатура, описывающая набор свойств, гарантирующих надежность обработки транзакций в базах данных: Атомарность, Согласованность, Изолированность, Долговечность.
  • Почему спрашивают на собеседовании: Проверяет фундаментальное понимание транзакционной целостности данных, особенно в реляционных базах.
  • Хитрости/подводные камни:
    • Микросервисы и транзакции: Поддержание ACID-свойств в распределенных системах (микросервисах) — сложная задача, требующая использования паттернов вроде Saga или двухфазной фиксации (2PC).
    • Уровень изоляции: Влияет на производительность и согласованность данных при конкурентном доступе.
    • NoSQL и ACID: Многие NoSQL-базы изначально не поддерживали ACID полностью, жертвуя им ради масштабируемости (BASE-модель), хотя некоторые (например, MongoDB) теперь имеют транзакции.
  • Что важно не забыть:
    • Atomicity (все или ничего).
    • Consistency (целостность данных).
    • Isolation (независимость транзакций).
    • Durability (сохранность данных).
    • Важно для реляционных БД.
    • Сложно в микросервисах (Saga, 2PC).
  • Быстрый чек-лист ответа синьора:
    • Atomicity, Consistency, Isolation, Durability definitions.
    • Transaction reliability.
    • Microservices challenges (Saga, 2PC).
    • Isolation levels (read committed, repeatable read).
    • NoSQL vs ACID (BASE model).
  • Приоритет на собесе: Средний
  • Сложность: Базовая
  • Уверенность в корректности (по материалам): 100%

Architecture & Design Patterns

Масштабирование (Горизонтальное и Вертикальное)​

  • Кратко: Масштабирование — это способность системы увеличивать свою производительность или пропускную способность для обработки возрастающей нагрузки. Вертикальное масштабирование (scale up) — увеличение ресурсов одного сервера (CPU, RAM). Горизонтальное масштабирование (scale out) — добавление новых экземпляров серверов или сервисов.
  • Почему спрашивают на собеседовании: Понимание, как проектировать системы, способные выдерживать высокие нагрузки и расти вместе с бизнесом.
  • Хитрости/подводные камни:
    • Вертикальное масштабирование: Имеет физические ограничения по ресурсам.
    • Горизонтальное масштабирование: Требует балансировщиков нагрузки (load balancers) и оркестраторов (Kubernetes), а также решений для согласованности данных (репликация, шардирование).
    • Гибкость vs Масштабируемость: Гибкость — это возможность как увеличивать, так и уменьшать ресурсы пропорционально нагрузке.
    • Node.js и масштабирование: Node.js хорошо подходит для горизонтального масштабирования (благодаря Event Loop и неблокирующему I/O), но для CPU-intensive задач требуется вынос в воркеры или другие процессы.
  • Что важно не забыть:
    • Vertical (CPU, RAM).
    • Horizontal (add instances/replicas).
    • Load balancers.
    • Orchestrators (Kubernetes).
    • Replication/Sharding (for DB).
    • Node.js suitability (good for horizontal).
    • Flexibility vs Scalability.
  • Быстрый чек-лист ответа синьора:
    • Scale up vs Scale out.
    • Load balancing for horizontal.
    • Kubernetes (orchestration).
    • DB replication/sharding.
    • Worker Threads for vertical (CPU).
  • Приоритет на собесе: Высокий
  • Сложность: Продвинутая
  • Уверенность в корректности (по материалам): 100%

Микросервисная архитектура​

  • Кратко: Архитектурный подход, при котором большое приложение строится как набор слабосвязанных, независимо развертываемых сервисов, каждый из которых отвечает за свою конкретную бизнес-функцию.
  • Почему спрашивают на собеседовании: Проверяет знание современных архитектурных подходов, их преимуществ и сложностей.
  • Хитрости/подводные камни:
    • Транзакции: Сложности с поддержанием транзакционной целостности (ACID) между несколькими микросервисами, требующие паттернов Saga или двухфазной фиксации (2PC), которые могут иметь проблемы с производительностью и изолированностью.
    • Межсервисная коммуникация: Сетевые задержки, проблемы с доступностью сервисов, необходимость брокеров сообщений (Kafka).
    • Координация: Сложность координации развертывания, мониторинга и отладки множества сервисов.
    • Онбординг: Усложняет онбординг новых членов команды.
    • Node.js для микросервисов: Подходит для создания легких, масштабируемых REST API и модульных систем.
  • Что важно не забыть:
    • Слабосвязанные, независимо развертываемые сервисы.
    • Проблемы с распределенными транзакциями (Saga, 2PC).
    • Сетевые проблемы и доступность.
    • Брокеры сообщений (Kafka).
    • Подходит для Node.js.
  • Быстрый чек-лист ответа синьора:
    • Independent deployment/scaling.
    • Distributed transactions (Saga vs 2PC).
    • Inter-service communication challenges (network, availability).
    • Message brokers (Kafka).
    • Node.js suitability (lightweight REST APIs).
  • Приоритет на собесе: Высокий
  • Сложность: Продвинутая
  • Уверенность в корректности (по материалам): 100%

Принципы ООП (SOLID)​

  • Кратко: SOLID — это набор из пяти принципов объектно-ориентированного программирования (Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion), которые помогают создавать гибкий, расширяемый и поддерживаемый код.
  • Почему спрашивают на собеседовании: Проверяет способность писать качественный, легко тестируемый и модифицируемый код.
  • Хитрости/подводные камни:
    • Single Responsibility Principle (SRP): Один класс/модуль/сервис должен иметь только одну причину для изменения. Нарушение: большой endpoint, выполняющий множество несвязанных действий.
    • Dependency Inversion Principle (DIP): Модули высокого уровня не должны зависеть от модулей низкого уровня; оба должны зависеть от абстракций. Абстракции не должны зависеть от деталей; детали должны зависеть от абстракций.
    • Open/Closed Principle: Сущности (классы, модули, функции) должны быть открыты для расширения, но закрыты для модификации.
    • Liskov Substitution Principle (LSP): Дочерние классы должны быть полностью взаимозаменяемы с родительскими классами.
    • Interface Segregation Principle (ISP): Клиенты не должны зависеть от интерфейсов, которые они не используют.
  • Что важно не забыть:
    • SRP (одна причина для изменения).
    • OCP (открыт для расширения, закрыт для модификации).
    • LSP (заменяемость дочерними классами).
    • ISP (разделение интерфейсов).
    • DIP (зависимость от абстракций).
  • Быстрый чек-лист ответа синьора:
    • Define each SOLID principle.
    • Provide examples of violations.
    • Explain how to apply them in Node.js/JS.
    • Connect DIP to Dependency Injection.
    • Relate SRP to service decomposition.
  • Приоритет на собесе: Высокий
  • Сложность: Продвинутая
  • Уверенность в корректности (по материалам): 100%

Внедрение Зависимостей (Dependency Injection - DI)​

  • Кратко: DI — это паттерн, позволяющий framework’у или DI-контейнеру автоматически инстанцировать и предоставлять необходимые зависимости (сервисы, объекты) другим компонентам во время выполнения, вместо ручного создания этих зависимостей разработчиком.
  • Почему спрашивают на собеседовании: Проверяет знание инструментов для создания модульного, тестируемого и легко поддерживаемого кода.
  • Хитрости/подводные камни:
    • Неявные зависимости: Может затруднить понимание, какие зависимости используются, если нет четкого декларативного определения.
    • Overhead: Использование DI-контейнера может добавить небольшие накладные расходы на инициализацию. (не было в источниках, но важно для синьора).
    • "Бойлерплейт": В некоторых реализациях может требовать большего количества "шаблонного" кода. (не было в источниках, но важно для синьора).
  • Что важно не забыть:
    • Framework инжектирует зависимости.
    • Декларативный, а не императивный код.
    • Decoupled код.
    • Упрощает тестирование.
    • Принцип Dependency Inversion (SOLID).
    • Примеры: NestJS.
  • Быстрый чек-лист ответа синьора:
    • Mechanism of injecting services.
    • Decoupled code.
    • Declarative vs imperative.
    • Testability benefits.
    • Relation to DIP.
  • Приоритет на собесе: Высокий
  • Сложность: Продвинутая
  • Уверенность в корректности (по материалам): 100%

Паттерн Репозиторий (Repository Pattern)​

  • Кратко: Паттерн, который абстрагирует логику работы с хранилищем данных (например, базой данных) от бизнес-логики приложения. Сервис не должен "знать", с какой базой данных он взаимодействует.
  • Почему спрашивают на собеседовании: Проверяет способность создавать легко заменяемые, тестируемые и слабосвязанные компоненты, особенно в контексте работы с данными.
  • Хитрости/подводные камни:
    • Слой абстракции: Добавляет дополнительный слой, что может привести к небольшим накладным расходам по производительности и усложнению (не было в источниках, но важно для синьора).
    • Чрезмерное использование: Не всегда оправдано для простых CRUD-операций без сложной бизнес-логики. (не было в источниках, но важно для синьора).
    • Миграция баз данных: Упрощает смену СУБД (например, с MongoDB на PostgreSQL), так как изменения вносятся только в слой репозитория.
  • Что важно не забыть:
    • Абстракция логики работы с БД.
    • Сервис не знает тип БД.
    • Упрощает смену БД.
    • Decoupled код.
    • Улучшает тестируемость.
    • Использует внедрение зависимостей.
  • Быстрый чек-лист ответа синьора:
    • Abstracts data access logic.
    • Decouples business logic from DB implementation.
    • Facilitates DB migration.
    • Improves testability.
    • Uses DI.
  • Приоритет на собесе: Средний
  • Сложность: Продвинутая
  • Уверенность в корректности (по материалам): 100%

Транзакционная целостность (Transactional Integrity)​

  • Кратко: Гарантия того, что набор операций с данными либо будет выполнен полностью и успешно (commit), либо будет полностью отменен (rollback), если какая-либо часть операций завершится неудачно.
  • Почему спрашивают на собеседовании: Проверяет понимание критичности согласованности данных, особенно в финансовых или важных бизнес-операциях.
  • Хитрости/подводные камни:
    • Производительность: Чрезмерное использование транзакций с высокими уровнями изоляции может снизить производительность, особенно в высоконагруженных системах.
    • Микросервисы: Реализация распределенных транзакций в микросервисах очень сложна (Saga, 2PC).
    • Предсказуемое поведение пользователя: Обеспечивает, что действия пользователя либо полностью завершатся, либо полностью откатятся, предотвращая непредсказуемые состояния.
    • Критичность данных: Важно различать критичные данные (настройки пользователя, платежи) и некритичные (аналитика), для которых можно пожертвовать транзакционностью ради производительности.
  • Что важно не забыть:
    • Все или ничего (Atomicity).
    • commit/rollback.
    • Критичные операции (платежки, настройки).
    • Производительность (уровни изоляции).
    • Сложность в микросервисах.
    • Предсказуемое поведение для пользователя.
  • Быстрый чек-лист ответа синьора:
    • Atomicity principle (all or nothing).
    • commit/rollback.
    • Distributed transaction patterns (Saga, 2PC).
    • Performance trade-offs with isolation levels.
    • User experience consistency.
  • Приоритет на собесе: Средний
  • Сложность: Продвинутая
  • Уверенность в корректности (по материалам): 100%

Development Practices

Безопасность (SQLi, XSS, MITM, Аудит зависимостей)​

  • Кратко: Набор мер и практик для защиты приложения от различных угроз, включая инъекции (SQL Injection, XSS), атаки "человек посередине" (MITM) и уязвимости в сторонних зависимостях.
  • Почему спрашивают на собеседовании: Разработчик должен создавать безопасный код и понимать потенциальные угрозы.
  • Хитрости/подводные камни:
    • SQL Injection: Происходит, когда параметры запроса к БД не экранируются, что позволяет злоумышленнику внедрять свой SQL-код. Защита: ORM/ODM, prepared statements.
    • XSS (Cross-Site Scripting): Атака, при которой вредоносный скрипт внедряется в веб-страницу и исполняется в браузере пользователя. Может быть отложенной.
    • MITM (Man-in-the-Middle): Злоумышленник перехватывает и, возможно, изменяет коммуникацию между двумя сторонами. HTTPS снижает риск, но не исключает его полностью (например, поддельные сертификаты).
    • Уязвимости зависимостей: Сторонние пакеты могут содержать уязвимости (переполнение стека, утечки памяти, инъекции). npm audit помогает их находить.
    • Социальная инженерия: Часто является наиболее простым способом получения доступа. Защита: политики безопасности, разделение ролей, минимальный доступ к боевым данным.
    • HTTPS не панацея: Подделка сертификатов может позволить MITM-атаки.
  • Что важно не забыть:
    • SQL Injection (защита: ORM, Prepared Statements).
    • XSS (санитизация ввода, CSP).
    • MITM (защита: HTTPS, но есть нюансы).
    • npm audit (для зависимостей).
    • Политики безопасности, RBAC.
    • CSRF-токены.
  • Быстрый чек-лист ответа синьора:
    • SQLi (prevention: ORMs/prepared statements).
    • XSS (sanitization).
    • MITM (HTTPS, but aware of certificate issues).
    • Vulnerability scanning (npm audit).
    • Security policies and RBAC.
  • Приоритет на собесе: Высокий
  • Сложность: Продвинутая
  • Уверенность в корректности (по материалам): 100%

Тестирование (Unit, Integration, E2E, TDD/BDD)​

  • Кратко: Процесс проверки программного обеспечения на соответствие требованиям и обнаружение ошибок. Включает различные типы тестов (юнит, интеграционные, E2E), а также методологии (TDD, BDD).
  • Почему спрашивают на собеседовании: Проверяет способность писать надежный и поддерживаемый код, а также предотвращать регрессии.
  • Хитрости/подводные камни:
    • Сложность в JavaScript: Написание интеграционных тестов особенно важно в JavaScript, так как легко что-то сломать.
    • DI для тестирования: Внедрение зависимостей значительно упрощает тестирование, позволяя подменять реальные зависимости моками или тестовыми реализациями.
    • Мокирование: Использование моков или стабов для изоляции тестируемого компонента от его зависимостей (баз данных, внешних API).
    • Примитивность тестов: Часто тесты сводятся к проверке, что ручка возвращает ожидаемый ответ.
    • TDD/BDD: TDD (Test-Driven Development) — написание тестов до кода; BDD (Behavior-Driven Development) — фокусировка на поведении системы с точки зрения пользователя.
  • Что важно не забыть:
    • Unit, Integration, E2E тесты.
    • TDD/BDD методологии.
    • Мокирование/стабирование.
    • Внедрение зависимостей для тестируемости.
    • Важность интеграционных тестов в JS.
  • Быстрый чек-лист ответа синьора:
    • Types of tests (Unit, Integration, E2E).
    • TDD/BDD approaches.
    • Mocks/Stubs for dependencies.
    • DI for testability.
    • Importance of integration tests for JS.
  • Приоритет на собесе: Высокий
  • Сложность: Базовая
  • Уверенность в корректности (по материалам): 100%

Обработка ошибок и логирование​

  • Кратко: Механизмы для выявления, перехвата и реагирования на исключительные ситуации (ошибки) в приложении, а также для записи информации о событиях и ошибках (логирование).
  • Почему спрашивают на собеседовании: Проверяет способность создавать отказоустойчивые и диагностируемые приложения.
  • Хитрости/подводные камни:
    • Невалидные входные данные: Должны быть обработаны, возможно, с выбрасыванием кастомных исключений и возвратом соответствующих HTTP-статусов.
    • Кастомные классы исключений: Создание собственных классов исключений (например, AppException) позволяет централизованно управлять логированием, статусами HTTP и форматом ответа.
    • Логирование: Ошибки и важные события должны быть залогированы для последующего анализа и отладки.
    • try-catch блоки: Для перехвата и обработки исключений, особенно при работе с внешними данными.
    • Обработка rejection в промисах: Важно перехватывать ошибки в промисах, чтобы они не приводили к падению приложения.
  • Что важно не забыть:
    • try-catch.
    • Кастомные Exception классы.
    • Логирование.
    • HTTP-статусы ошибок.
    • Обработка невалидных данных.
    • Rejection в промисах.
  • Быстрый чек-лист ответа синьора:
    • Custom Exception classes (centralized handling).
    • Logging mechanisms.
    • try-catch for external input.
    • Mapping errors to HTTP status codes.
    • Promise rejection handling.
  • Приоритет на собесе: Средний
  • Сложность: Базовая
  • Уверенность в корректности (по материалам): 100%

Код ревью (Code Review)​

  • Кратко: Процесс систематической проверки исходного кода программы другими разработчиками с целью выявления ошибок, улучшения качества кода и обмена знаниями.
  • Почему спрашивают на собеседовании: Проверяет понимание важности коллективной работы, качества кода и непрерывного улучшения.
  • Хитрости/подводные камни:
    • Формализованные правила: Наличие свода правил для код-ревью помогает обеспечить единообразие и качество.
    • Фокус: На повторении кода, модульности, чистоте кода, именовании переменных и функций, соблюдении принципов Clean Code.
    • Время: Код-ревью может быть долгим, если не автоматизировано или нет четких правил (не было в источниках, но важно для синьора).
  • Что важно не забыть:
    • Улучшение качества кода.
    • Выявление ошибок.
    • Модульность.
    • Clean Code (чистота, наименования).
    • Свод правил.
  • Быстрый чек-лист ответа синьора:
    • Purpose: quality, error detection, knowledge sharing.
    • Key focus areas: modularity, naming, code duplication, clean code.
    • Defined rules/guidelines.
    • Constructive feedback.
  • Приоритет на собесе: Низкий
  • Сложность: Базовая
  • Уверенность в корректности (по материалам): 100%

Мониторинг (Prometheus, Grafana)​

  • Кратко: Мониторинг — это процесс сбора, анализа и визуализации метрик системы для отслеживания ее состояния, производительности и выявления проблем. Prometheus используется для сбора метрик, а Grafana для их визуализации.
  • Почему спрашивают на собеседовании: Проверяет знание инструментов для обеспечения стабильности и производительности продакшен-систем.
  • Хитрости/подводные камни:
    • Высокоуровневые метрики: Grafana и Prometheus могут собирать метрики на более высоком уровне, чем отдельные микротаски Event Loop. Для более глубокого анализа (профайлинга) требуются другие инструменты (Async Hooks).
    • Интеграция с фреймворками: Некоторые фреймворки (например, NestJS с prom-client) упрощают сбор метрик.
  • Что важно не забыть:
    • Сбор метрик (Prometheus).
    • Визуализация (Grafana).
    • Отслеживание состояния сервера.
    • NestJS integration (@nestjs/terminus).
    • Выявление проблем с производительностью.
  • Быстрый чек-лист ответа синьора:
    • Prometheus for metrics collection.
    • Grafana for visualization.
    • System health and performance.
    • Integration with frameworks (e.g., NestJS).
    • Complementary to profiling tools.
  • Приоритет на собесе: Низкий
  • Сложность: Продвинутая
  • Уверенность в корректности (по материалам): 90%

Профайлинг и Отладка Node.js​

  • Кратко: Процесс измерения и анализа производительности кода для выявления "узких мест" (bottlenecks), а также использования инструментов для пошагового выполнения кода и инспектирования состояния приложения во время выполнения.
  • Почему спрашивают на собеседовании: Проверяет способность разработчика оптимизировать код и эффективно диагностировать проблемы в продакшен-среде.
  • Хитрости/подводные камни:
    • Инструменты: DevTools Chrome (для flame chart, call stack), Async Hooks (для трассировки микротасок), нагрузочное тестирование.
    • Микротаски: Сложно отследить "автора" микротаски в Event Loop, так как в стеке вызовов отсутствует родительский контекст. Async Hooks решают эту проблему.
    • Не нагружая: Можно анализировать профиль приложения и Flame Chart в DevTools без запуска нагрузочного тестирования.
    • Утечки памяти: Профайлеры позволяют обнаружить, как сборщик мусора накапливает неочищаемые объемы памяти.
  • Что важно не забыть:
    • Выявление "узких мест".
    • DevTools (Flame Chart, Call Stack).
    • Async Hooks (трассировка микротасок).
    • Нагрузочное тестирование.
    • Утечки памяти.
  • Быстрый чек-лист ответа синьора:
    • Identify bottlenecks.
    • Chrome DevTools (Flame Charts).
    • Async Hooks (microtask tracing).
    • Load testing (for dynamic problems).
    • Memory leak detection.
  • Приоритет на собесе: Низкий
  • Сложность: Продвинутая
  • Уверенность в корректности (по материалам): 95%

JavaScript Fundamentals

Сборщик мусора (Garbage Collector)​

  • Кратко: Сборщик мусора в JavaScript — это автоматический процесс, который освобождает память, занимаемую объектами, на которые больше нет ссылок или которые недостижимы из глобального контекста.
  • Почему спрашивают на собеседовании: Понимание управления памятью, причин утечек памяти и оптимизации производительности.
  • Хитрости/подводные камни:
    • Циклические ссылки: Объекты, ссылающиеся сами на себя, будут удалены, если они недостижимы из глобального контекста (современные сборщики мусора умеют это).
    • Утечки памяти: Могут возникать из-за непреднамеренных сильных ссылок на объекты (например, забытые слушатели событий, глобальные переменные).
    • WeakMap/WeakSet: Могут использоваться для предотвращения утечек памяти, так как хранят слабые ссылки на объекты.
  • Что важно не забыть:
    • Автоматическое управление памятью.
    • Отсутствие ссылок/недостижимость из глобального контекста.
    • Heap (куча).
    • Циклические ссылки (GC справляется).
    • Утечки памяти.
    • WeakMap/WeakSet.
  • Быстрый чек-лист ответа синьора:
    • Automatic memory management.
    • Reachability from global context.
    • Reference counting (conceptual).
    • Circular references (handled by modern GC).
    • Memory leak causes.
    • WeakMap/WeakSet.
  • Приоритет на собесе: Средний
  • Сложность: Базовая
  • Уверенность в корректности (по материалам): 100%

Замыкания (Closures)​

  • Кратко: Замыкание — это функция, которая запоминает свое лексическое окружение (переменные из родительской функции), даже после того, как родительская функция завершила свое выполнение.
  • Почему спрашивают на собеседовании: Фундаментальное концепция JavaScript, используемая для инкапсуляции данных и создания приватных переменных.
  • Хитрости/подводные камни:
    • Утечки памяти: Если замыкание сохраняет ссылку на большой объект из внешнего скоупа, это может привести к утечкам памяти. (не было в источниках, но важно для синьора).
    • Потеря this: В старых реализациях. (не было в источниках, но важно для синьора).
  • Что важно не забыть:
    • Функция внутри функции.
    • Лексическое окружение.
    • Сохранение доступа к переменным родителя.
    • Создание приватных переменных (не было в источниках, но важно для синьора).
  • Быстрый чек-лист ответа синьора:
    • Function + lexical environment.
    • Access to outer scope variables.
    • Persistence after outer function execution.
    • Data encapsulation.
  • Приоритет на собесе: Средний
  • Сложность: Базовая
  • Уверенность в корректности (по материалам): 100%

Передача аргументов (по ссылке/значению) и неизменяемость строк​

  • Кратко: В JavaScript примитивы (строки, числа, булевы) передаются по значению, а объекты (массивы, объекты) — по ссылке. Строки в JavaScript являются неизменяемыми: любая операция, которая кажется изменением строки, на самом деле создает новую строку.
  • Почему спрашивают на собеседовании: Проверяет фундаментальное понимание поведения данных в JavaScript, что критично для предотвращения неожиданных побочных эффектов и оптимизации.
  • Хитрости/подводные камни:
    • Неожиданные мутации: Передача объекта по ссылке может привести к неожиданным изменениям в других частях кода, если не управлять мутабельностью.
    • Производительность строк: Частые операции конкатенации или "изменения" строк могут быть неэффективны, так как создаются новые строки.
    • Присваивание объектов: obj = newObj изменяет ссылку, а не мутирует объект по старой ссылке.
  • Что важно не забыть:
    • Примитивы: по значению (string, number, boolean).
    • Объекты: по ссылке (array, object, set, map).
    • Строки неизменяемы (immutable).
    • + или += для строк создают новую строку.
  • Быстрый чек-лист ответа синьора:
    • Primitives by value, Objects by reference.
    • Strings are immutable.
    • New string created on modification.
    • Implications for side effects and performance.
  • Приоритет на собесе: Средний
  • Сложность: Базовая
  • Уверенность в корректности (по материалам): 100%

Алгоритмы и Структуры Данных​

  • Кратко: Фундаментальные концепции информатики, описывающие способы организации данных (структуры) и пошаговые инструкции для решения задач (алгоритмы). Включают массивы, списки (связанные, двусвязные), стеки, очереди, деревья (AVL, лево/право дочерние), графы (ориентированные, невзвешенные, взвешенные). Оцениваются по временной и пространственной сложности (Big O Notation).
  • Почему спрашивают на собеседовании: Проверяет аналитическое мышление, способность решать проблемы эффективно и выбирать подходящие инструменты для оптимизации.
  • Хитрости/подводные камни:
    • Big O: Важно не только знать нотацию, но и уметь применять ее к реальным алгоритмам (N, N^2, N+N, константы).
    • Сложность доступа: Различные структуры данных имеют разную временную сложность для доступа (например, хэш-таблица O(1), массив O(N), связанный список O(N)).
    • Линейный поиск: Пример O(N) алгоритма.
  • Что важно не забыть:
    • Big O Notation (N, N^2, O(1)).
    • Массивы, списки, стеки, очереди.
    • Деревья (AVL, обходы).
    • Графы (ориентированные, взвешенные, кратчайший путь).
    • Оценка доступа по времени (хэш-таблица O(1)).
  • Быстрый чек-лист ответа синьора:
    • Big O notation (meaning, common complexities).
    • Define common data structures (Stack, Queue, Linked List, Tree, Graph).
    • Time complexity for access in different structures (Hash Table O(1), Array O(N)).
    • Tree traversal (BFS/DFS).
    • Graph algorithms (shortest path).
  • Приоритет на собесе: Средний
  • Сложность: Базовая
  • Уверенность в корректности (по материалам): 100%

Infrastructure

Docker и Kubernetes​

  • Кратко: Docker — это платформа для разработки, доставки и запуска приложений в контейнерах, которые инкапсулируют приложение и его зависимости. Kubernetes — это система оркестрации контейнеров, автоматизирующая развертывание, масштабирование и управление контейнерными приложениями.
  • Почему спрашивают на собеседовании: Проверяет знание современных инструментов для деплоя, управления и масштабирования приложений.
  • Хитрости/подводные камни:
    • Docker Compose: Инструмент для определения и запуска многоконтейнерных Docker-приложений.
    • Kubernetes (K8s): Позволяет настраивать реплики, гибко управлять связями между сервисами, горизонтально масштабировать.
    • Сложность: Kubernetes может быть сложным для настройки и управления.
    • Minikube: Облегченная версия Kubernetes для локальной разработки.
  • Что важно не забыть:
    • Docker (контейнеризация).
    • Kubernetes (оркестрация, масштабирование).
    • Реплики.
    • Docker Compose.
    • CI/CD интеграция (не было в источниках, но важно для синьора).
  • Быстрый чек-лист ответа синьора:
    • Containerization (Docker).
    • Orchestration (Kubernetes).
    • Replication and scaling in K8s.
    • kubectl (не было в источниках, но важно для синьора).
    • Docker Compose for local environments.
  • Приоритет на собесе: Средний
  • Сложность: Базовая
  • Уверенность в корректности (по материалам): 100%

Пропуски и белые пятна​

Перечисленные ниже темы не были подробно освещены в предоставленных видеоматериалах, но часто встречаются на собеседованиях по Node.js, особенно на позиции уровня Senior.

  1. Управление конфигурацией (Environment Variables, dotenv): Важность использования и безопасного хранения переменных окружения для различных сред (разработка, тестирование, продакшен). Отсутствие этой темы оставляет пробел в понимании развертывания приложений.
  2. Обработка файлов (File Uploads): Работа с загрузкой файлов на сервер является очень распространенной задачей в веб-разработке. Отсутствие обсуждения таких библиотек, как Multer, или подходов к потоковой обработке файлов при загрузке.
  3. Автоматизация задач (Cron Jobs): Хотя упоминались "background jobs" и "Worker Threads", конкретные решения для планирования периодических задач (cron jobs) или использования библиотек типа node-cron не были затронуты.
  4. Безопасность: Rate Limiting / DoS Protection: Обсуждались DoS-атаки, но не было конкретных технических решений для их предотвращения, таких как Rate Limiting, CORS.
  5. ORM: Lazy vs Eager Loading: Важный аспект производительности при работе с ORM, который влияет на количество запросов к базе данных и может быть причиной неэффективности.
  6. Микросервисы: Service Discovery, API Gateway: Несмотря на обсуждение микросервисов, ключевые элементы инфраструктуры, такие как механизмы обнаружения сервисов (Service Discovery) и единые точки входа (API Gateway), не были упомянуты.
  7. CI/CD (Continuous Integration/Continuous Delivery): Процессы автоматизации сборки, тестирования и развертывания кода являются неотъемлемой частью современного процесса разработки, но не были затронуты.
  8. Type-checking (TypeScript): Хотя в резюме одного из кандидатов упоминался TypeScript, углубленное обсуждение его роли в Node.js проектах, специфических для TS проблем (например, any, unknown, type guards, utility types, TS-ESLint), не проводилось.
  9. Оптимизация производительности: Caching Headers / ETag: Эффективное использование HTTP-заголовков для кэширования на стороне клиента (Cache-Control, ETag, Last-Modified) для снижения нагрузки на сервер и улучшения пользовательского опыта.
  10. Отладка: debugger и профилирование памяти: Несмотря на упоминание профайлинга, не было конкретных примеров использования debugger или инструментов для глубокого анализа утечек памяти (например, heap dump).
  11. Управление версиями (Git Workflow): Обсуждение стандартных рабочих процессов с Git (например, Git Flow, Trunk-based development), которое часто является частью собеседования на senior-позиции.
  12. gRPC: Упоминался RPC, но gRPC как современная высокопроизводительная реализация для межсервисной коммуникации не была рассмотрена в сравнении с REST/GraphQL.