Linters

Linters encode maintainability rules beyond what the compiler checks: unused variables, unsafe promises, hook dependency mistakes, import cycles, accessibility issues, and security-sensitive APIs. They turn recurring review comments into automated feedback. Rule sets should match team maturity—strict where bugs are expensive, incremental where legacy code needs room.

On interviews: name rules you have enabled and why. Explain how you introduce new lint rules without blocking the whole team at once.

Common pitfalls: disabling rules globally instead of locally with justification; noisy rules that teams ignore; lint config drift between editor and CI.

The trade-off is flexibility versus complexity—know when the simpler path is enough.

Checklist:

• Run the same lint command locally and in CI.
• Document exceptions with comments and tickets.
• Tune rules per package or legacy boundary.
• Pair lint failures with fixable autofix where possible.