Какие инструменты использовали для качества кода (линтеры, форматтеры)

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

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

Как отвечать

• линтер: ESLint 9 с flat-конфигом в eslint.config.js, typescript-eslint, плагины react-hooks (правила хуков и зависимости эффектов), jsx-a11y, import-x. Правила с проверкой типов (no-floating-promises, no-misused-promises) требуют projectService и стоят времени, зато ловят реальные баги;
• форматтер: Prettier 3, а стилевые правила ESLint выключены через eslint-config-prettier. Формат не должен обсуждаться на ревью;
• альтернатива: Biome или oxlint, один бинарник, прогон на порядок быстрее, но набор правил уже;
• типы и стили: tsc --noEmit отдельным шагом, Stylelint для CSS-модулей;
• автоматизация: lint-staged в pre-commit через husky, в CI eslint . --max-warnings=0 и prettier --check, но не --write. CI проверяет, а не правит код за вас;
• сверху: knip или depcheck на мёртвый код, size-limit на бюджет бандла, commitlint на сообщения коммитов.

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

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

Берут большой готовый пресет целиком, потом отключают половину правил и не могут объяснить, зачем оставили остальные.

Держат всё в режиме предупреждений. Тысяча warning равна их отсутствию, порог --max-warnings=0 возвращает смысл проверке.

Ставят линтер только в pre-commit. Хук обходится флагом --no-verify, единственная настоящая защита это шаг в CI, блокирующий мерж.