How would you decide whether a team reports Bayesian or frequentist results for its recurring decisions?

## Frame it as a decision about decisions The wrong version of this conversation is philosophical. The useful version asks what the team's decisions actually look like, and picks reporting that fits them. Five dimensions do most of the work. ### 1. Data volume per decision This is the strongest single factor. Where each decision is backed by a large, well-behaved sample, the two frameworks produce numerically near-identical answers; the estimates coincide and the uncertainty is the same width. Arguing about which to use costs meetings and produces no change in what anyone does. Where each decision is backed by dozens of observations — a low-traffic surface, a new market, a cold-start launch, a rare-event metric where the effective sample is the event count and not the row count — the frameworks genuinely diverge, because whether outside information is allowed into the estimate materially changes the answer. ### 2. Whether real prior information exists A prior is worth its cost when you can point at where it came from: twelve documented launches on the same surface, a published base rate, a physical constraint. It is a liability when the honest answer is "we guessed". Ask the team to produce the evidence that would justify a prior *before* committing to a framework that requires one. If they cannot, the framework choice has already been made for you. ### 3. One-off versus streaming decisions A belief-style framework is naturally sequential: today's conclusion is the starting point for tomorrow's. For a team making the same class of decision every week over the same population, that accumulation is real value — knowledge carries forward instead of each readout starting from nothing. For genuinely isolated, non-repeating decisions the accumulation argument disappears, though the ability to speak about a one-off event at all remains a point in its favour. ### 4. What the audience must be able to act on Listen to how stakeholders ask their questions. "What is the probability this actually helps?" is a question about a parameter, and only a framework that gives the parameter a distribution answers it directly. If a leadership forum keeps asking that and keeps receiving answers about the behaviour of procedures, you have a persistent translation loss that shows up as decisions made on misread numbers. Either supply the framework that answers the question asked, or make it explicit and repeated what your reporting does and does not mean. ### 5. Organisational cost This is where senior judgment differs from technical preference. A prior is an explicit, attackable choice. In an adversarial setting — a team that wants its feature shipped, a review board looking for reasons to say no — the choice becomes a negotiation, and you need governance to make it credible: priors sourced from documented history, fixed before the data arrives, reviewed by someone with no stake in the outcome. A standardised procedure with no free parameter is more robust to bad-faith use, which is a genuine argument for it independent of any statistical merit. Also weigh what the organisation can maintain: reviewers, shared templates, and people who can explain the output to non-specialists. ## The recommendation I would actually make One default house style for the high-volume path, chosen for consistency and reviewability rather than elegance, because at that data volume the numbers agree anyway. A documented, reviewed belief-style route reserved for thin-data and cold-start decisions, where it changes the answer and the prior is defensible. A hard rule against mixing vocabularies inside a single readout, since the fastest way to produce a bad decision is a document whose numbers mean two different things on two different pages. And a review checkpoint for any decision where the prior visibly drives the conclusion. ## Anti-patterns to name - **Framework as identity.** Analysts choosing by allegiance rather than by the decision in front of them. - **Switching after seeing results.** Running one analysis, disliking the answer, running the other. This is the single most damaging pattern and only pre-commitment prevents it. - **Invented priors.** Informative priors with no documented provenance, especially when they point toward the conclusion the author wanted. - **Silent translation.** Reporting one framework's output while letting stakeholders read it in the other framework's language, and never correcting them. - **Debating frameworks instead of measurement.** On mature surfaces the larger error is usually the metric definition, the population, or instrumentation quality — not the inference style. ## How to deliver this in an interview Start by refusing the false binary and saying the choice depends on decision shape. Give the dimensions — data volume, availability of real prior information, one-off versus streaming, what the audience needs, governance cost. Make an actual recommendation rather than listing considerations, because principal-level questions are testing whether you will commit. Then name the failure mode you would police hardest: choosing the framework after seeing which one gives the preferred answer.