As a platform default for new pipelines, would you require one implementation serving both modes or accept two, and how do you decide?
answer
- count implementations, not engines
- drift is paid every month
- can history go back through live code
- a default plus a named escape hatch
- who owns reconciliation, and until when
basics
~20 sDefault to one implementation serving both the live run and the recomputation, and make a second implementation a reviewed, time-boxed exception with a named owner. Drift and reconciliation are paid every month; a single path pays mostly up front.
solid answer
~50 sDecide from the readers, not from the engine. Start with what each consumer genuinely needs: how fresh, and whether a published figure may ever move. Then check what is actually available — some engines in this class serve both a recomputation over stored records and a continuous run from one program surface, others really only do one shape well — and whether history can be pushed back through the live code at all. The default should be **one implementation serving both modes**, because the two-path design's cost is permanent: two code paths, two operational surfaces, twice the compute, and a reconciliation step that never goes away. Keep an explicit escape hatch: a second implementation is allowed where a consumer's number may never move, or where the engine cannot serve one mode, with a named owner for reconciliation and a review date.
go deeper
Recall the two arrangements: one program used for both the live run and the recomputation, or the same rule written twice with a step deciding which answer is published.
Explain why two implementations cost more than twice: every rule change is two changes, plus a test that the two agree, plus a permanent comparison between their outputs.
Argue the case from a concrete workload — the freshness each consumer actually needs, whether a figure may be revised, and whether history can be pushed back through the live code.
Own the standard: state the default, define and price the exception, name who holds reconciliation, and say plainly what evidence would make you reverse the decision.
## The call, stated precisely The choice is between **one implementation serving both modes** — the same program used for the live run and for recomputing over history — and **the two-path design**, where the same rule is written twice and a reconciliation step decides which answer a reader sees. This is not a framework preference; it is a decision about how many implementations of each business rule the organisation will maintain forever. ## What actually decides it 1. **What each consumer needs, per consumer.** Freshness is not one number for a platform. A figure someone acts on within the minute and a figure quoted in a monthly review have different requirements, and only the first argues for continuous execution at all. 2. **Whether a published figure may move.** If a number, once seen, must never change, one path serving both modes has to be designed so that it never publishes a provisional value — or the second path earns its place. 3. **What the available engines actually do.** Some expose one program surface that runs over a bounded stored input or continuously; others are strong in one shape and imitate the other, and the imitation carries the imitated shape's costs. Assuming the first case universally is the most common error in this decision. 4. **Whether history can be pushed back through the live code.** The single path depends on being able to re-read a long stretch of past records through the same program. Whether that is possible, and what it costs, is a separate subject with its own owner — but if the answer is no, the argument is over. 5. **Capacity to catch up.** Feeding history through the live path needs a burst of capacity well above steady state, and the platform must be able to grant it without starving everything else. 6. **Who is on call.** Two implementations mean two operational surfaces with different failure units. If one team owns both, the drift lands on them; if two teams own one each, the disagreement becomes an organisational problem as well as a technical one. ## What each option costs | | one implementation, both modes | two implementations | |---|---|---| | where the cost lands | up front: contract design, capacity for catch-up | every month: drift, reconciliation, double review | | a change to the rule | one change, both modes | two changes plus a test that they agree | | what a reader quotes | one lineage, possibly revised | two numbers whose difference must be explained | | operational surface | one, with a catch-up mode | two, with different failure units | | main risk | the live path's semantics applied to a settled period | the two answers quietly diverging | ## Setting the default and the escape hatch 1. **State the default** — one implementation serving both modes — and make it the cheap path: templates, a reviewed shape, examples that already handle a catch-up run. 2. **Define the exception.** A second implementation is allowed where a consumer's published figure may never move, where the engine genuinely cannot serve one of the two modes, or where a migration needs both running side by side. 3. **Price the exception.** Every exception ships with a named owner for reconciliation, a detector that compares the two answers per period, and a review date. 4. **Make the count visible.** Publish how many pipelines are on the exception. A default nobody measures is a preference, not a standard. ## What would change the decision - A regulated figure with a formal restatement process, where a provisional number is not acceptable in any form. - An engine landscape where no available runtime serves both modes credibly, making a single path an aspiration rather than a design. - Consumers whose freshness need turns out, on inspection, to be hours — in which case the live path may not be needed at all, which is the answer candidates most often skip. ## What an interviewer is listening for A candidate who starts from consumers and cost rather than from the name of a runtime; who knows that the two-path design's price is recurring and the single path's price is mostly up front and in capacity; who states a default and an escape hatch rather than a rule with no exceptions; and who names what would change their mind. Answering with a runtime's feature list, or declaring one implementation always correct without asking whether history can be pushed back through it, is the weak version of this answer.
- What would make you deliberately accept two implementations?A consumer whose published figure may never move, an engine that genuinely cannot serve one of the two modes, or a migration that needs both running side by side. In each case the exception carries a named owner for reconciliation, a comparison that alerts on drift, and a review date.
- Even with one program, what still differs between the live execution and the recomputation?The inputs are cut differently, the output contract differs — a settled answer once against a figure revised as more arrives — reference data is read as of different moments, and the capacity profile differs sharply because catching up needs a burst well above steady state.
- How do you stop the default from being quietly ignored?Make the supported path the cheapest one to take: a template that already handles a catch-up run, a review that grants exceptions with an owner and an expiry, and a published count of pipelines currently on the exception so drift from the standard is visible.
saying these in an interview costs you the question
- Picks a runtime as the default with no consumer requirement named
- Assumes every engine of this class serves both modes from one program
- Treats two implementations as free once both have been written
- Sets a default with no escape hatch and no owner for exceptions
- Claims one implementation removes the need to recompute history at all
- Judges the call on engine features rather than on what readers need