Какие линтеры используешь в работе

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

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

Как отвечать

Разложите инструменты по ролям, а не просто перечислите:

• Ruff: линтер и форматтер на Rust, сейчас выбор по умолчанию в новых проектах. Реализует правила Flake8 и его популярных плагинов, isort (группа I), pyupgrade (UP), bugbear (B), часть Pylint (PL). Работает настолько быстро, что его гоняют на каждое сохранение. ruff check --fix исправляет часть замечаний сам, вывод ruff format почти полностью совпадает с Black;
• Flake8: классика, обёртка над pyflakes, pycodestyle и mccabe. Живёт в проектах, где давно настроен;
• Pylint: самый глубокий и самый медленный. Выводит типы между модулями, находит неиспользуемые аргументы, дубли кода, слишком сложные функции. Из коробки шумный, требует настройки;
• Black: не линтер, а форматтер. Ничего не ищет, просто переписывает код в единый вид;
• mypy или pyright: проверка типов по аннотациям, отдельный класс ошибок.

Дальше про процесс. Настройки лежат в pyproject.toml ([tool.ruff], [tool.mypy]), локально их запускает pre-commit, в CI те же команды выполняются без --fix, и упавшая проверка блокирует мерж. В редакторе стоит расширение того же линтера, чтобы замечания были видны сразу. В старом коде правила включают постепенно и держат исключения в конфиге, а не гасят всё через # noqa.

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

Называют Black линтером. Он форматирует и ошибок не ищет, интервьюер это заметит.

Держат вместе Flake8 и Black без согласованных настроек: разная длина строки и правило E203 дают конфликт, и код после форматирования не проходит линтер. Лечится общим line-length и исключениями либо переходом на Ruff.

Не знают, что Flake8 не читает pyproject.toml без плагина, и удивляются, почему настройки не применяются.