Actors
- Employee or upstream expense system
- Finance reviewer investigating mismatch
- Policy owner approving correction
- Migration engineer running differential tests
- Auditor replaying a decision
- Support operator handling appeal
BEHAVIOR LAB / MOCK 06
Reconstruct an opaque reimbursement engine from observed inputs and outputs, preserve money behavior, add effective-dated corrections, and cut over without a big-bang bet.
OPENING PROMPT
Read this once, then begin aloud. Spend the first two minutes establishing contract, actors, risk and what must remain authoritative.
Design ReimburseX, a replacement for a black-box reimbursement binary. The legacy interface accepts trip days, miles traveled and receipt amount and returns an exact monetary reimbursement. You have 30 million historical request/response pairs and temporary access to the legacy oracle, but no source code. The replacement must reproduce current behavior, support reviewed effective-dated corrections, shadow safely, explain divergences and cut over incrementally.
Separate behavior preservation from policy improvement. A golden-master corpus and differential harness certify compatibility; a versioned policy engine introduces deliberate corrections only through explicit, effective-dated change records.
REQUIREMENTS
These are supplied mock numbers for sizing and follow-ups. Say your assumptions before using them.
HIGH-LEVEL DESIGN
Name the authoritative state, derived projections, asynchronous boundaries and the exact point where a business decision becomes durable.
STORAGE + ACCESS
The table is logical, not a mandate for one database. Choose physical stores after access patterns, transactions, retention and rebuildability are clear.
| Entity | Primary / unique key | Important fields and purpose |
|---|---|---|
| InputCase | (case_id) | days, miles, receipt_cents, observed_at, source, fingerprint |
| OracleObservation | (case_id, oracle_version) | output_cents, called_at, environment, response_hash |
| GoldenExample | (corpus_version, example_id) | case_id, stratum, boundary_tags, expected_cents |
| PolicyVersion | (policy_id, version) | effective_from/to, rule_bundle_hash, state, approvers |
| Decision | (tenant_id, request_id) | input_hash, policy_version, output_cents, explanation_hash, state |
| ShadowComparison | (request_id, candidate_version) | legacy_cents, candidate_cents, delta, mismatch_class |
| Correction | (correction_id) | rationale, affected_domain, effective_date, approvals, rollout_state |
| Appeal | (appeal_id) | decision_id, claimant_reason, evidence, resolution, adjusted_decision_id |
POST /v1/reimbursementsIdempotency-Key + observed/effective date + three inputs
200 {decisionId,amountCents,policyVersion}GET /v1/decisions/{id}Replay inputs, rule trace and hashes subject to role
200 {explanation}POST /v1/corpora/{id}/evaluateRun candidate bundle against frozen golden set
202 {evaluationRun}GET /v1/comparisons?class=&delta=&cursor=Mismatch workbench with sampled cases
200POST /v1/policies/{id}/versionsCreate draft effective-dated rule bundle
201 {version}POST /v1/appealsReference original decision; never mutate it
201 {appealId}00:00 → 30:00
Answers are written in a speakable first-person style. Turn on Practice Mode to hide them, answer aloud, then reveal one at a time.
I would explicitly separate two products: a compatibility engine that reproduces observed legacy behavior, and a governed policy engine for intentional future changes. First freeze the observable contract: three inputs, decimal output, date/context and error behavior. Build a stratified golden-master corpus from history plus oracle probes, create a deterministic evaluator, shadow every request, and ledger both outcomes. Only after measured parity do we route cohorts. I would ask whether output alone or exceptions/timing are contract behavior too.
We need exact-cent output, input validation parity, idempotent API, effective-dated policy choice, explanation, appeal linkage, differential testing and safe rollback. The only observable features are days, miles, receipts and request date; employee or department stories are untestable and must not leak into the model. I want the historical sampling process, whether the oracle changed over time, and the legal meaning of retroactive correction. I exclude travel booking, probabilistic production decisions and silently rewriting past outcomes.
Fifty thousand/day averages 0.58 RPS, so the 40 RPS peak and availability dominate compute sizing. Thirty million compact cases at roughly 100 bytes are 3 GB before indexes—easy to store; repeated evaluation is CPU-bound but parallel. A 99.99% target allows one mismatch per 10,000. Seeing zero errors in only 30,000 random tests gives a rough 95% upper error bound of 3/n = 0.01%, but random samples miss rare boundaries. I need millions of stratified and generated boundary cases, not one aggregate percentage.
50,000 / 86,400 ≈ 0.58 RPS average
99.99% ⇒ ≤ 1 mismatch / 10,000
Rule of three: zero failures in n ⇒ upper rate ≈ 3/nDeduplicate exact input triples but preserve frequency metadata and time buckets. Stratify by days, miles/day, receipt ranges, decimal endings, extreme ratios, historical epoch and observed discontinuities. Detect output step changes and cluster local neighborhoods. Sample both traffic-weighted cases for business impact and uniform/boundary cases for rule discovery. While the oracle is available, actively probe just below/at/above candidate thresholds and create metamorphic pairs such as +1 mile or +1 cent. Every corpus version is immutable and records selection code, source hashes and expected oracle version.
InputCase stores normalized integers: days, miles and receipt cents. OracleObservation is append-only because the same input may return differently across legacy epochs. GoldenExample pins corpus and oracle version. PolicyVersion is immutable after approval, with non-overlapping effective intervals enforced per policy line. Decision is keyed by tenant/request ID and stores input hash, selected policy, cents and explanation hash. A correction creates a new version; an appeal references the old decision and any adjustment is a second decision. POST requires an idempotency key and effective context.
The edge authenticates and dedupes request ID. A strict normalizer parses decimal strings to integer cents, validates units and canonicalizes the input hash. The policy router selects the one approved version whose effective interval contains the decision date, and snapshots that choice. A deterministic rules engine evaluates a compiled decision table, producing output cents and rule trace. In one transaction, the service writes Decision plus an outbox response event; retries return the same decision. During shadow, an asynchronous adapter invokes or reads the legacy outcome and writes ShadowComparison. Dashboards aggregate deltas, but the immutable ledger remains the investigation source.
Start with interpretable hypotheses from discontinuity plots and interviews, but certify only against held-out observations. A decision-table/rule DSL encodes tiers, caps, bonuses and interactions with explicit rounding after each stage if observations require it. Use active learning to query cases that distinguish competing hypotheses. Metamorphic tests find nonmonotonic zones but do not assume monotonicity globally. Keep an exception table only for genuinely isolated known legacy defects; a giant lookup/memorization model would fail unseen combinations and be impossible to govern.
Each approved PolicyVersion has transaction time and valid effective interval. The router resolves using the business decision date, not deploy time. A correction proposal includes rationale, impacted golden strata, simulated financial delta, approvals and intended effective date. If retroactive recalculation is allowed, generate adjustment decisions referencing originals; never mutate ledger rows. Overlap constraints prevent two active versions for the same cohort/date. The golden suite has two lanes: compatibility tests expected to match legacy and policy tests expected to differ by an approved correction ID.
Strong consistency covers request dedupe, policy interval publication and decision ledger. Corpus evaluation and comparison analytics are eventual. Idempotency key maps to canonical input hash; reusing a key with different input returns 409. Decision plus outbox commits atomically, so downstream payment sees one effect despite at-least-once delivery. If policy selection or ledger is unavailable, fail closed rather than guess money. Shadow adapter failures do not fail customer requests; they create a comparison gap metric and retry with bounded age.
OracleObservation already includes observed time and environment, so we detect a multimodal output for one fingerprint. Freeze certification against the pre-change oracle version, stop active promotion, and create a new epoch. Probe a stratified panel before and after to localize affected regions. Ask policy owners whether it is an intended policy change or defect. Do not blend observations and learn an average. The shadow comparator labels legacy epoch, and routing remains on the last approved new-engine policy until a reviewed version models the intended change.
Phase zero replays frozen history. Phase one mirrors live requests asynchronously while legacy remains authoritative. Phase two makes the new engine authoritative for internal/test accounts, then low-risk cohorts selected by stable hash—not per request—to avoid inconsistent employee outcomes. Every phase has parity, financial-delta, latency, error and appeal guardrails with an automatic routing kill switch. Keep dual computation long enough to cover monthly boundaries. At full cutover, retain a read-only legacy adapter and replay capability until retention and audit requirements expire.
Pause cohort expansion because aggregate 99.99% can hide a material slice. Create a dedicated boundary stratum around those endings and inspect each arithmetic stage. This likely indicates decimal parsing, rounding order or a threshold keyed to cents. Replace any floating-point path with integer/rational arithmetic, encode rounding mode at the exact legacy stage, and add metamorphic cases ±1 cent. Backfill comparisons to calculate total financial impact. Promotion requires slice-specific zero unexplained mismatches, not only global parity.
The three numeric inputs are low sensitivity alone, but production requests may carry employee and tenant identity. Minimize the evaluator input, tokenize actor identity, encrypt ledgers with tenant keys and isolate test corpora from raw PII. Policy authors, approvers and deployers have separated roles. Golden datasets are access-controlled and exports watermarked/audited. Signed bundle hashes and append-only decisions detect tampering. The oracle adapter uses least-privilege credentials and cannot issue payment. Explanations redact internal anti-fraud thresholds when policy requires.
Service SLIs: p99 latency, availability, dedupe conflicts, policy-cache miss, ledger commit and outbox lag. Correctness: exact-cent parity, absolute delta, signed financial delta, mismatch rate by stratum/epoch/policy/cohort and validation-error parity. Migration: shadow coverage, legacy adapter gap age, cohort size and rollback readiness. Product: appeals, overturn rate, investigator time and unexplained mismatch age. Every release publishes a matrix over frozen corpora; online monitors compare distributions and run synthetic boundary canaries.
Interpretability may take more engineering than a flexible model but is required for exact money and corrections. Mirroring the legacy bug maximizes compatibility while policy cleanup improves outcomes; keeping separate compatibility and correction lanes resolves that tension. Traps are random-only sampling, leakage from history into certification, floats, assuming calendar/person inputs that do not exist, one global parity metric, mutating old decisions, and big-bang cutover.
ReimburseX learns with evidence but runs deterministically. Immutable, stratified golden corpora capture observed legacy epochs, boundaries, errors and metamorphic probes. A compiled, integer-money policy engine selects an approved effective-dated bundle and writes an immutable idempotent decision plus explanation. Shadow comparison is asynchronous and sliced by risk; deliberate corrections have their own approvals and expected mismatches. We progress from replay to shadow to stable cohorts with financial guardrails and rollback. Historical decisions remain untouched; appeals and adjustments form a traceable ledger.
DOMAIN DEPTH
These mechanisms are the interview’s differentiators. Be able to redraw each from memory and defend its failure behavior.
Traffic-weighted examples protect business impact; boundary and counterfactual probes protect rare rule edges. Both are required.
Immutable decisions reference one immutable rule bundle. New rules alter future or explicit adjustment decisions, never history in place.
FAILURE MATRIX
When the interviewer injects a fault, restate the violated assumption, change state or protocol, and name the new invariant.
| Injection | Recovery mechanism | Tempting wrong answer |
|---|---|---|
| 01Oracle changes | Version observations by epoch | Blend incompatible labels |
| 02Duplicate request | Idempotency key + input hash | Double payment |
| 03Floating rounding | Integer cents/rational intermediate | Tolerance hides cents |
| 04Shadow adapter down | Customer path succeeds; retry/coverage gap | Couple availability |
| 05Boundary mismatch | Slice gate and active probes | Aggregate parity |
| 06Policy overlap | Serializable interval constraint | Ambiguous version |
BOTEC
Use orders of magnitude to expose the bottleneck. State what this simple model omits.
INTERACTIVE SCENARIO
With zero observed mismatches, estimate the rough 95% upper error bound. Stratification is still required.
OPERATIONS + DELIVERY
A system is incomplete without observable user outcomes, staged deployment, rollback and an answer to “how will we know?”
INTERVIEWER TRAPS
Use these as flash cards. The right column is the compact sentence you want available under pressure.
| Trap | Better move |
|---|---|
| Random split only | Hold out strata, time and boundaries. |
| Tolerance for cents | Require exact money semantics. |
| Unobservable features | Use only contract inputs/context. |
| One parity number | Slice by epoch, boundary and impact. |
| Rewrite past result | Append adjustment decision. |
| Big-bang migration | Shadow and route stable cohorts. |
DEFINITIONS
Define the term, then connect it to a concrete invariant in this design. Avoid dropping vocabulary as a substitute for reasoning.
FINAL MINUTE
ReimburseX learns with evidence but runs deterministically. Immutable, stratified golden corpora capture observed legacy epochs, boundaries, errors and metamorphic probes. A compiled, integer-money policy engine selects an approved effective-dated bundle and writes an immutable idempotent decision plus explanation. Shadow comparison is asynchronous and sliced by risk; deliberate corrections have their own approvals and expected mismatches. We progress from replay to shadow to stable cohorts with financial guardrails and rollback. Historical decisions remain untouched; appeals and adjustments form a traceable ledger.
Rehearse again