DoorDash Staff-Level Solutions Architect Interview Preparation Guide

Direct answer

An automated failover system for primary-replica pairs needs four pieces working together to minimize split-brain risk: a consensus-based health check (a majority, not a single observer, must agree the primary is actually down), fencing that guarantees the old primary cannot keep accepting writes once it loses leadership, a promotion-safety check that refuses to promote a replica too far behind, and an audit trail proving what happened and when. This is the same design pattern Patroni implements for PostgreSQL clusters, and it generalizes to any primary-replica system.

Architecture

flowchart TD
  A[Health check: primary missed N heartbeats] --> B{DCS quorum reachable?}
  B -->|no quorum| C[Do not promote: minority side, refuse writes]
  B -->|quorum reached| D[Elect candidate: most caught-up in-sync replica]
  D --> E[Fence old primary via watchdog/STONITH]
  E --> F{Fencing confirmed?}
  F -->|no| G[Abort promotion, alert on-call: cannot guarantee safety]
  F -->|yes| H[Promote candidate to primary]
  H --> I[Update DNS/service discovery to new primary]
  I --> J[Audit log: who/what promoted, at what LSN, data-loss window]
  J --> K[Old primary rejoins later as a follower once fencing is lifted]

Health checks. A single node observing "the primary didn't respond" is not enough evidence, since that node itself could be the one that is network-partitioned. Route the decision through a distributed configuration store (DCS: a small, separately-replicated coordination service such as etcd, Consul, or ZooKeeper) that requires a majority, or quorum, of its own members to agree before any leadership change proceeds; this is the same mechanism Patroni uses for PostgreSQL. If the surviving side of a partition cannot reach a majority of the DCS, it must not promote, even if it genuinely believes the primary is down, because it cannot distinguish "the primary is dead" from "I am the one who is isolated."

Fencing mechanisms. Before any promotion, the old primary must be guaranteed unable to keep accepting writes. Two layers, used together: revoke its ability to renew its leadership lease in the DCS (a soft fence: it should demote itself once it notices the lease expired), and a hardware or OS-level watchdog that forcibly resets the host if the soft fence has not been confirmed within a bounded time (a hard fence, sometimes called STONITH, "shoot the other node in the head"). The hard fence exists specifically for the case where the old primary is unresponsive rather than well-behaved, since a well-behaved node would have already demoted itself.

Promotion safety checks. Never promote a replica that is more than a defined, bounded amount behind the primary's last known position (measured by comparing log sequence numbers, LSNs). If the most caught-up available replica is still too far behind, the safer action is to alert and wait (accepting downtime) rather than promote and silently accept a larger-than-intended data loss; that threshold (how far behind is "too far") is a deliberate, pre-agreed trade-off between availability and data loss, not a default left unexamined.

Validating and auditing automatic promotions. Every automatic promotion writes an audit record: which node was promoted, what LSN it was at, what the old primary's last known LSN was (which bounds the data-loss window), and what triggered the decision. This is what turns "the system did something" into something a human can verify after the fact, and it is what a chaos-testing exercise (deliberately triggering failures in a controlled way, including in production during low-traffic windows, specifically to verify this pipeline works under realistic conditions rather than only in a lab) should be validating end-to-end, including checking that dependent services handling the failover (connection pools reconnecting, in-flight requests retried safely) do not cascade the failure outward.

Manual versus automatic failover: what data can be lost, and the RPO/RTO difference

Automatic failover is the right default for a well-tested, generic primary-down scenario, because RTO matters more than shaving the last few seconds of RPO for most services. Manual (or manual-confirmed) failover is worth keeping as an option, or even the default, for a scenario where the failure mode is ambiguous (a regional network partition isolating a meaningful fraction of followers, rather than a clean single-node crash), where an automated system cannot reliably distinguish "promote now" from "wait, this might resolve itself" and a wrong automatic decision (over-eager promotion during a transient blip) is worse than the extra minute a human takes to confirm.

Trade-offs and pitfalls

