An interviewer says — you are launching a language-model feature to 2 million users. Design the evaluation gate that decides whether it ships, and tell me what it cannot tell you. Where do you take this?

What the interviewer is testing

Whether you can build a gate that is decidable — one that produces ship or do-not-ship from evidence, rather than a report that a committee interprets. Most candidates describe evaluations. The senior move is to state thresholds in advance and to say what happens when the threshold is missed.

The clarifying questions that change the answer

• What is the worst outcome for a single user? A wrong answer in a cooking assistant and a wrong answer in a benefits-eligibility assistant need different gates, and the difference is not a matter of degree.
• Is output shown directly to the user or does it pass through an action? A model that drafts text and a model that triggers a refund have different failure surfaces.
• What is the fallback when the gate fails open? If there is no non-model path, the gate cannot block anything without taking the feature down.
• Who is on the hook when it is wrong in public — and do they see the evaluation results before launch?

A strong answer's arc

Four layers, each answering something the others cannot.

1. A task suite with a fixed threshold, built from real user requests rather than invented ones, scored automatically. Its job is to catch regression between versions, so the number matters less than its stability.
2. Adversarial testing against a stated threat model — prompt injection where the model reads untrusted content, extraction of system instructions, harmful-content elicitation, and the domain-specific misuse this particular feature invites. Red-teaming without a threat model produces anecdotes, and anecdotes do not have thresholds.
3. A human review sample with published inter-rater agreement. If reviewers agree at chance level, the metric is noise and the gate is theatre.
4. A staged rollout with live guardrail metrics — not to gather opinions but because some failures only exist at scale, particularly rare-input and adversarial-user behaviour that no pre-launch suite contains.

Then state the thresholds and the consequence before the results are known: below this, we do not ship; between these, we ship to 1% with a named owner watching; above this, we proceed.

Common weak answers

• A benchmark score with no threshold, which makes the gate a conversation.
• Red-teaming as an unbounded exercise, which always finds something and therefore never decides anything.
• Evaluating the model rather than the feature. Retrieval, prompt, tools and fallbacks are where most real failures live, and swapping the model version does not revalidate them.
• Treating a passed gate as a finished obligation, when model and data both drift after launch.

What a strong answer adds

What the gate cannot tell you, said plainly: it cannot cover inputs nobody imagined, it degrades as the input distribution moves, and a suite that is reused long enough is optimised against. So the design includes refreshing the suite from production traffic, holding out a portion that is never used for tuning, and a documented rollback that does not require a model change — a feature flag, because retraining under incident pressure is not a rollback.

And the organisational layer: who may override the gate, recorded in advance. A gate with an undocumented override path has one, and it will be used by whoever has the most delivery pressure on the day.

What the gate costs, stated when proposing it: a suite to maintain against a moving product, reviewer time that scales with sample size, and a launch date that a threshold can move. Choose the depth from the worst single-user outcome and from reversibility — a drafting assistant whose output the user edits needs layer 1 and a thin layer 4; a feature that takes an irreversible action on the user's behalf needs all four and the documented override. Published model and system cards since 2019 have converged on roughly this structure, which makes them a reasonable template rather than something to invent.