Golden-Master Modernization

Candidate · clear top-down answerI would build two things. A compatibility engine matches what the old system does today. A policy engine handles intentional changes later. Keeping them separate lets us migrate safely without treating every old bug as a forever rule.

Why this mattersThis gives the interviewer a map before any boxes appear, and it makes the system's most important trust decision explicit.

Candidate · clear top-down answerThe API takes days, miles, receipt amount, and decision date. It must return the exact amount, validation result, policy version, and explanation. The same request ID must never create two payments. We need to learn how old cases were sampled before trusting the data.

Why this mattersA narrow first release keeps the design realistic. It also shows which tempting features can wait without weakening the core product.

Candidate · clear top-down answerTraffic is small, so servers are easy to size. Correctness is hard. A 99.99% target means at most one wrong result in 10,000, but observing zero errors in only 10,000 samples does not prove that target. A rough zero-failure confidence rule needs about 30,000 independent examples for a 0.01% upper error bound. Even then, random tests can miss rare money and date boundaries, so we need risk-based slices as well as a global number.

Why this mattersThe calculation is not about perfect forecasting. It identifies the part most likely to run out of capacity or delay users.

Candidate · clear top-down answerA golden master is a trusted set of inputs and old-system outputs. I would include common cases, rare cases, values near thresholds, date periods, and error cases. We keep both traffic-weighted samples and evenly spread boundary samples.

Why this mattersA random sample mostly proves common behavior. Boundary and risk slices make rare but expensive rules visible before the replacement handles money.

Candidate · clear top-down answerThe main records are normalized input, old-system observation, golden example, approved policy version, decision, comparison result, and appeal. Money is stored as integer cents. A decision points to the exact input and policy version. The API uses a request key so a retry returns the same decision; reusing that key with different input is an error rather than a second payment.

Why this mattersThe API follows the user journey and makes slow work visible. A client should never hold one request open for a long job.

Candidate · clear top-down answerA request is authenticated, normalized, and checked for a duplicate key. We choose the approved policy for the business date, run fixed rules, and save the decision, explanation, and pending payment message in one database transaction. A worker sends payment afterward. If the receiver times out, we look up the business key before retrying, because a timeout does not tell us whether money moved.

Why this mattersTracing one real request proves the boxes connect. It also exposes where we acknowledge success and where a retry may begin.

Candidate · clear top-down answerWe start with readable rule guesses, test them on cases that were not used to create the guess, and actively query examples that separate competing rules. Related-value tests check properties such as “more miles should not reduce payment” unless evidence proves an exception. I keep a private final test set so repeated tuning cannot slowly overfit the benchmark.

Why this mattersThe deep dive starts only after the basic path is clear. Use one concrete example, then state the speed-versus-correctness choice.

Candidate · clear top-down answerEach policy says when it applies. A correction is a new approved version with an impact report, not an edit to old history. If the business allows retroactive changes, we create adjustment decisions that point to the old decision.

Why this mattersBusiness date and decision time are different. New versions and explicit adjustments preserve what was paid, why it was paid, and what changed later.

Candidate · clear top-down answerThe request key maps to one normalized input. Reusing it with different input is an error. Saving the decision and its outgoing message together prevents a crash from losing payment work or creating a second logical payment.

Why this mattersUse immediate agreement only for decisions that cannot be ambiguous. Let rebuildable views catch up and always show their freshness.

Candidate · clear top-down answerIf the old system changes, we create a new observed era instead of mixing outputs. We freeze promotion, compare before and after on a carefully chosen panel, and ask owners whether the change was intentional or a regression.

Why this mattersA failure answer should name the uncertain state first. Then explain how the system learns the truth before it repeats an action.

Candidate · clear top-down answerFirst replay old cases. Then mirror live traffic while the old system remains the only payment authority. Next enable small stable user groups, compare every result and side effect, and expand only while slice-level money and error checks pass. One route switch sends a group back to the old system. We keep that rollback path until in-flight work is settled and the agreed retention window ends.

Why this mattersOnly one system may move money for a request. Shadowing compares safely; cohort cutover and one route switch make expansion and retreat controlled.

Candidate · clear top-down answerA high overall match can hide a bad group. If mismatches cluster around .49 and .99, stop rollout, test those endings closely, inspect rounding order, and use integer cents everywhere. Fix the rule and rerun both the boundary group and the full suite.

Why this mattersA global percentage can hide a systematic financial bug. Slice-level gates turn the suspicious endings into a release blocker instead of averaging them away.

Candidate · clear top-down answerSend only the needed numeric inputs into the rules engine and keep employee identity outside when possible. Encrypt each customer's records with separate keys, separate policy authors from approvers, restrict golden datasets, and log every policy change and export. Test files use masked or synthetic data, and support tools must not reveal receipts or identities to people without case-level permission.

Why this mattersSecurity belongs in keys, tokens, workers, and logs. It is not a single box added to the diagram at the end.

Candidate · clear top-down answerMeasure latency and availability, but also exact-cent match, total financial difference, errors by boundary group and policy era, appeals, and rollback readiness. Alert on a bad slice even when the global number still looks good.

Why this mattersMetrics should cover user speed, system safety, and result quality. Rollout starts read-only and earns stronger automation with evidence.

Candidate · clear top-down answerReadable rules take more work than a flexible model, but money needs exact and explainable behavior. The core trade-off is matching old behavior versus fixing it; separate compatibility and correction lanes make that choice explicit.

Why this mattersEvery design choice has a cost. Name the simpler alternative and explain which requirement makes the added complexity worth it.

Candidate · clear top-down answerIn short: learn old behavior from a carefully chosen golden set, run deterministic integer-money rules, choose one approved policy by business date, and save one repeat-safe decision. Shadow traffic and slice-level checks make cutover safe.

Why this mattersThe recap should repeat the user flow, the main trust rule, the hardest failure, and the most important trade-off—not every component.