The most common design flaw is building the health check and the fencing mechanism as two independently-tuned systems that can disagree: a health check that decides to promote faster than the fencing mechanism can guarantee the old primary is actually stopped creates exactly the split-brain window the whole design exists to prevent. The second common flaw is never testing the failover path against a real, partial-partition scenario (only testing against a clean node crash), since a partition that isolates a meaningful fraction, not all, of the followers behaves very differently (some followers see a different quorum than others) than a simple full-node failure, and is the scenario most likely to expose a subtle bug in the promotion-safety logic.

Direct answer

Scoping a pilot means deliberately picking a subset where the signal will be clear and the blast radius (how many customers, accounts, or systems are actually touched if something goes wrong) small, defining success criteria and a genuine fallback before starting rather than after seeing how it goes, and deciding upfront what evidence would justify scaling rather than making that call on a gut feeling once the pilot is already running.

Structured elaboration

• Criteria for pilot scope: pick a subset that's representative of the real rollout, not the easiest possible case, and small enough that a failure is recoverable. The best pilot subset usually has the clearest existing pain, so the before-and-after comparison is unambiguous.
• Success metrics: define a small number of measurable criteria before starting, so "it worked" isn't decided after the fact based on whatever numbers happen to look good.
• Guardrails and fallback plan: keep the old process running in parallel rather than a hard cutover, and define an explicit rollback trigger, a specific failure condition that pauses the pilot automatically, not a judgment call made under pressure.
• Deciding whether and how to scale: set the go and no-go thresholds before the pilot starts, review against them at a set checkpoint, and scale incrementally, team by team or segment by segment, keeping the same fallback safety net at each stage rather than cutting over everywhere at once.

Worked example

A team wants to replace ad hoc chat-based incident alert triage with a dedicated alerting tool.

• Pilot scope: one team with the highest on-call load and the clearest existing pain, over a 4-week window, rather than piloting across every team at once.
• Success metrics defined upfront: reduce the median time-to-acknowledge an alert from around 12 minutes to under 5 minutes, with zero missed critical alerts, plus a short survey of on-call engineers on whether they'd want to keep it.
• Guardrails and fallback: the old process kept running in parallel rather than being switched off, and the rollback trigger was explicit: any missed critical alert due to a tool misconfiguration pauses the pilot and reverts to the prior process immediately, no discussion required in the moment.
• Scaling decision: the go and no-go thresholds were agreed before the pilot started, reviewed at the 4-week mark against actual results, and if met, the tool was rolled out to one additional team at a time, keeping the same parallel-fallback safety net at each stage.

Trade-offs and pitfalls

Picking the easiest team as the pilot instead of a representative one produces a result that looks great but doesn't generalize, undermining the whole point of piloting. Running a pilot without a real fallback effectively turns it into a full rollout with none of the pilot's safety, so any failure has full blast radius. Deciding go and no-go criteria only after seeing the results is the third common failure, since it invites picking whichever numbers happen to look good rather than an honest test.

Direct answer

Show the return as a before-and-after comparison on incidents the business already feels: faster detection and recovery means fewer minutes of customer impact and less engineer time per incident. Convert the minutes saved into dollars with the cost of downtime, subtract what the observability costs, and state the break-even. In the illustration below, saving 30 minutes per incident returns $7,600 a month net on $9,000 of monthly cost, and the investment breaks even at about 16 minutes saved per incident.

Definitions

Observability is the ability to see what the system is doing from its logs, metrics and traces so that you can find the cause of a problem quickly. MTTR (mean time to restore) is the average time from the start of an incident to recovery. Investing in observability mainly cuts the time to detect and diagnose, so it shortens MTTR.

Hypothetical example (illustrative numbers)

Inputs: 8 incidents a month, 5 of which affect customers; each customer-affecting hour costs $6,000 in lost profit and credits; 4 engineers respond to each incident at $100 per hour. Better dashboards and tracing are expected to cut 30 minutes from the time to restore every incident. Cost: $6,000 a month for the platform plus a quarter of an engineer's time ($3,000 a month), so $9,000 a month. A one-off instrumentation project costs $30,000.

Stating the break-even and the sensitivity

Each minute saved per incident is worth 5 x ($6,000 / 60) + 8 x 4 x ($100 / 60) = $553 a month. The $9,000 of monthly cost is covered at $9,000 / $553 = about 16.3 minutes saved per incident. If the improvement were only 10 minutes, the monthly benefit would be $5,533, below the $9,000 cost, so the investment would not pay. This is the honest statement to make to executives: the case rests on the minutes saved, so commit to measuring that number.

