Приходилось ли работать с Linux терминалом и удаленными машинами

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

Не заблокируетесь ли вы, когда стенд лёг, а смотреть на нём нечего. Ждут, что вы сами зайдёте на машину, найдёте логи, повторите запрос мимо интерфейса, заберёте артефакт и перезапустите сервис, не превращая каждый шаг в отдельную задачу для разработчика.

Как отвечать

Назовите набор, которым правда пользуетесь, и покажите, как он складывается в разбор падения: подключение по ключу, логи сервиса, повтор запроса, проверка ресурсов.

ssh qa@stand
docker compose ps
journalctl -u api --since "10 min ago" | grep -i error
curl -i -H "Authorization: Bearer $TOKEN" localhost:8080/api/orders

Дальше по ситуации: df -h и free -m, когда стенд «тормозит», ss -tulpn, чтобы увидеть, слушает ли кто-то порт, tail -f по файлу лога, scp или rsync за отчётом прогона. Упомяните tmux или screen: долгий прогон автотестов не должен умирать вместе с разорванным соединением. Хорошо звучит и бытовое: алиасы хостов в конфиге ssh, доступ по ключу вместо пароля, понимание, где на стенде лежат переменные окружения.

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

Знают команды списком, но теряются на выводе. Спрашивают обычно живьём: показывают кусок лога или вывод статуса и просят сказать, что делать дальше, а пересказ справки тут не помогает.

Второе: правят конфигурацию на общем стенде и не предупреждают команду. Через час коллега ловит необъяснимое поведение и тратит день на поиск причины, которой в коде нет.

Третье: не различают «сервис не запущен», «сервис запущен, но не слушает порт» и «сервис отвечает ошибкой». Это три разных факта с тремя разными проверками, а их смешивание рождает дефект с формулировкой «ничего не работает».