Приходилось ли работать с Unix-системами

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

Для Go-разработчика это вопрос не про экзотику, а про повседневную среду: сервис собирается статическим бинарником и живёт в Linux-контейнере. Интервьюер выясняет, сможете ли вы разобраться в проде без среды разработки: посмотреть логи, дескрипторы, нагрузку, сигналы.

Как отвечать

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

• сборка и выкладка: GOOS и GOARCH, кросс-компиляция, запуск под systemd или в контейнере, переменные окружения, права на файлы;
• диагностика: journalctl и логи, ss и lsof для сокетов и дескрипторов, top, strace, tcpdump, df и du при заполненном диске;
• специфика Go поверх Unix: корректное завершение по SIGTERM через os/signal и context, лимит дескрипторов при большом числе соединений, профилирование через pprof.

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

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

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

Игнорируют сигналы. Контейнеру при остановке приходит SIGTERM, и если его никто не обрабатывает, оркестратор через таймаут убивает процесс жёстко: запросы обрываются, буферы не сброшены. Обработчик сигнала и мягкое завершение через context это минимум, который ждут от Go-сервиса.

Забывают про лимиты контейнера. Долгое время рантайм брал число ядер хоста, а не квоту cgroup, поэтому GOMAXPROCS выставляли руками; в свежих версиях рантайм умеет читать лимит сам, но проверить это стоит, иначе планировщик работает не так, как вы ожидаете.