Making the claim credible

1. Baseline MTTR and the time to detect for the last two quarters, taken from the incident tracker, not recalled.
2. After the rollout, compare the same incident classes (not the easy ones), and report the change in median and slowest-decile recovery time.
3. Include benefits that are harder to price, such as incidents caught before customers saw them or fewer escalations at night, as separate, unpriced bullets, not folded into the dollar total.

Pitfalls

• Claiming the full cost of downtime as savings. Only the minutes saved count.
• Treating alerts as value: more alerts without a lower detection time is cost.
• Ignoring the ongoing cost of storing and querying telemetry, which can grow faster than traffic.

Direct answer

Put a circuit breaker around the model call and a fallback ladder behind it: first the model's own recent output for that zone and product (last-known-good, if younger than a few minutes), then a rule-based heuristic computed from live supply and demand, then the base price with no surge. Refusing to price is not on the ladder for normal traffic. Keep the fallback warm by computing it continuously in shadow (running it in parallel on live traffic and logging its output without ever serving it, so it is never cold when actually needed), not only when the model fails, and keep it consistent with the model by calibrating the heuristic against recent model output and clamping it to a band around the last model price. On recovery, move traffic back gradually and blend from heuristic price to model price over a few minutes so customers never see a jump caused by the switch itself.

Terms

• Circuit breaker: a wrapper that watches a dependency's error rate and, above a threshold, stops calling it for a cool-down (open state), then lets a few trial calls through (half-open) and resumes if they succeed (closed). It turns a slow, failing dependency into a fast, predictable fallback.
• Last-known-good: the most recent successful model output, cached per key.
• Heuristic: a simple deterministic formula, here a lookup table of multiplier by supply-to-demand ratio.

Comparing the three fallback options

I commit to cached price for up to 3 minutes, then the heuristic, with deny reserved for missing base data. Refusing to price because a demand-shaping model is down turns an optimisation outage into a full outage, which is the wrong trade for a marketplace.

Architecture

flowchart LR
  Req[Price request] --> Svc[Pricing API]
  Svc --> CB{Breaker closed?}
  CB -->|yes| Model[ML model service]
  CB -->|no| LKG{Last-known-good under 3 min?}
  LKG -->|yes| Cache[Cached model price]
  LKG -->|no| Heur[Calibrated heuristic]
  Signals[Live supply and demand] --> Heur
  Model --> Store[LKG store per zone and product]
  Model --> Calib[Calibration job]
  Calib --> Heur

Cache warm-up

A cold fallback is the classic failure: the model dies, every request falls through to an empty cache, and the heuristic has never run in production so nobody knows if it is sane.

• Write-through last-known-good: every successful model response writes its result into the per-zone, per-product LKG store. Because every busy zone is priced many times a minute, the store is always warm for the zones that matter.
• Shadow heuristic: the heuristic runs on every request (or every zone every minute) even while the model is healthy, and its output is logged next to the model's. It is therefore always computed from current signals, never cold, and its disagreement with the model is continuously measured.
• Node start-up: a new pricing node loads a snapshot of the LKG store and the heuristic's calibration table before accepting traffic, so a scale-out during a model outage does not create cold nodes.

Consistency between model and heuristic

Two prices for the same trip from two methods are inconsistent by nature. Three mechanisms keep the difference small and invisible:

1. Calibration: a job fits the heuristic's ratio-to-multiplier table to the model's recent outputs per city (for example, over the last 7 days, what multiplier did the model produce when supply-to-demand ratio was 0.7?). The heuristic is then a coarse approximation of the model rather than an independent opinion.
2. Clamping: the heuristic's output for a zone is clamped to within ±20% of that zone's last model multiplier for the first 15 minutes of an outage. Early in an outage the last model value is still informative; later, conditions drift and the clamp relaxes to the global caps.
3. Global guardrails apply to both paths identically: the same caps, floors and rule-engine overrides. A fallback must never escape a cap the model is held to.

Every quote carries a pricing_source field (model, lkg, heuristic, base) and the version used, so analytics and dispute handling can tell which path priced it. Quotes already issued are honoured whatever path produced them.

Re-syncing once the model recovers

