Работали ли вы с Linux и с какими дистрибутивами?
Что проверяют
Эксплуатационный опыт, а не список названий. Интервьюер слушает, различаете ли вы семейства дистрибутивов и понимаете ли, что меняется при переезде между ними: именно в этом месте ломаются заученные рецепты.
Как отвечать
Назовите то, что реально держали в работе, и сразу переходите к различиям. Две большие ветки: deb с apt и dpkg, rpm с dnf и rpm. Дальше по слоям:
- срок поддержки релиза: от него зависит, на чём допустимо держать прод и как долго приезжают обновления безопасности;
- инициализация почти везде systemd:
systemctl, юниты, таймеры вместо cron, журнал вместо текстовых логов; - сеть настраивается по-разному, инструменты и конфиги не совпадают;
- обязательный контроль доступа: SELinux в одной ветке, AppArmor в другой, и это частая причина отказа в доступе там, где на тестовой машине всё работало;
- свежесть ядра и библиотек против стабильности и бэкпортов.
Полезно добавить задачи, а не только названия: разбор нагрузки, поиск утечки дескрипторов через lsof и /proc, ограничения ресурсов через systemd и cgroups, права и sudoers, сборка своего пакета, раскатка ролями системы управления конфигурацией. Отдельный плюс, если скажете про базовые образы контейнеров: сборка на musl ведёт себя иначе, чем на glibc, и ловится это на разрешении имён и странных падениях.
Где спотыкаются
Перечисляют дистрибутивы через запятую и замолкают. Список ничего не говорит об опыте, следующий вопрос будет про различия, и на нём разговор заканчивается.
Второе: решают проблему выключением защиты. Ответ «отключил SELinux, выдал права на запись всем, сбросил правила межсетевого экрана» закрывает вакансию быстрее любой технической ошибки. Ждут другого: разбора отказа в журнале аудита и точечного правила.
Третье: не знают, где искать. Ищут текстовые логи в привычном каталоге на системе, где всё пишется в журнал systemd, и делают вывод, что сервис ничего не логирует.