Вопросы для собеседования backend-разработчика на Node.js

Что хотим услышать

• var с функциональной областью, let и const с блочной
• var поднимается с undefined, let/const попадают в TDZ
• var можно объявить повторно, let/const нет
• const запрещает переприсваивание, но не изменение объекта
• var на верхнем уровне скрипта становится свойством window
• По умолчанию const, let для изменяемых, var не использую

Если ответил, копните глубже

Что хотим услышать

• any выключает проверку в обе стороны: на нём можно вызвать что угодно и присвоить его куда угодно
• any заразен: свойства и результаты вызовов на нём тоже any, ошибка уходит далеко от источника
• Замена для неизвестных данных: unknown с сужением или валидацией
• Замена для «любого, но одного и того же»: дженерик
• Защита: noImplicitAny в strict и правило линтера no-explicit-any

Если ответил, копните глубже

Что хотим услышать

• Колбэки error-first: просто, но вложенность и легко потерять ошибку
• Промисы: цепочки, единая обработка ошибок, комбинаторы all/allSettled/race/any
• async/await: синтаксис над промисами, код читается как синхронный, try/catch
• await приостанавливает только свою функцию, продолжение идёт микрозадачей
• async-функция всегда возвращает промис
• util.promisify и промис-версии модулей (fs/promises)

Если ответил, копните глубже

Что хотим услышать

• WHERE фильтрует строки до группировки, HAVING фильтрует группы после
• В WHERE нельзя агрегаты, в HAVING можно
• Порядок: FROM, WHERE, GROUP BY, HAVING, SELECT
• Условия без агрегатов лучше писать в WHERE: меньше строк до группировки
• Пример: WHERE status = 'paid' и HAVING SUM(total) > 10000

Если ответил, копните глубже

Что хотим услышать

• Same-origin policy: скрипт не может читать ответы другого origin (схема, хост, порт)
• CORS: сервер заголовками Access-Control-Allow-* разрешает конкретным origin читать ответы
• Проверяет браузер, сервер отвечает всегда; вне браузера CORS не действует
• Простые запросы уходят сразу, остальные после preflight OPTIONS
• С куками нужен credentials: 'include', Allow-Credentials: true и точный origin вместо *

Если ответил, копните глубже

Что хотим услышать

• Вертикальное: мощнее машина, код не меняется, есть предел и единая точка отказа
• Горизонтальное: больше узлов, нужен stateless или распределённое состояние
• Stateless-сервисы приложения масштабируют горизонтально в первую очередь
• БД часто сначала масштабируют вертикально и репликами, шардирование позже
• Горизонтальное даёт отказоустойчивость, но добавляет сложность

Если ответил, копните глубже

Что хотим услышать

• Называет, что такое n (и m, если входов несколько)
• Считает циклы: вложенные перемножаются, последовательные складываются
• Помнит скрытые циклы: includes, indexOf, slice, sort, spread
• Отдельно оценивает память, включая стек рекурсии
• Сравнивает с ограничениями: при n до 10⁵ O(n²) уже не годится

Если ответил, копните глубже

Что хотим услышать

• граф зависимостей от точки входа
• трансформация: TS, JSX, современный синтаксис, CSS
• резолв пакетов из node_modules
• склейка в чанки, минификация, tree shaking
• хеши в именах для долгого кеша
• dev-сервер с HMR и source maps

Если ответил, копните глубже

Что хотим услышать

• Жёсткая ссылка: ещё одно имя того же inode, равноправное с оригиналом
• Данные живут, пока счётчик ссылок больше нуля и файл никто не держит открытым
• Жёсткую нельзя на каталог и между разными ФС
• Символьная: отдельный файл, внутри которого путь к цели
• Символьная ломается при удалении или переносе цели, зато работает с каталогами и через ФС
• Пример: symlink на текущий релиз current -> releases/42 для атомарного переключения

Если ответил, копните глубже

Что хотим услышать