1. Half-open probing: after the cool-down (say 30 seconds) the breaker lets 1% of requests call the model. Their results are not used yet; they are compared with the heuristic.
2. Health gate: the model must succeed on the probes and its outputs must be within a sanity band (not all 1.0, not all at the cap) for two minutes.
3. Ramp: 1%, then 10%, 50%, 100% of zones switch back, each step held for a minute and reverted automatically if error rates rise.
4. Price blending: for each zone, the served multiplier moves from the heuristic value to the model value over 5 minutes rather than jumping.

Worked example: zone Z has heuristic multiplier 1.30 when the model returns, and the model now says 1.80. Blending linearly over 5 one-minute steps gives:

A rider refreshing the app sees prices rise by at most 0.10 per minute, which reads as market movement, instead of a jump in one refresh caused purely by the system switching methods: (1.80 - 1.30) / 1.30 = 0.3846..., a jump of about 38%.

Breaker thresholds (starting values)

• Open when more than 20% of calls in a 10-second window fail or exceed the timeout, with at least 50 calls in the window (so a handful of errors in a quiet zone does not trip it).
• Model call timeout: the pricing API's latency budget minus its own work. If the API promises 150 ms and needs 30 ms for itself, that leaves 120 ms; give the model call a 100 ms timeout and keep the remaining 20 ms as margin for the rest of the request, not the default of a few seconds.
• Retries: at most one, and only within the deadline. Retrying a struggling model three times triples its load exactly when it is weakest.

Testing fallback correctness

A fallback that has never run is a hypothesis. How to prove it works:

• Unit and contract tests: for every rung, prices stay within caps and floors, currency and rounding are correct, and pricing_source is set.
• Fault injection in staging and production: make the model client return errors, hang past the timeout, or return garbage (all zeros, NaN) for a slice of traffic or a single city, and assert the breaker opens, the right rung serves, and latency stays within the SLO (service-level objective).
• Shadow comparison: because the heuristic runs continuously, you can report its error against the model every day (for example, median absolute difference in multiplier per city). If that grows, recalibrate before an outage needs it.
• Replay tests: replay a recorded hour of traffic with the model disabled and compare revenue, conversion and price distribution against the real hour.
• Game days: a scheduled exercise where the team deliberately disables the model in one city during a normal period and walks through the recovery and blending.

Trade-offs and pitfalls

• Treating "garbage output" as success: a model that returns 200 OK with a multiplier of 0 or 50 is unhealthy. Validate outputs, and count invalid outputs as failures for the breaker.
• A breaker per node opens at different times on different nodes, so users get different prices depending on which node served them. Share breaker state per region, or accept brief disagreement and rely on quote honouring.
• An LKG with no age limit keeps charging yesterday's surge. Enforce the 3-minute limit.
• What would change the design: where regulation caps prices strictly (for example, during a declared emergency), the fallback could be a flat, capped multiplier with no heuristic at all, because predictability then matters more than efficiency.

Direct answer

Map each feature to the store family whose native data model matches its dominant query pattern, not to whichever database the team already knows best. For a social platform: relational for authentication (small rows, strict uniqueness, ACID transactions), document for user profiles (flexible, per-user schema), a graph database for the friend-graph (multi-hop traversals), a wide-column or document store for posts and comments (high write volume, simple key-based access), and a columnar warehouse for analytics. The same reasoning generalizes to other domains: an e-commerce system maps catalog, inventory, sessions, and orders onto the same four families plus a NewSQL option, and any service-oriented system adds a messaging/distributed-log layer as a first-class store choice, not an afterthought.

Feature-to-store mapping (social platform)

Extending the mapping: e-commerce and a generic microservices system

The same four-family exercise applies to an e-commerce system's catalog, inventory, sessions, and orders, with one addition: NewSQL (a class of databases, such as Google Cloud Spanner or CockroachDB, that aim to keep full relational ACID guarantees while scaling out horizontally like a distributed system) becomes a genuine fourth candidate alongside relational, document, and key-value, specifically for orders and inventory, where a single-node relational database's scaling ceiling is a real constraint but the strict consistency requirement rules out a document or key-value store outright.

