Какой опыт работы с JavaScript
Что проверяют
Зачем DevOps-инженеру JavaScript: хотят понять, можете ли вы читать и чинить Node.js-сервисы, которые деплоите, и писать на нём автоматизацию, если в команде это основной язык. Следом обычно спрашивают про запуск Node.js в контейнере или про сервис, который падает по памяти.
Как отвечать
Честно назовите уровень и привяжите его к инфраструктурным задачам:
- сборка и CI:
npm ciпо lock-файлу вместоnpm install, кэш зависимостей в GitHub Actions или GitLab CI,npm audit, Dependabot или Renovate; - контейнеры: многоэтапный Dockerfile, в финальном образе только прод-зависимости (
npm ci --omit=dev), запуск не от root. Процессnodeпод PID 1 сам не завершается поSIGTERM, поэтому нуженtiniилиdocker run --initплюс свой обработчик сигнала; - рантайм: актуальные LTS-ветки Node.js 22 и 24, лимит кучи через
--max-old-space-size, согласованный с лимитом памяти контейнера; - автоматизация: скрипты на Node.js для API облака, собственные GitHub Actions на JavaScript, инфраструктура на Pulumi или AWS CDK с TypeScript;
- асинхронность: event loop и то, почему синхронный
fs.readFileSyncв обработчике запроса блокирует весь процесс.
Приведите один свой пример: какой скрипт или сервис, что он делал, что в нём ломалось. Если JavaScript вы в основном читали, а автоматизацию писали на Python или Bash, так и скажите: «разбираюсь в Node.js-приложениях на уровне сборки, запуска и отладки, автоматизацию пишу на Python». Для DevOps это нормальный ответ.
Где спотыкаются
Рассказывают про фронтенд, которым не занимались, или путают JavaScript с Java. Интервьюера интересует, как вы эксплуатируете и автоматизируете.
Не знают, почему контейнер с Node.js останавливается ровно десять секунд при docker stop. Процесс под PID 1 не получает действия по умолчанию для сигналов, и Docker добивает его через SIGKILL по таймауту.
Рассчитывают, что размер кучи сам подстроится под контейнер. Он не обязан совпадать с лимитом cgroup, и процесс убивает OOM killer без понятной ошибки в логе, поэтому лимит задают явно.