Техническое собеседование на Team Lead Node.js в Profi.ru с разбором legacy-кода сервиса пользовательских настроек. Основной акцент — на безопасности, производительности MongoDB, согласованности данных и архитектурной декомпозиции.
Запись разбора собеседования на позицию Team Lead Node.js в Profi.ru: кандидат последовательно ищет проблемы в условном legacy-обработчике настроек пользователя. Обсуждаются SQL-инъекции и ORM, валидация входных DTO, индексы и агрегации MongoDB, хранение многотерабайтных данных, транзакции, HTTP-статусы, аутентификация и декомпозиция сервиса. Автор сообщает, что собеседование было успешным и после него был офер, но это его собственное утверждение.
При аудите Node.js-кода сначала проверяйте небезопасные SQL-запросы: не подставляйте значения строковой конкатенацией, используйте параметризованные запросы или ORM.
Входные данные из body и query нужно валидировать на границе приложения до JSON.parse и бизнес-логики; для NestJS уместны DTO с class-validator, также обсуждаются Zod и Joi.
Для большой MongoDB-коллекции связывайте запрос с индексируемым ClientID, а затем фильтруйте по status в aggregation pipeline; реплики и масштабирование не заменяют отсутствующий индекс или плохой план запроса.
Разделяйте критичность операций: потеря аналитического события может быть допустима, а несохранённые пользовательские настройки — нет; необходимость транзакции определяется ожидаемой атомарностью для пользователя.
При пакетном обновлении настроек заранее определяйте сценарий частичного успеха: либо явно допускайте его, либо выполняйте изменения транзакционно с rollback.
Не передавайте пароль или иной секрет в query-параметрах; на собеседовании полезно отдельно объяснить назначение query и body, риски URL-логов и роль HTTPS.
Для legacy-эндпоинта полезно выделить проверку статуса, обновление настроек, отправку аналитики, получение сессий и отзывов в отдельные функции или сервисы, а доступ к БД скрыть за репозиторием и внедрением зависимостей.