For a generic microservices system built around many independent services, the store-per-feature exercise needs one more explicit category: messaging and distributed-log systems (Kafka, or a cloud-managed equivalent) as a store choice in its own right, not just plumbing between the others. Services that need to publish "this happened" events for other services to consume, replay history, or decouple producers from consumers should be pointed at a log-structured message bus, the same deliberate way posts are pointed at a wide-column store. And when a feature's store choice comes down to a relational (or NewSQL) system, replication topology is itself a consistency and durability input to the decision, not a detail to leave to defaults: single-leader replication (one primary accepts writes, replicas apply them asynchronously or semi-synchronously) gives simple, strong consistency on the leader but a single point of write failure and potential replica lag; multi-leader replication (more than one node accepts writes, typically across regions) trades that away for lower write latency close to each region and higher availability during a regional outage, at the cost of needing an explicit conflict-resolution strategy (last-write-wins, application-level merge, or CRDTs) for writes that collide. Authentication and orders, where a duplicate or conflicting write is a real bug, default to single-leader; a multi-region session store or a shopping cart, where "last write wins" is an acceptable resolution, is a much safer place to accept multi-leader's trade-offs.

Trade-offs and pitfalls

• The graph database is the easiest one to over- or under-justify. For "friends of friends" at a few hops, a graph engine is a genuine, large win over relational joins. But if the actual query pattern is closer to "show a list of my direct connections," a relational adjacency table with a good index is simpler to operate and doesn't need to be justified at all; don't reach for a graph database on the strength of the word "friend-graph" alone without checking how many hops the real queries need.
• Every store split adds a synchronization problem. Posts written to the wide-column store still need to reach the search index and the analytics warehouse; that's another CDC pipeline to build, monitor, and alert on for lag, same as the catalog example above.
• NewSQL is not a free upgrade. It buys horizontal write scaling with relational guarantees, but at higher write latency per transaction than a well-tuned single-node relational primary, because committing a transaction now means coordinating across nodes. Reach for it only once a single relational primary is the actual, measured bottleneck, not preemptively.
• Multi-leader replication is a correctness decision, not a performance knob. Turning it on without an explicit conflict-resolution rule for every write path that can touch the same row from two regions is how silent data corruption gets into production.

Direct answer
Proving blameless postmortems causally reduce recurrence, rather than assuming it, requires comparing incident outcomes between groups that did and did not receive the full blameless-postmortem treatment, while controlling for the fact that incidents are relatively rare, which makes a small, underpowered comparison unreliable.

Structured elaboration

• Define the primary metric precisely. Incident recurrence rate for the same or closely related failure category within a defined window (say, six months) after a postmortem, and mean-time-to-recovery for any recurrence that does happen, are both reasonable primary outcomes.
• Form comparison groups given low incident frequency. A staggered rollout across teams (some teams adopt full blameless postmortems now, others adopt a few months later) gives you a natural comparison without denying anyone the practice indefinitely, and it's more feasible than a strict randomized controlled trial in most organizations. Alternatively, compare incident classes that received a full postmortem against similar-severity incident classes from before the practice was adopted, using the organization's own history as the comparison.
• Account for low frequency directly. Because a single team's incident count is small, aggregate across many teams or many incident categories to get enough statistical power, and be honest that with genuinely rare, high-severity incidents, you may only be able to speak confidently about a proxy (like recurrence of the underlying vulnerability class in code review or testing) rather than recurrence of an actual outage.
• Control for confounders explicitly. Teams that adopt blameless postmortems early are often also the teams already investing more broadly in reliability practices, so any observed improvement could be due to that general investment rather than the postmortem practice specifically; a staggered rollout across otherwise-similar teams helps isolate this, and tracking a secondary metric less directly tied to postmortems (like general code quality trends) as a check helps rule out a confound affecting everything at once.
• Report the honest limitation. Even a well-designed study in this space will likely have wide confidence intervals given how rare severe incidents genuinely are; report that uncertainty rather than overstating confidence in a clean causal result.

Worked example
An organization with 40 teams rolls out mandatory blameless postmortems to half the teams (chosen to be broadly similar in size and incident history) starting this quarter, with the other half adopting the practice three months later. Primary metric: recurrence rate of a related incident category within six months of any postmortem-eligible incident. After the study window, teams in the early-adoption group show a lower recurrence rate than the later-adoption group during the period before the second group adopted the practice, and the gap narrows once the second group also adopts it, which is more convincing evidence of a causal effect than a simple before-and-after comparison on a single group would have been, since it rules out a general org-wide trend as the sole explanation.