• Две-три стороны, а не список из десяти
• Каждая подкреплена примером
• Стороны связаны с вакансией
• Нет пустых слов вроде «стрессоустойчивый, коммуникабельный» без доказательств
• Уверенно, без хвастовства

Если ответил, копните глубже

Что хотим услышать

• AbortController создаёт signal, который передаётся в fetch
• controller.abort() отклоняет промис ошибкой AbortError
• AbortError нужно отличать от настоящей ошибки при обработке
• в React отмена идёт в функции очистки useEffect
• без отмены получаем гонку: ответ на старый запрос перезаписывает новый
• один signal можно передать нескольким запросам сразу

Если ответил, копните глубже

Что хотим услышать

• Оба описывают форму объекта и в большинстве случаев взаимозаменяемы
• Только interface сливается при повторном объявлении (declaration merging), это нужно для расширения чужих типов
• Только type описывает объединения, кортежи, условные и mapped-типы, псевдонимы примитивов
• Расширение: extends у interface против пересечения &; конфликт полей при extends даёт ошибку, при & поле становится never
• Осознанное правило команды: например interface для публичных объектных контрактов, type для всего остального

Если ответил, копните глубже

Что хотим услышать

• async function*, внутри цикл по страницам с await fetch
• yield* по элементам страницы или yield поштучно
• Условие остановки: нет курсора next или пустая страница
• Ленивость: следующая страница грузится только когда потребитель дошёл до конца текущей
• Досрочный break у потребителя завершает генератор, запросы прекращаются; finally для очистки
• Ошибки и отмена: try/catch у потребителя, AbortSignal в параметрах

Если ответил, копните глубже

Что хотим услышать

• Голый параметр в T extends U даёт распределение по членам объединения
• На этом построены Exclude, Extract, NonNullable
• never как пустое объединение даёт never в результате
• Отключение: [T] extends [U], нужно для IsNever и проверок всего объединения
• Распределение срабатывает только для параметра типа, а не для конкретного объединения, записанного прямо в условии

Если ответил, копните глубже

Что хотим услышать

• Middleware: низкоуровневое, до роутинга (логирование, cors, raw body), как в Express
• Guards: решение «пускать или нет» (аутентификация, роли), имеют ExecutionContext и метаданные хендлера
• Interceptors до хендлера и после: трансформация ответа, тайминги, кеш, таймауты (RxJS вокруг вызова)
• Pipes: валидация и преобразование аргументов (ValidationPipe, ParseIntPipe)
• Хендлер контроллера вызывает сервисы; исключения ловят Exception filters и превращают в ответ
• Порядок уровней: глобальные, потом контроллера, потом метода

Если ответил, копните глубже

Что хотим услышать

• UPDATE создаёт новую версию строки, старая остаётся с xmax; DELETE только помечает версию
• Каждая транзакция видит версии по своему снимку, поэтому чтение не блокирует запись и наоборот
• VACUUM удаляет версии, которые уже никому не видны, обновляет visibility map и замораживает старые строки
• Долгие транзакции и забытые слоты репликации мешают очистке и раздувают таблицы
• Autovacuum настраивают по таблицам: autovacuum_vacuum_scale_factor, лимиты стоимости; мониторинг через pg_stat_user_tables
• HOT-обновления и fillfactor уменьшают нагрузку на индексы

Если ответил, копните глубже

Что хотим услышать

• Реконнект с экспоненциальной задержкой и джиттером, сброс задержки после успеха
• Heartbeat: ping/pong с таймаутом, при пропуске закрыть и переподключиться
• Нумерация сообщений: после реконнекта клиент сообщает последний id, сервер досылает пропущенное
• Очередь исходящих сообщений с клиентскими id, идемпотентность на сервере против дублей
• Реакция на online/offline и видимость вкладки, повторная авторизация при истёкшем токене

Если ответил, копните глубже

Что хотим услышать

