Писал ли bash-скрипты для автоматизации?
Что проверяют
Справляетесь ли вы с окружением вокруг собственного кода. От фронтендера не ждут уровня инженера эксплуатации, но ждут, что вы почините свой шаг сборки, не блокируя команду, и не станете просить коллегу переименовать файлы в двадцати папках руками.
Как отвечать
Коротко «да» и сразу две-три конкретные задачи, а не общие слова про автоматизацию. Что обычно бывает у фронтендера:
- шаг в CI: сборка, прогон линтера и тестов, проверка размера бандла с падением по порогу;
- хук перед коммитом, который гоняет проверки только по изменённым файлам;
- подготовка окружения для e2e: поднять статику, дождаться порта, прогнать тесты, погасить сервер;
- выпуск версии: поднять номер, собрать, повесить тег;
- точка входа контейнера, подставляющая переменные окружения в конфиг перед стартом.
Полезно показать гигиену: set -euo pipefail, кавычки вокруг подстановок, ${VAR:?не задано} для обязательных переменных, shellcheck в проверках. И назвать границу применимости: как только логика перерастает десяток строк или в команде есть Windows, скрипт переезжает в Node и в команды package.json, а bash остаётся для склейки вызовов.
Где спотыкаются
Пересказывают заученный шаблон с придуманной экономией вроде «сократил деплой вдвое, ошибок стало втрое меньше». Такие числа без методики замера вызывают ровно один следующий вопрос, и разговор на нём заканчивается.
Второе: скрипт без set -e и без кавычек. Команда посередине падает, а шаг остаётся зелёным; путь с пробелом разваливается на два аргумента; пустая переменная в rm -rf "$DIR/dist" превращает уборку в удаление не того каталога.
Третье: пишут под GNU, а запускают на macOS или наоборот. sed -i, date, readlink -f ведут себя по-разному, и скрипт, отлаженный на ноутбуке, падает на сборочном агенте.