How would you automate forbidden-word checks in CI/CD?

WHAT THIS TESTS: Your ability to translate a content policy into a reliable engineering control. Interviewers want to see that you understand the difference between user-facing strings and internal code, that you know how to integrate checks into CI/CD without destroying velocity, and that you can manage the signal-to-noise ratio of automated rules.

A GOOD ANSWER COVERS: Four layers in order. First, detection mechanics: use an AST-based extractor or a framework-aware linter to find strings that actually reach users, rather than grepping all source files. Second, rule configuration: maintain a forbidden-word list with severity tiers, for example blocking fatal outright while flagging invalid for review, and pair it with an allowlist for approved exceptions. Third, CI integration: run the check on every pull request via a lightweight job that fails fast before expensive tests, and surface results as PR annotations so authors fix issues in context. Fourth, false-positive mitigation: support inline annotations or metadata tags so developers can mark internal-only strings as exempt, and log suppression reasons for auditability.

COMMON WRONG ANSWERS: Proposing a simple grep or regex across the entire repository without distinguishing UI strings from variable names or comments. Suggesting manual editorial review in the PR process instead of automation. Ignoring the blast radius of false positives, which trains teams to bypass or disable the check. Recommending a post-deploy scan rather than pre-merge gating, which lets violations reach users.

LIKELY FOLLOW-UPS: How do you handle internationalization files where forbidden words might appear as translation keys rather than display text. What happens when a forbidden word is part of a third-party dependency string you cannot change. How would you roll this out without breaking builds for twenty existing violations. Whether you would block deploys or merely warn, and how you decide.

ONE CONCRETE EXAMPLE: Suppose your React codebase uses a custom useCopy hook for all user-facing text. You write a Babel or TypeScript compiler plugin that extracts string literals passed to that hook, then runs them against a Vale or TextLint rule set in CI via GitHub Actions. The job completes in under thirty seconds. When a developer uses the word fatal in a new error message, the PR check fails with an inline comment suggesting critical or unrecoverable instead. If the same word appears in a server-side log identifier, an allowlist entry or a nocheck comment keeps the build green.

Source: Netlify Blog