How would you automate forbidden-word checks in CI/CD?
This tests embedding brand governance into engineering workflows. A strong answer covers AST-aware string extraction, CI gating with severity levels, and allowlisting to cut false positives.
What's really being asked
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.
The full answer
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.
The mistakes people make
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.
What usually comes next
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.
A 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.
Interview question
You need to add a forbidden-word check to a React app's CI pipeline. Which approach best prevents user-facing policy violations while keeping the signal-to-noise ratio low?
- a.Extract string literals from a framework-specific user-facing hook, check against tiered rules with allowlists, and run as a fast PR annotation job.Correct
- b.Add a mandatory PR checklist asking developers to confirm no forbidden words were added, bypassing the check for internal identifiers.
- c.Grep all source files for forbidden terms and fail the build on any match, requiring content team approval to override.
- d.Scan the repository post-deployment and create tickets for the editorial team to review flagged strings within 48 hours.
Why? this is the answer
Option A is correct because it targets only user-facing strings via AST-aware extraction, uses severity tiers and allowlists to control noise, and gates pull requests with fast inline feedback. Option C is a tempting distractor because grepping all source files sounds thorough, but it cannot distinguish UI text from variable names or comments, generating false positives that train teams to ignore the check.
Just read this? Test yourself on what you have been reading.
Read the original → netlify.com
- #ci/cd
- #linting
- #developer-experience
- #content-governance
- #automation
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on ci/cd — each one lists the topics its interview covers.
See open roles