Вернуться в видеотеку

СОБЕС НА ТИМЛИДА NODEJS В ПРОФИРУ НА 340.000 РУБ

Техническое собеседование на Team Lead Node.js в Profi.ru с разбором legacy-кода сервиса пользовательских настроек. Основной акцент — на безопасности, производительности MongoDB, согласованности данных и архитектурной декомпозиции.

Источник: КИРИЛЛ ПОЗДНЯКОВ | ДЖАВАСКРИПТИЗЕРЫ

Открыть на YouTube

Таймлайн

Коротко о видео

Запись разбора собеседования на позицию 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-эндпоинта полезно выделить проверку статуса, обновление настроек, отправку аналитики, получение сессий и отзывов в отдельные функции или сервисы, а доступ к БД скрыть за репозиторием и внедрением зависимостей.

Рекомендуем посмотреть