Trade-offs and pitfalls
The most common mistake is treating a simple before-and-after comparison on one group as proof of causation, when it's equally consistent with unrelated organizational improvements happening over the same period. A second is understating how much statistical power genuinely rare, severe incidents cost you, and presenting a result with far more confidence than the small sample size actually supports.

Direct answer

Placing real people on a power/interest grid means separating their FORMAL authority from their actual DAY-TO-DAY engagement, and the quadrant should drive a specific, different engagement plan for each person, not just a label.

Structured elaboration

Given an executive sponsor who rarely engages day to day, a compliance lead who must approve any change but has limited ongoing interest, a hands-on technical lead who uses the output constantly, and a vocal mid-level manager with little formal authority:

• Executive sponsor: high power (can kill or fund the initiative), low day-to-day interest. Quadrant: keep satisfied. Engagement: infrequent, high-level updates focused on risk and outcome, not process detail; don't overload them or they'll disengage further.
• Compliance lead: high power (a required approval gate), low day-to-day interest until something needs their sign-off. Quadrant: keep satisfied, with a specific trigger: proactively loop them in well before any approval deadline, since low interest doesn't mean low importance when the gate arrives.
• Hands-on technical lead: their formal power over the DECISION may be limited, but their interest and practical influence over EXECUTION is high. Quadrant: manage closely. Engagement: frequent, detailed, working-level.
• Vocal mid-level manager: high interest, genuinely low formal power. Quadrant: keep informed. Engagement: regular updates so they feel heard and don't create friction through unofficial channels, but without giving them decision authority they don't hold.

Worked example

If this initiative hits a scope change, the compliance lead needs to be told IMMEDIATELY even though their day-to-day interest is low, because a late surprise at their approval gate is the single most common way "keep satisfied" stakeholders escalate to angry. The vocal manager, by contrast, can be told on the normal cadence: their concern is being heard, not approving anything, so a slight delay in updating them is lower-risk than the same delay would be for the compliance lead.

Trade-offs and pitfalls

The grid is a starting classification, not a permanent one: the vocal manager's formal power can change with a reorg, and the executive sponsor's interest can spike if the initiative becomes politically visible. Treat the initial placement as a hypothesis to revisit, not a one-time exercise.

Direct answer

Spend the first hours on questions, not drawing. Produce a small, honest package: a context and container diagram, a two to three page narrative, an assumption log, an indicative estimate as a range, and a list of open questions. Stamp all of it as pre-sales and non-binding, and keep commitments for the signed contract after design work. A container diagram shows the deployable pieces (web app, API, database) and how they talk. The open questions list is the written set of things you could not confirm, each with an owner. A design narrative is the short prose that explains what the diagrams show and why. Pre-sales is the work done before a contract exists.

How the 48 hours run

What to ask the client

• Outcome: what changes for the business if this works, and what is the success measure?
• Users and volumes: who, how many at peak, growth expectations.
• Existing systems to integrate with and the interfaces they offer.
• Data: types, sensitivity, where it must live.
• Availability and recovery expectations, in their words.
• Constraints: preferred cloud, compliance rules, deadlines, budget band, and who decides.

The assumption log (illustrative rows)

Each assumption is a testable sentence with an owner to confirm it and a stated consequence. The confidence column is a plain label (High, Medium, Low) for how sure you are; anything Low is the first thing to chase.

Sample open-questions list (illustrative)

• Q1: Can the existing identity provider issue tokens to our API? Owner: client IT lead. Needed by: hour 30.
• Q2: Is the 2,000 peak users a measured figure or a guess? Owner: client product owner.
• Q3: Which regulator's rules apply to the customer data? Owner: client compliance.

Sample narrative opening (illustrative)

"We propose a web application and API hosted in the EU, integrating with your existing order system. This concept rests on 11 assumptions listed in Appendix A; three are unconfirmed and could change the estimate. Nothing here is a commitment."

Separating estimate from commitment

