Backend-разработчику на Node.js для первой работы нужно знать: JavaScript и TypeScript на глубоком уровне, устройство Node.js и event loop, SQL, транзакции и индексы в PostgreSQL, один фреймворк - чаще всего NestJS, основы асинхронной архитектуры и брокеров сообщений, Docker и тестирование. Ниже - роадмап по этим темам в порядке изучения и с тем, что по каждой спрашивают на собеседовании.
Путь в backend на Node.js длиннее, чем во frontend: помимо языка нужно разбираться в базах данных, архитектуре и инфраструктуре. Этот роадмап - последовательность тем, которые встречаются на собеседованиях и в первые месяцы работы.
0. JavaScript и асинхронность
Прежде чем переходить к Node.js, язык должен быть освоен глубоко: замыкания, прототипы, контекст this, промисы, async/await, обработка ошибок в асинхронном коде. На backend ошибка, пропущенная в промисе, может уронить весь процесс, поэтому понимание того, как распространяются исключения, - не теория, а практика.
1. Node.js изнутри
- Event loop: фазы, микро- и макрозадачи, почему блокирующий код опасен.
- CommonJS и ES Modules, организация кода.
- Потоки (Streams) и работа с файлами, буферы.
- Child processes и worker threads - когда нужны.
- Профилирование CPU и памяти.
Почему Node.js однопоточный и при этом быстрый
Классический вопрос. Хороший ответ: JavaScript-код выполняется в одном потоке, но операции ввода-вывода - сеть, файлы, база данных - выполняются асинхронно силами системы и пула потоков libuv. Пока запрос ждёт ответа базы, event loop обрабатывает другие запросы. Поэтому Node.js хорошо справляется с большим числом одновременных соединений, но плохо - с тяжёлыми вычислениями в основном потоке.
Что делать с тяжёлыми вычислениями
Если обработчик запроса долго считает, весь сервер перестаёт отвечать. Решения: вынести вычисления в worker threads, в отдельный сервис или в фоновую очередь задач. Умение распознать блокирующий код и объяснить последствия - один из признаков, по которым отличают понимание от заучивания.
Streams
Потоки позволяют обрабатывать данные частями, не загружая их целиком в память: чтение большого файла, загрузка на сервер, проксирование ответа. Стоит понимать виды потоков, backpressure и функцию pipeline, которая корректно обрабатывает ошибки и закрывает ресурсы.
2. TypeScript на сервере
Строгая типизация, дженерики для абстракций, декораторы и метаданные, настройка tsconfig, типизация работы с базой данных и валидация входных данных. Важный момент: типы TypeScript исчезают при запуске, поэтому данные, пришедшие извне, - тело запроса, параметры, ответы других сервисов - нужно проверять в рантайме через валидацию, например class-validator или Zod.
3. Базы данных и SQL
- ACID и уровни изоляции транзакций.
- Нормализация и когда от неё отступают.
- Индексы: B-tree, составные, покрывающие; почему индекс может не использоваться.
- EXPLAIN и оптимизация медленных запросов.
- Репликация и шардинг - на уровне понимания.
Транзакции и изоляция
Спрашивают, что такое транзакция и зачем она нужна, какие аномалии бывают при параллельной работе - грязное чтение, неповторяющееся чтение, фантомы - и какие уровни изоляции от них защищают. Практический пример: списание баланса и создание заказа должны выполняться в одной транзакции, иначе при сбое между ними данные разойдутся.
Индексы
Нужно понимать, как индекс ускоряет поиск, почему он замедляет запись, как работает составной индекс и почему порядок колонок в нём важен. Частый вопрос - почему индекс есть, а запрос всё равно медленный: функция над колонкой в условии, неподходящий порядок колонок, низкая селективность. Отвечать помогает умение читать вывод EXPLAIN.
Проблема N+1
Классическая ошибка при работе через ORM: загрузили список из ста записей, а потом для каждой отдельным запросом подгрузили связанные данные. Получилось сто один запрос вместо одного-двух. Решения - JOIN, пакетная загрузка, явное указание связей в запросе. Этот вопрос хорошо показывает, смотрели ли вы, какие запросы на самом деле уходят в базу.
SQL и NoSQL
Стоит понимать, когда реляционная база - естественный выбор (связанные данные, транзакции, сложные запросы), а когда уместны документные или key-value хранилища. Redis часто спрашивают как кеш и хранилище сессий: что такое TTL, как инвалидировать кеш и почему кеширование добавляет сложности с согласованностью данных.
4. Фреймворк: NestJS
Модули, контроллеры и провайдеры, внедрение зависимостей, guards, pipes и interceptors, валидация. NestJS задаёт структуру приложения и облегчает переход к микросервисам, GraphQL и WebSockets.
Что спрашивают по NestJS
- Как работает внедрение зависимостей и зачем оно нужно для тестирования.
- Порядок выполнения middleware, guards, interceptors и pipes при обработке запроса.
- Как организовать авторизацию: JWT, стратегии, проверка ролей через guard.
- Как обрабатывать ошибки централизованно через exception filters.
- Как разделить приложение на модули и избежать циклических зависимостей.
5. API и безопасность
Принципы REST: ресурсы, методы, коды ответа, идемпотентность, пагинация и версионирование. Понимание, чем GraphQL отличается от REST и когда он оправдан. Базовая безопасность: хеширование паролей, защита от SQL-инъекций, проверка прав доступа на каждом эндпоинте, ограничение частоты запросов, хранение секретов в переменных окружения, а не в коде.
6. Асинхронная архитектура
Event-driven подход, Pub/Sub, очереди сообщений. Kafka, RabbitMQ и NATS: чем отличаются, какие гарантии доставки дают, как обрабатывать ошибки и повторы.
Для первой работы достаточно понимать, зачем вообще нужна очередь: чтобы не выполнять долгие операции внутри HTTP-запроса, сгладить пики нагрузки и развязать сервисы. Отправка писем, генерация отчётов, обработка изображений - типичные примеры фоновых задач. Полезно знать понятия «at least once» и идемпотентная обработка: если сообщение может прийти дважды, обработчик должен это пережить.
7. Контейнеры и деплой
Docker: образы, тома, сети, хороший Dockerfile; Docker Compose для локального окружения; основы CI/CD и развёртывание на VDS. Хороший Dockerfile использует многоэтапную сборку, не тащит в финальный образ исходники и dev-зависимости и не хранит секреты. Kubernetes на junior-позиции обычно достаточно знать на уровне понятий: под, деплоймент, сервис.
8. Тестирование
Unit-тесты на Jest или Vitest с моками, интеграционные и e2e-тесты, нагрузочное тестирование и осмысленное покрытие. На собеседовании спрашивают, что вы тестируете и почему: бизнес-логику - unit-тестами, работу с базой и API - интеграционными тестами на настоящей базе в контейнере, а не на моках всего подряд.
9. Логирование и наблюдаемость
Структурированные логи вместо разрозненных сообщений, уровни логирования, корреляция запросов по идентификатору, базовые метрики и health-check эндпоинты. В продакшене вы не сможете поставить точку останова, и хорошие логи - единственный способ понять, что произошло.
10. Git и командная работа
В команде код проходит через ветки, пул-реквесты и ревью. Нужно уверенно работать с ветками, делать rebase, разрешать конфликты, писать осмысленные сообщения коммитов и понимать, зачем нужен CI, который запускает линтер и тесты до слияния. Умение принимать замечания на ревью и аргументированно отвечать на них ценится не меньше, чем знание фреймворка.
Что спрашивают на собеседовании backend-разработчика
- Как работает event loop и в каком порядке выполнятся setTimeout, setImmediate, process.nextTick и промисы.
- Что произойдёт с сервером, если в обработчике запроса выполнить долгий синхронный цикл.
- Как устроена аутентификация на JWT, где хранить токены и как их отзывать.
- Чем отличаются уровни изоляции транзакций и какой используется в PostgreSQL по умолчанию.
- Как найти и ускорить медленный запрос.
- Как сделать повторную обработку сообщения из очереди безопасной.
- Как устроено внедрение зависимостей в NestJS.
- Что должно быть в Dockerfile для продакшена.
Кроме вопросов, часто дают практическое задание: спроектировать схему базы данных для небольшого сервиса, написать SQL-запрос или эндпоинт с валидацией. На таких задачах важно проговаривать решения так же, как на лайвкодинге: почему такие таблицы, где индексы, что будет при росте данных.
Типичные ошибки при изучении backend
- Учить много фреймворков поверхностно вместо одного глубоко.
- Пропускать SQL, полагаясь на ORM.
- Строить микросервисы в учебном проекте, где хватило бы монолита.
- Не писать тесты, потому что «это учебный проект».
- Не запускать проект в Docker и не пробовать развернуть его на сервере.
В каком порядке учить
- Язык, асинхронность и устройство Node.js.
- SQL и PostgreSQL: запросы, транзакции, индексы.
- Фреймворк и REST API с авторизацией и валидацией.
- Docker и Docker Compose для запуска проекта целиком.
- Тесты на ключевую логику и интеграцию с базой.
- Очереди, кеш и архитектура - по мере роста проекта.
Сначала - язык, Node.js и SQL: без них остальное не держится. Затем фреймворк и проект, в котором всё это используется вместе. Архитектуру, брокеры и инфраструктуру добавляйте по мере роста проекта, а не заранее.
Как понять, что вы готовы к собеседованию
- Можете объяснить event loop и предсказать порядок выполнения асинхронного кода.
- Пишете SQL-запросы с JOIN, группировкой и подзапросами без подсказок.
- Понимаете транзакции и можете объяснить, где они нужны в вашем проекте.
- Ваш проект запускается одной командой через Docker Compose и покрыт тестами на ключевую логику.
- Можете рассказать, как устроена авторизация в вашем проекте и почему именно так.
Если большинство пунктов выполнено, пора откликаться: реальные собеседования покажут, какие темы нужно подтянуть, точнее любого списка.
Не ждите, пока освоите Kafka, Kubernetes и распределённые системы: от junior-разработчика этого обычно не требуют. Гораздо важнее уверенно владеть базой и показать проект, в котором она применена аккуратно и осмысленно.
Чем backend на Node.js отличается от других стеков
Главное преимущество Node.js - один язык на клиенте и сервере: frontend-разработчику проще перейти в backend, а команде - делиться кодом, например типами и схемами валидации. Ограничения тоже нужно понимать: для тяжёлых вычислений основной поток не подходит, а экосистема пакетов требует внимательного выбора зависимостей и регулярных обновлений. На собеседовании могут спросить, в каких задачах вы бы выбрали Node.js, а в каких - другой стек, и зрелый ответ учитывает обе стороны.
Где брать практику
Официальная документация Node.js, PostgreSQL и NestJS - лучший источник для глубокого понимания: там описаны механизмы, а не только примеры. Для SQL полезно решать задачи на запросы к готовым учебным базам. Для архитектуры - читать код открытых проектов на NestJS и разбирать, как в них устроены модули, обработка ошибок и работа с базой. И главное - развивать собственный проект, добавляя в него по одной новой теме из роадмапа.
Проект, который закрывает роадмап
Лучше всего темы закрепляются в одном проекте, который постепенно растёт. Например, API сервиса бронирования или учёта задач: пользователи и роли, связанные сущности в PostgreSQL, транзакции там, где они нужны, валидация, миграции, тесты, Docker Compose для запуска и фоновая очередь для уведомлений. На собеседовании такой проект даёт материал для ответа почти на любой вопрос: «а как у вас это было сделано и почему».
Если вы идёте в backend из frontend, пригодится и статья как найти первую работу frontend-разработчиком: принципы резюме, проектов и воронки откликов общие для обоих направлений. Отдельно стоит подготовиться к лайвкодингу.
На менторстве этот путь проходит на реальном проекте на NestJS. Подробнее - на странице трека Backend на Node.js.