• Требования: личные и групповые чаты до 1 000 участников, доставка онлайн и офлайн (push), история, статусы «доставлено» и «прочитано»; порядок сообщений в чате; медиа и сквозное шифрование вне рамок
• Оценка нагрузки: 50 млн DAU по 40 сообщений ≈ 2 млрд в сутки ≈ 20 000 RPS записи, в пике ~60 000; 10 млн одновременных соединений, ~100 000 на gateway → ~100 gateway; 2 млрд × 200 байт ≈ 400 ГБ в сутки, ~150 ТБ в год без реплик
• API: WebSocket: send {chat_id, client_msg_id, text}, ack {msg_id}, события new_message, read; HTTP: GET /chats/{id}/messages?before=...
• Данные: чаты и участники в PostgreSQL, сообщения в Cassandra/ScyllaDB с ключом партиции chat_id и сортировкой по msg_id, реестр user_id → gateway в Redis с TTL
• Компоненты: gateway-серверы с соединениями, сервис сообщений (сохранить, присвоить id, разослать), сервис присутствия, push-сервис для офлайн, очередь для фан-аута в группах
• Узкие места: большие группы (фан-аут через очередь), дубли при переотправке (client_msg_id для идемпотентности), переподключения и догрузка пропущенного, горячие чаты, падение gateway

Если ответил, копните глубже

Что хотим услышать

• начать с самого рискованного и ценного для бизнеса: оплата, вход, ключевые сценарии
• несколько e2e smoke-тестов на критичные пути
• unit-тесты на чистую логику: расчёты, форматирование, утилиты
• интеграционные тесты компонентов и API на новых и изменяемых местах
• тесты в CI как обязательная проверка PR
• регрессионный тест на каждый найденный баг, борьба с флаки

Если ответил, копните глубже

Что хотим услышать

• Воспроизвести и уточнить симптом: таймаут, refused, ошибка TLS, 5xx
• DNS: dig +short, правильный ли IP, не истёк ли домен
• Сеть и порт снаружи: curl -v, nc -zv host 443; refused или timeout
• На сервере: слушает ли процесс и на каком адресе (ss -tlnp), отвечает ли локально
• Фаервол на хосте и в облаке, балансировщик и его health checks
• Логи прокси и приложения, сертификат и его срок

Если ответил, копните глубже

Что хотим услышать

• Назван масштаб: команда, нагрузка, пользователи или деньги
• Есть решения, которые повлияли дальше своего кода
• Есть метрики результата
• Упомянуто влияние на команду: менторинг, процессы, ревью
• Уложился в 2 минуты, не утонул в деталях

Если ответил, копните глубже

Что хотим услышать

• Воспроизвести сценарий и подтвердить рост: Performance с Memory, ступенчатый рост после сборок
• Сузить до действия: какие переходы или операции увеличивают память
• Heap snapshots до и после серии повторов, Comparison, Retainers
• Проверить типичные причины: подписки, таймеры, detached DOM, глобальные кеши, сторы
• Исправить и проверить тем же сценарием, добавить защиту: лимиты кешей, линтер на очистку эффектов
• Мониторинг в проде: performance.memory или measureUserAgentSpecificMemory выборочно

Если ответил, копните глубже

Что хотим услышать

• T extends U ? X : Y вычисляется на уровне типов, для обобщённого T откладывается до подстановки
• Распределение: голый параметр с union применяется к каждому члену; отключается обёрткой [T]
• never как пустое объединение даёт never в распределительном типе
• infer объявляет переменную типа в шаблоне: ReturnType, Awaited, разбор строк
• Прикладные примеры: тип ответа API по пути, извлечение параметров маршрута, Extract/Exclude

Если ответил, копните глубже

Что хотим услышать

• Сначала измерить: метрики задержки, event loop lag, CPU, память, узкое место (БД, внешний API, CPU)
• Если CPU и блокировки цикла: профилирование (--cpu-prof, clinic), вынос тяжёлого в воркеры
• Сделать сервис stateless и масштабировать репликами
• База часто узкое место: индексы, пул соединений, реплики на чтение, кеш
• Кеш и очереди для тяжёлых и необязательных операций
• Нагрузочное тестирование (k6, autocannon) до и после

Если ответил, копните глубже