• Give ranges with a three-point estimate. A person-week is one person working for one week. Example: optimistic 10, most likely 14, pessimistic 24 person-weeks gives (10 + 4 x 14 + 24) / 6 = 90 / 6 = 15 weighted. The most-likely value gets weight 4 because it is the outcome you believe in most, and the two extremes get weight 1 each, so the weights total 1 + 4 + 1 = 6, which is why you divide by 6. The result (15) is a planning midpoint that sits above the most-likely 14 because the pessimistic tail is longer. Quote the range, not the midpoint: "roughly 10 to 24 person-weeks, low confidence", with the weighted 15 as the internal planning figure only.
• Put a stamp on every page: "Pre-sales concept. Indicative only. Valid for 30 days. Not a design of record."
• A visible "what this does not include" list.
• SLAs, fixed prices and delivery dates appear only in the signed statement of work (the contract document that lists deliverables, price and dates), after discovery and a security review (a formal check of the design by the security team, treated as a gate before any commitment).
• Validity means the period the offer stays open (here 30 days); after it, the estimate must be redone. A peer review means a second architect reads the package for gaps before it goes out.

Pitfalls

• A polished diagram that looks final. Polish signals commitment, so label it.
• Unwritten assumptions. Every silent assumption becomes a dispute later.
• Answering an estimate request with one number.

Direct answer

A strong answer shows you built a case, not just found a number. You named the default decision that was about to happen without evidence, matched the weight of evidence to how reversible the decision was and how much time you had, triangulated quantitative and qualitative signal so the "what" and the "why" both showed up, and packaged the result as a decision artifact the stakeholder could act on, not a data dump they had to interpret themselves.

Structured elaboration

Anatomy of an evidence-based case:

1. Name the default. Say plainly what decision is about to happen and why (usually intuition, urgency, or one compelling anecdote), so the room can see the gap you're filling.
2. Match evidence weight to reversibility and time. An irreversible, expensive decision earns more rigor; a near-term deadline earns the fastest credible signal, not the most rigorous one.
3. Triangulate. Quantitative data shows what is happening; qualitative signal (interviews, quotes, support tickets) shows why. Either alone invites the obvious rebuttal ("that's just anecdotes" or "the numbers don't say why").
4. Package for the audience. A one-page decision memo or a single slide often does more persuasive work than another week of analysis.

Worked calculation: honest uncertainty. Say a pilot of 200 users produced 30 conversions ($\hat p = 0.15$). Reporting the point estimate alone overstates confidence; a senior candidate reports a confidence interval instead, a range you can say you are 95% sure the true value falls in, rather than presenting one number as if it were exact. The 1.96 is the cutoff that corresponds to 95% confidence under a normal approximation (the assumption that many possible outcomes cluster into the familiar bell-curve shape, where about 95% of that curve falls within 1.96 standard errors of the estimate), and the term under the square root is the standard error, a measure of how much this estimate would move around if the pilot were rerun on a fresh sample:

Saying "10% to 20%, most likely around 15%" instead of a bare "15%" is what separates a credible business case from a fabricated-precision one, and it pre-empts the "is this even real" objection a numerate stakeholder will raise.

Same move, different packaging. This competency shows up in many shapes across roles, and the table below is a reference, not a checklist to work through row by row: skim it once for the pattern, then treat the worked example further down as the one version you actually need to know cold. The underlying move (evidence proportional to stakes, triangulated, packaged to persuade) stays the same in every row:

Worked example

Situation. At a mid-size B2B platform team, leadership was two weeks from locking next quarter's roadmap around a reporting-and-analytics overhaul, driven by one executive's belief that power users needed deeper reports to upgrade. Meanwhile, early trial cancellations were climbing and nobody had looked at why.

Stakes. Committing a full quarter of engineering capacity to the wrong bet, while trial users kept leaving faster than new demand could replace them, would have made growth slower, not faster, than the reporting bet was even meant to fix.

The influence moves.

