Какой опыт работы с Bash

Что проверяют

Пишете ли вы скрипты, которые не ломают прод при первой неожиданности, или склеиваете команды из истории терминала. Следом часто просят прочитать или написать кусок скрипта прямо на встрече, либо спрашивают, в какой момент вы перешли бы на Python или Ansible.

Как отвечать

Начните с реальных задач: обёртки для бэкапов, entrypoint-скрипты контейнеров, шаги CI, задачи в cron, разбор логов. Затем покажите, что знаете, как сделать скрипт надёжным:

• строгий режим: set -euo pipefail в начале. Оговорите пределы: -e не срабатывает внутри условий if и в цепочках с &&, поэтому критичные коды возврата проверяют явно;
• кавычки: "$var" всегда, иначе имя файла с пробелом превращается в два аргумента, массивы через "${arr[@]}";
• уборка: trap cleanup EXIT для удаления временных файлов из mktemp;
• идемпотентность: повторный запуск не ломает результат, mkdir -p, проверка перед созданием;
• конкурентность: flock, чтобы cron не запустил вторую копию поверх первой;
• проверка: ShellCheck в CI, bash -n для синтаксиса;
• текст и данные: grep, awk, sed, jq для JSON, xargs -P для параллельного запуска.

Сильно звучит граница применимости: когда скрипт перерастает сотню строк, в нём появляются структуры данных или повторы по состоянию, его переписывают на Python, а конфигурацию серверов отдают Ansible. Своих примеров нужно два или три, с тем, что скрипт делал и что в нём однажды сломалось.

Где спотыкаются

Считают set -e полной защитой. На вопросе «почему скрипт не упал, хотя команда вернула ошибку» кандидаты теряются.

Пишут for f in $(ls *.log) и разбирают вывод ls. Имена с пробелами ломают такой цикл, нужен обычный glob: for f in *.log.

Путают sh и bash: пишут [[ ]] и массивы, а запускают через /bin/sh, который в Debian и Ubuntu указывает на dash.