"Interview. You are the architect for a grocery marketplace where item availability changes constantly. Name three fitness functions you would put in CI to protect the architecture, and explain what each one would have caught." What makes a strong answer?

Why the question is hard

Most candidates name unit-test coverage or a linter. Those protect code. A fitness function protects an architectural characteristic — a property that no single test would notice was lost, because losing it requires no test to fail.

Three strong answers

1. Freshness budget on the availability pipeline. Check: end-to-end lag from a retailer's stock update to it being visible in search, measured continuously in production and asserted in a staging replay. Fails the build if p99 exceeds the budget the product promised. What it catches: an innocuous new enrichment step added to the pipeline that adds ninety seconds of lag. No test fails. Customers order items that are already gone, and the substitution rate — a business metric — degrades weeks later with no obvious cause.

2. Dependency-direction check on the checkout path. Check: a static rule that no module on the ordering path may import from analytics, recommendation or marketing modules. What it catches: the day someone adds a personalisation call inside checkout "just for a banner". It works fine in staging and becomes a checkout outage the first time the recommendation service is slow. This is the single highest-value fitness function in most commerce systems, because critical paths acquire non-critical dependencies by accident, never by decision.

3. Degradation test as a build gate. Check: with the availability service returning errors, the system must still let a customer complete an order using last-known stock plus a wider substitution allowance. Asserted in an automated resilience test, not a game day. What it catches: the gradual replacement of graceful degradation with hard dependency, which happens whenever a fallback path is not exercised. Fallbacks that are never run do not work.

What makes these strong rather than generic

Each names a specific property, a specific automated check and a specific decay it prevents. And each protects something that would otherwise be discovered by a customer: stale availability, a critical path that acquired an optional dependency, and a fallback that quietly stopped functioning.

The bar for a staff-level answer

Adding the cost: fitness functions that are slow or flaky get deleted. Say how you would keep them fast — sampled production measurement rather than full replay, static analysis rather than runtime for dependency rules — because an architectural check nobody trusts is worse than none.