• Named the default out loud, as a factual gap rather than an accusation: the roadmap was currently being decided on one executive's hypothesis with no supporting signal.
• Matched evidence to the window: with only ten days before the roadmap locked, pulled existing product-analytics event data (already collected, no new instrumentation needed) and ran a short opt-in exit survey to the last 60 days of canceled trials.
• Triangulated: the event data showed where in onboarding users dropped off; the survey free-text explained why. Of 40 respondents, 27 cited setup and configuration confusion as their reason for leaving ($27 \div 40 = 0.675$, about 68%), not a missing feature.
• Packaged it as a one-page decision brief: one paragraph stating the ask ("delay the reporting overhaul one quarter, fix onboarding setup friction instead") plus a short evidence appendix (the funnel chart and three verbatim quotes), not a slide-by-slide walkthrough.
• Sized the ask to the evidence: proposed a two-week spike to fix the worst setup step and re-measure, rather than asking for a permanent reroute of the whole quarter on ten days of analysis.

Resolution. Leadership approved the two-week spike before the roadmap locked. The evidence was credible enough that the original executive co-sponsored the change instead of contesting it.

What a senior candidate does differently. A mid-level candidate stops once the numbers "prove" the point. A senior candidate also stages the ask so it's proportionate to how much evidence they actually had, and brings the original stakeholder along as a co-sponsor rather than a defeated opponent, which is what protects the relationship for the next disagreement.

Trade-offs and pitfalls

• Rigor vs. speed. Over-investing in statistical proof for a reversible, low-stakes call wastes the one resource (time and goodwill) that a genuinely irreversible call actually needs.
• Data dump vs. artifact. A wall of dashboards is not persuasive on its own; the packaging (one slide, a two-part memo) often does more work than an extra week of analysis.
• Causal overclaim. Claiming a change "caused" a metric improvement without ruling out confounders (seasonality, concurrent launches) is the fastest way to lose credibility with a numerate stakeholder. Name the confidence and the caveats instead of hiding them.
• Thin-signal cases. Treat a severe but thin (n<10) signal as grounds for a bounded, reversible action (a pilot, a spike), not a full commitment. Conflating "worth investigating now" with "proven" is a common junior mistake.

Direct answer
For a 100-engineer organization, the three common team-ownership models are service-per-team (each team owns a small, dedicated set of services end to end), feature teams sharing services (cross-functional teams that ship features but don't uniquely own the services they touch), and a dedicated platform team (owning shared infrastructure that every other team builds on); most organizations at this size end up needing a combination, service-per-team for product-facing services plus a platform team for shared concerns, rather than picking one model exclusively.

Structured elaboration
Service-per-team gives the clearest accountability (one team, one on-call rotation, one release cadence per service) and the strongest Conway's Law alignment, but it can lead to duplicated effort across teams solving similar infrastructure problems independently, and it struggles when a feature genuinely needs coordinated changes across several services owned by different teams. Feature teams sharing services optimize for shipping cross-cutting product features quickly, since a team can touch whatever services a feature needs without waiting on another team's roadmap, but they create ambiguous ownership (who's on-call when a shared service breaks, whose roadmap does a needed change compete against) and tend to erode the clean boundaries a service-per-team model would otherwise maintain. A platform-team model centralizes shared infrastructure (deployment pipelines, observability, core libraries) so product teams don't each reinvent it, but if under-resourced relative to demand, it becomes a bottleneck every other team is waiting on.

Worked example
A workable combination at 100 engineers: organize the majority of engineers into a handful of product-facing teams, each owning a small, clear set of services end to end (service-per-team for ownership and on-call clarity), carve out one platform team (perhaps 10-15% of headcount) providing the shared deployment, observability, and core-library tooling every product team depends on, and use temporary, cross-team "feature squads" only for genuinely cross-cutting initiatives that need coordinated changes across several product teams' services, disbanding them once the initiative ships rather than making shared, ambiguous ownership permanent.

Trade-offs and pitfalls
Governance needs to track which model a given piece of work actually fits: a well-understood, product-facing feature fits cleanly inside one team's service-per-team ownership; a genuinely cross-cutting initiative (say, adding a new compliance requirement across every service) needs either a temporary cross-team squad or, if it recurs often enough, its own dedicated team. Shared libraries are a common pitfall regardless of model: without a clear owner and a versioning discipline, a shared library becomes either everyone's problem (nobody prioritizes fixing it) or a de facto dependency that quietly recouples otherwise-independent services, since a breaking change to the shared library now has to be coordinated across every team using it, the same coordination cost service-per-team was meant to avoid.