intermediate 2 min answer

A 12-year-old service has 4% test coverage and no tests for its core logic. It changes twice a year. Do you apply your quality gates to it?

legacypragmatismgovernance
Show the full answer Hide the answer

What the interviewer is testing

Whether you can apply standards proportionately, which is a more advanced skill than applying them uniformly.

The reasoning

Uniform gates fail here. Requiring 80% coverage on this service means either a large retrofit investment with no product return, or an exemption that undermines the standard everywhere.

The relevant questions are about risk and change rate, not about the number:

What is the consequence of a defect? If this service calculates regulatory returns or moves money, the low coverage is a serious risk regardless of change frequency. If it generates an internal report, it is not.

What changes when it changes? Twice a year suggests small, well-understood modifications rather than active development.

What is its future? Being replaced next year, or expected to run for another decade?

The proportionate answer

Apply delta-based gates: any code changed must be covered and must pass the current standards. The existing body is left alone. This costs almost nothing for a service changing twice a year, and it means the parts being touched improve.

Add a characterisation test around the core logic before the next change — tests that document current behaviour rather than asserting correctness. That gives a safety net for modification at a fraction of the cost of full coverage, and it is the standard technique for making legacy code safe to change.

If the consequence tier is high, fund a targeted investment in the core calculation only, plus mutation testing on it. Not the whole codebase — the part where a silent wrong answer is expensive.

What a strong answer adds

Recording this as an explicit, time-bound exception with a named risk owner rather than letting it be an unspoken gap. The waiver register is where the aggregate risk becomes visible, and an unrecorded exception is invisible risk.

Common weak answers

Applying the standard rigidly, producing an expensive retrofit or a permanent exemption. Exempting it entirely without assessing consequence.