Был ли в команде отдельный специалист по DevOps
Что проверяют
За простым вопросом прячутся два. Первый: насколько вы самостоятельны с тем, что происходит после мержа, от сборки до выкладки. Второй: впишетесь ли вы в команду, где выделенного DevOps может не быть вовсе. Следом почти всегда спрашивают, что в пайплайне вы настраивали своими руками.
Как отвечать
Ответ строится на вашем реальном опыте, поэтому подставьте свои детали. Каркас такой:
- устройство команды: был ли выделенный инженер, общая платформенная команда на несколько продуктов или инфраструктурой занимались сами разработчики;
- ваша зона: что делали вы. Для фронтенда это обычно конфиг CI в GitHub Actions или GitLab CI (линтер, тесты, сборка),
Dockerfileс многоэтапной сборкой и nginx для раздачи статики, переменные окружения, которые вшиваются в бандл на этапе сборки, загрузка source maps в Sentry, preview-окружения для веток; - взаимодействие: что вы передавали DevOps и в каком виде. Например, правило
try_files $uri /index.htmlдля SPA, заголовки кэширования отдельно для файлов с хэшем в имени и дляindex.html, список новых переменных; - результат: один конкретный эпизод. Скажем, сборка шла 12 минут, вы включили кэш зависимостей, и она стала идти 4. Цифры берите только свои.
Если DevOps был и вы в инфраструктуру не лезли, так и скажите, но покажите, что понимаете путь кода до прода и где могли бы помочь. Если его не было и вы разбирались сами, это сильная сторона: расскажите, что именно подняли. Если опыта мало, честно назовите границу: «пайплайн настраивал не я, но я читал конфиг и чинил падения сборки».
Где спотыкаются
Отвечают одним словом, «да» или «нет». Интервьюер задал вопрос, чтобы услышать про вашу роль, и без неё ответ пустой.
Говорят «деплой не моя зона». Для фронтенд-разработчика это настораживает: от сборки и кэширования статики напрямую зависит, что увидит пользователь после релиза.
Приносят гладкие проценты вроде «инцидентов стало на 20% меньше» без понимания, откуда они взялись. Первый же вопрос «как мерили» такой ответ разрушает.