Zillow interview questions & answers

Model answer

Situation — I manage up and down by treating communication as part of execution, not as status theater. For example, my team was delivering a customer migration while leadership had committed to a date that depended on an external data contract. The engineers were worried the date was unrealistic, while executives wanted a clear answer and the product team needed a plan they could communicate to customers.

Task — I needed to give leadership an honest forecast and options, while giving the team enough context and focus to make progress. I also needed to avoid turning uncertainty into either false confidence or unnecessary alarm.

Action

• I first built a shared view of the facts with the tech lead and product manager: remaining work, external dependencies, confidence by milestone, and the impact of different scope choices. I distinguished what we knew from what we were assuming.
• Upward, I communicated in terms of business outcomes and decisions needed. I gave my director a concise update: the committed date was at risk because the partner contract was unconfirmed; we could preserve the date with a narrower migration, or preserve scope with a later date. I made a recommendation and stated what evidence would change it.
• Downward, I shared the why behind the priority and the constraints, then asked the team to identify technical risks and sequence work. I did not pass down pressure as urgency without context. We agreed on owners and a short check-in cadence while the dependency was unresolved.
• I kept product, support, and the partner team aligned through one written source of truth. When the contract slipped, I updated the forecast immediately and explained the customer impact rather than letting different groups circulate different dates.
• In one-on-ones, I checked whether the plan was creating unsustainable load and moved unrelated work where needed.

Result — Leadership chose the narrower launch, and we met the customer-facing date without compromising the migration’s core safety checks. The team had fewer last-minute escalations, and customer-facing partners could set expectations consistently. My lesson is that managing up means surfacing risks with options and a recommendation; managing down means translating strategy into clarity, ownership, and psychological safety. I adjust the level of detail to the audience, but I do not change the underlying facts.

What interviewers listen for

• Candor and useful recommendations, not just escalation.
• Clear context and empowerment for the team.
• Consistent communication across stakeholders.

Model answer

Situation

In a hypothetical example I would adapt to my own experience, a team was preparing a data-driven feature that used sensitive user or neighborhood information. During review, I noticed that one proposed attribute could create a privacy or fair-housing concern, and the feature was close to a launch date. The risk was not only policy noncompliance; it was also loss of user trust and potential harm to people affected by the product.

Task

I needed to make the concern concrete, protect users, and help the team reach a safe decision without treating schedule pressure as a reason to bypass policy. I also needed to avoid making a legal or ethics determination outside my role.

Action

• I first checked the current internal policy and documented the exact data field, intended use, affected user groups, and the decision the feature would make. I separated observed facts from assumptions.
• I raised the concern promptly with the product and engineering leads, framing it as a product and trust risk rather than accusing an individual of bad intent.
• I asked the appropriate privacy, legal, compliance, or ethics partners to review the use case. I brought a concrete data-flow diagram and examples so the review could address actual collection, access, retention, and downstream use.
• I proposed safer alternatives, such as removing the sensitive attribute, using a less granular signal, limiting access, or delaying the affected capability while preserving unrelated launch work.
• I made the decision and its rationale visible in the design record, added tests or controls for the agreed constraints, and ensured there was an owner for monitoring after launch. If the concern had remained unresolved, I would have escalated through the established channel rather than quietly shipping it.

Result

The example's desired outcome is a documented decision that protects users, gives the team a compliant path forward, and avoids an unreviewed launch; in an interview, I would replace this with the actual outcome and evidence from my experience. I would explain the measurable follow-through—for example, a removed data field, reduced access scope, completed review, or audit finding closed. My principle is to surface concerns early, use the right experts, and make the safest viable path easier for the team to execute.

What interviewers listen for: sound judgment under deadline pressure, respect for policy and escalation channels, protection of users, and constructive collaboration rather than either silent compliance or unsupported accusations.

Model answer

Situation

During a platform launch, a senior stakeholder proposed moving the release forward to align with a major customer event. The requested date left little time for a load test and a failure-recovery rehearsal. Engineering had identified a credible risk: the service might meet normal traffic needs but fail under the expected event-day peak. The stakeholder had strong reasons for wanting the date, so I needed to challenge the plan without dismissing the business goal.

Task

I owned the cross-functional readiness plan and needed to make sure the launch decision reflected customer impact, operational risk, and the value of the event date. My goal was to find the safest viable path, not to win an argument or automatically block the launch.

Action

• I first spoke with the engineering and operations leads to validate the risk and distinguish known facts from worst-case assumptions. I asked what evidence would change their recommendation and what mitigations were feasible within the remaining time.
• I then met with the stakeholder directly, acknowledged the value of the event, and explained the specific failure mode in customer terms. I avoided presenting “engineering says no” as the rationale.
• I brought options: keep the date but limit traffic through a controlled cohort; keep the full audience and move the date; or proceed only after a time-boxed load test and recovery rehearsal passed defined thresholds.
• I recommended the controlled launch, with a feature flag, a rollback owner, live monitoring, and a clear stop condition. For example, we would halt expansion if error rate or latency crossed the agreed guardrail.
• I documented the decision and asked the stakeholder to confirm the accepted residual risk. I also gave the team a single escalation path during launch so new evidence could trigger a quick decision rather than a prolonged approval chain.

Result

We met the customer event with a limited release, validated the service under real traffic, and expanded only after the readiness checks passed. The launch avoided a broad customer-impacting incident, and the stakeholder remained engaged because the proposal protected the event’s core value. I learned that effective pushback combines respect for the stakeholder’s objective with clear evidence, alternatives, and an explicit risk decision.

What interviewers listen for

• Ability to disagree upward with composure and evidence.
• Judgment about reversible options, launch gates, and customer risk.
• A clear recommendation and documented decision—not escalation as a substitute for leadership.

Model answer

Situation

On a multi-team platform program, a sponsor wanted to keep the original launch date while also adding a significant feature request. At the same time, two critical engineering teams had lost capacity to an urgent production issue. The sponsor’s goal was understandable: the launch was tied to a customer commitment. But pretending we could deliver everything safely would have created a reliability and credibility risk.

Task

I needed to make the capacity constraint explicit, preserve the most important business outcome, and help the sponsor make a timely decision without turning the conversation into a debate about whose team was responsible.

Action

• I prepared a fact-based view of remaining work, named dependencies, team capacity, and the impact of the production issue. I separated estimates from assumptions so we could identify what was genuinely uncertain.
• I framed the conversation around outcomes and choices, not a flat “no.” I presented three options: hold the date and reduce scope to the launch-critical path; retain the full scope and move the date; or add capacity, while clearly stating the onboarding cost and the work that capacity would displace.
• I made the risks concrete. For example, shipping without the required load test would leave a known peak-traffic failure mode unvalidated; it was not simply a schedule preference from engineering.
• I asked the sponsor to rank the customer commitment, feature breadth, and operational readiness. When the sponsor favored the date, I proposed a staged release: deliver the core workflow first, gate exposure behind a feature flag, and schedule the additional feature for a later increment.
• I documented the decision, assumptions, owners, and revisit triggers. I also checked in with the affected team leads afterward so the agreed plan translated into realistic commitments rather than pressure to absorb invisible overtime.

Result

We kept the externally important date by narrowing the first release, completed the safety checks, and delivered the deferred feature in the next increment. The sponsor had a clear view of what changed and why, and the teams avoided making a promise that depended on unplanned capacity. I learned that difficult trade-off conversations go better when I bring options, evidence, and a recommendation—not just a problem.

What interviewers listen for

• Respectful candor with senior stakeholders.
• Transparent capacity, risk, and opportunity-cost analysis.
• A recommendation that protects outcomes without hiding trade-offs.

Model answer

Situation — I managed an enterprise customer whose checkout integration experienced elevated latency during a peak period. The customer’s operations lead was understandably angry: orders were backing up, their support team was overwhelmed, and the issue affected a business-critical workflow. I was the TPM coordinating the response across engineering, support, and the account team.

Task — I needed to restore service, give the customer reliable information, and protect the working relationship without promising a cause or resolution time we could not verify. I also needed to keep the internal response focused despite the pressure.

Action

• I let the customer explain the impact without interrupting, acknowledged the business consequences, and summarized what I had heard to confirm we were aligned. I stayed calm and separated the urgency of the issue from the intensity of the conversation.
• I established a clear incident channel and named owners for diagnosis, mitigation, customer updates, and account coordination. We treated recovery as the priority and deferred unrelated work.
• I gave the customer a predictable update cadence—even when we had no new root-cause information—and clearly distinguished confirmed facts, current hypotheses, and next steps. I offered a safe workaround only after engineering validated its risks.
• When the conversation became personal, I calmly set a boundary: I wanted to resolve the issue and would stay engaged, but we needed to keep the discussion respectful. I then redirected us to impact, decisions, and next update time.
• After mitigation, I coordinated a blameless review with the customer-facing teams and engineering. We agreed on corrective actions, owners, and dates, including an alerting improvement and a tested fallback path.

Result — Service recovered within the incident window, and the customer resumed normal processing. In a similar real example, I would include the verified measures—for instance, time to mitigation, affected transactions, and whether repeat incidents declined—rather than rely on sentiment alone. The follow-up review also gave the customer a concrete view of what changed and how we would detect recurrence. I learned that empathy matters most when paired with clear ownership, honest uncertainty, and a dependable communication rhythm.

What interviewers listen for

• De-escalation without defensiveness or unsupported promises.
• Incident leadership, customer empathy, and clear ownership.
• Appropriate boundaries and a measurable follow-through plan.

Model answer

Situation — I once had a significant disagreement with a senior engineer about how to address a recurring reliability problem. They wanted to rewrite a stateful service before adding more features; product wanted to ship a high-value customer capability that quarter. Both positions were reasonable: the service had caused incidents, but the rewrite had uncertain scope and delayed visible customer value.

Task — I was responsible for resolving the disagreement in a way that protected customers, respected technical expertise, and gave product a credible plan. My goal was not to win an argument; it was to make a decision using shared evidence and clear ownership.

Action

• I spoke with the engineer privately first. I asked them to walk me through the failure modes and what evidence made a rewrite necessary. I acknowledged the operational burden they had been carrying rather than treating their concern as resistance to delivery.
• I then brought the engineer, product manager, and tech lead together. I framed the discussion around customer and business risk: incident frequency, time to recover, feature impact, and the cost of delaying the rewrite.
• We compared options: continue as-is, perform a full rewrite, or reduce the most dangerous failure modes with targeted changes while designing the feature to avoid the fragile path. We agreed on explicit criteria rather than arguing from preference.
• I asked the team to instrument the failure points and time-box a technical spike. The evidence showed that most incidents came from one retry and recovery path, not the whole service. I recommended fixing that path first, adding a runbook and alert, then shipping the feature behind a gradual rollout.
• I documented the decision, risks, owners, and conditions that would trigger reconsidering a broader rewrite. I also made sure the engineer had time to lead the reliability work and that product understood the remaining risk.

Result — We addressed the primary incident cause, launched the customer capability within the quarter, and avoided committing to a rewrite whose benefits were not yet justified. The service then went several months without a repeat of that failure mode. The engineer remained engaged because their concern was taken seriously and translated into action. I learned to separate disagreement about solutions from alignment on the problem, and to make decisions reversible where possible.

What interviewers listen for

• Respectful listening and fact-based resolution.
• A clear decision process, not conflict avoidance.
• Follow-through, measurable impact, and preserved trust.

Model answer

The specific linked-list task is not stated, so I would clarify it before coding. To demonstrate the expected approach without implementing a list or node class, assume the task is to detect whether a supplied singly linked list has a cycle. The function accepts the caller's existing head node and uses its next field.

/**
 * Detect a cycle in a singly linked list.
 * Expects the caller's nodes to expose a `next` property.
 * Does not create or implement a linked-list type.
 */
function hasCycle(head) {
  let slow = head;
  let fast = head;

  while (fast !== null && fast.next !== null) {
    slow = slow.next;       // Advance one link.
    fast = fast.next.next;  // Advance two links.

    if (slow === fast) {
      return true;
    }
  }

  return false;
}

• The fast pointer eventually catches the slow pointer if a cycle exists; otherwise, it reaches null.
• No extra data structure or list implementation is needed. Confirm the input node contract and null representation in the interview.
• Complexity: O(n) time and O(1) extra space.

Model answer

function findSurvivor(numbers, stepSize) {
  if (!Array.isArray(numbers) || numbers.length === 0) {
    throw new TypeError("numbers must be a non-empty array");
  }
  if (!Number.isSafeInteger(stepSize) || stepSize < 1) {
    throw new RangeError("stepSize must be a positive safe integer");
  }

  // Josephus recurrence: the survivor's index for size n is
  // (the survivor's index for size n - 1, shifted by stepSize) modulo n.
  let survivorIndex = 0;
  for (let size = 1; size <= numbers.length; size += 1) {
    survivorIndex = (survivorIndex + stepSize) % size;
  }

  return numbers[survivorIndex];
}

// Example: counting every third element leaves 40.
console.log(findSurvivor([10, 20, 30, 40, 50], 3));

• Treat stepSize as counting the current element as 1; the recurrence returns the same survivor as repeated circular elimination.
• Keep the input array unchanged and calculate only the final index, rather than repeatedly removing elements.

Complexity: O(n) time, O(1) extra space, where n is the number of elements.

Model answer

I’ll make the problem concrete by assuming the task is: count contiguous subarrays containing exactly k distinct values. This is a good hard-array pattern because the direct approach is quadratic, while a sliding-window invariant gives a linear solution.

function subarraysWithKDistinct(nums, k) {
  if (k <= 0) return 0;

  // Exactly k distinct = atMost(k) - atMost(k - 1).
  return countAtMost(nums, k) - countAtMost(nums, k - 1);
}

function countAtMost(nums, limit) {
  if (limit < 0) return 0;

  const frequency = new Map();
  let left = 0;
  let total = 0;

  for (let right = 0; right < nums.length; right++) {
    const value = nums[right];
    frequency.set(value, (frequency.get(value) || 0) + 1);

    // Restore the invariant: the window has at most `limit` distinct values.
    while (frequency.size > limit) {
      const outgoing = nums[left++];
      const remaining = frequency.get(outgoing) - 1;
      if (remaining === 0) frequency.delete(outgoing);
      else frequency.set(outgoing, remaining);
    }

    // Every suffix ending at `right` and starting in [left, right] is valid.
    total += right - left + 1;
  }

  return total;
}

• For each right endpoint, countAtMost counts all valid windows ending there.
• Subtracting counts with at most k - 1 distinct values leaves exactly k.
• Complexity: O(n) expected time and O(k) space for the active window.

Model answer

First Missing Positive

Given an unsorted integer array, return the smallest positive integer that does not appear in it. The target is O(n) time and O(1) extra space.

/**
 * @param {number[]} nums
 * @return {number}
 */
function firstMissingPositive(nums) {
  const n = nums.length;

  // Put each value x in position x - 1, when x is in [1, n].
  for (let i = 0; i < n; i++) {
    while (
      nums[i] >= 1 &&
      nums[i] <= n &&
      nums[nums[i] - 1] !== nums[i]
    ) {
      const targetIndex = nums[i] - 1;
      [nums[i], nums[targetIndex]] = [nums[targetIndex], nums[i]];
    }
  }

  // The first position that does not contain its expected value
  // identifies the smallest missing positive.
  for (let i = 0; i < n; i++) {
    if (nums[i] !== i + 1) {
      return i + 1;
    }
  }

  return n + 1;
}

// Examples:
console.log(firstMissingPositive([1, 2, 0])); // 3
console.log(firstMissingPositive([3, 4, -1, 1])); // 2
console.log(firstMissingPositive([7, 8, 9, 11, 12])); // 1

• Approach: The answer must be between 1 and n + 1. Place each in-range value x at index x - 1; then scan for the first mismatch.
• The while loop handles multiple swaps at one index. The duplicate-value guard prevents an infinite loop.

Complexity: O(n) time, O(1) extra space. The array is modified in place.

Model answer

I’d make an open-ended prompt tractable by clarifying the goal, identifying the dominant workload, and then making explicit, revisable assumptions. To show the process concretely, I’ll use a URL shortener as an example rather than pretend an unspecified product has fixed requirements.

1. Requirements & scale

• Functional: create a short URL, redirect to the original URL, optionally support custom aliases and expiration, and provide basic click analytics.
• Non-functional: redirects should be highly available and fast; creation should be durable; abuse prevention and privacy matter.
• Clarify whether aliases must be globally unique, whether links can be edited or deleted, and whether analytics must be real time. These choices change the design.
• Illustrative scale: 100M new links/month is about 40 writes/s average; at a 10x peak, about 400 writes/s. If each link gets 100 redirects/month, that is roughly 4,000 reads/s average and 40,000 reads/s peak. At 500 bytes per mapping, five years of 6B links is about 3 TB raw, before indexes and replication.

2. High-level architecture

flowchart TD
  subgraph Client["Client"]
    U["Browser / App"]
  end
  subgraph Edge["Edge / CDN"]
    E["Redirect cache"]
  end
  subgraph LB["Load Balancer"]
    L["Regional router"]
  end
  subgraph API["API / Services"]
    C["Create API"]
    R["Redirect service"]
    A["Analytics API"]
  end
  subgraph Cache["Cache"]
    K["Mapping cache"]
  end
  subgraph DB["Datastores"]
    D["Sharded mapping store"]
    S["Analytics warehouse"]
  end
  subgraph MQ["Message Queue"]
    Q["Click events"]
  end
  subgraph Workers["Workers"]
    W["Event aggregators"]
  end
  U -->|"redirect request"| E
  E -->|"cache miss"| L
  L --> R
  U -->|"create request"| L
  L --> C
  R -->|"lookup"| K
  K -->|"miss"| D
  C -->|"write mapping"| D
  R -->|"click event"| Q
  Q --> W
  W --> S
  L --> A
  A --> S

• I’d first deliver the simplest design that meets the redirect latency and durability goals, then add regional complexity only when measured traffic requires it.

3. API design

• POST /v1/links — create a link; accept url, optional customAlias, and optional expiresAt; return shortUrl and link ID.
• GET /{code} — redirect with 302 by default; use 301 only if links are immutable and long-lived.
• GET /v1/links/{id}/analytics?from=&to= — retrieve aggregated counts for an authorized owner.
• Use idempotency keys for retried create requests. Validate schemes and reject unsafe destinations.

4. Data model & storage

• Mapping record: code (primary key), url, ownerId, createdAt, expiresAt, status, and optional version.
• Store mappings in a durable, horizontally partitioned key-value or NoSQL store, partitioned by code; redirect lookup is the dominant access pattern.
• Keep hot mappings in a TTL cache. Store click events in a queue and aggregates in an analytical store, rather than making redirects wait for analytics writes.

5. Deep dive

• Generate a random, collision-resistant code or allocate IDs and encode them. For random codes, check uniqueness at write time and retry on collision; never assume collision probability is zero.
• Redirect flow: normalize and validate the code, check cache, read the mapping on miss, verify expiry/status, populate cache, return redirect, and publish a click event asynchronously.
• Set cache TTL no longer than the link’s remaining lifetime. Negative-cache unknown codes briefly to reduce repeated misses, while avoiding long-lived stale negatives after creation.
• Protect the public creation endpoint with quotas, abuse detection, safe-browsing checks, and per-account limits.

6. Scale, bottlenecks & trade-offs

• CDN caching can absorb popular redirects, but invalidation and expiration become harder; use short TTLs or purge support for mutable links.
• Replicate mapping data across regions for low-latency reads. A single home region can own writes initially; global active-active writes require a clear collision and conflict strategy.
• Redirects can favor availability for cached mappings, while creation should favor durable uniqueness. Analytics may be eventually consistent because it is not on the redirect critical path.
• Monitor redirect p50/p99 latency, cache-hit rate, lookup errors, create success and collision rates, abuse reports, and analytics lag. I’d validate assumptions with load tests and evolve the design based on the actual bottleneck.

Model answer

1. Requirements & scale

Functional requirements

• Users save searches with filters such as product, region, price ceiling, and availability, then choose alert channels and frequency.
• Ingest price changes, evaluate affected searches, deduplicate alerts, and deliver them promptly.
• Let users pause, edit, or delete alerts, and inspect delivery status and recent notifications.

Non-functional requirements

• Target p95 alert creation under 60 seconds after a source price update; preserve correctness and avoid duplicate sends.
• Support bursty source updates, tenant isolation, retries, unsubscribe enforcement, and auditable delivery outcomes.
• Treat preferences and consent as authoritative; degrade safely if a notification provider is unavailable.

Assume 10 million saved searches, 2 million daily active users, and 50 million price updates per day. Average input is about 580 updates/second; at a 10x peak, plan for roughly 6,000 updates/second. If an update matches 20 searches on average, that is 1,000 million match evaluations/day, or about 11,600/second average. At 1 KB per saved-search record, raw search data is about 10 GB; indexes and replicas may make it 30–50 GB. At 1 KB per notification, 20 million notifications/day is about 20 GB/day before retention and replication. These are planning assumptions; real fan-out and provider limits need measurement.

2. High-level architecture

flowchart TD
  subgraph Client
    C[Web and mobile]
  end
  subgraph Edge
    E[API gateway and CDN]
  end
  subgraph Load_Balancer
    L[Regional load balancer]
  end
  subgraph API_Services
    A[Alert API]
    P[Price ingestion]
    M[Matching service]
    D[Delivery service]
  end
  subgraph Cache
    R[Redis preferences and dedupe]
  end
  subgraph Datastores
    S[(Search database)]
    I[(Search index)]
    N[(Notification database)]
  end
  subgraph Message_Queue
    Q[Price event stream]
    O[Notification queue]
  end
  subgraph Workers
    W[Match workers]
    X[Delivery workers]
  end
  C -->|HTTPS requests| E
  E -->|API traffic| L
  L -->|CRUD requests| A
  A -->|save subscriptions| S
  A -->|index updates| I
  P -->|normalized price events| Q
  Q -->|partitioned events| W
  W -->|candidate query| I
  W -->|user preferences| R
  W -->|create deduplicated alert| N
  W -->|enqueue eligible alert| O
  O -->|delivery jobs| X
  X -->|record status| N
  X -->|email push webhook| D

3. API design

• POST /v1/alerts — create a saved search and notification preferences; accept an idempotency key.
• GET /v1/alerts/{alertId} — read configuration and status.
• PATCH /v1/alerts/{alertId} — update filters, threshold, channels, or pause state.
• DELETE /v1/alerts/{alertId} — disable the alert and remove it from the active index asynchronously.
• GET /v1/notifications?cursor=... — list recent alert events and delivery status.
• Internal POST /internal/prices/batch — authenticated, batched price updates from source adapters.

4. Data model & storage

Use a relational database such as PostgreSQL for users, alert configuration, consent, and notification records: correctness and transactional updates matter for these entities. Store an alert as (alert_id, user_id, query, channels, frequency, state, version, created_at). Store notifications with a unique key such as (alert_id, product_id, price_version, rule_type) to enforce idempotency. Partition notification history by time and shard by user ID; keep a retention policy for older records.

Use a search/indexing system for candidate retrieval, not as the source of truth. Index searchable dimensions and numeric price bounds, with active alert IDs. Redis can cache preferences and short-lived dedupe keys, but database uniqueness remains the correctness backstop. Kafka or a comparable durable stream carries price events, partitioned by product ID to preserve per-product ordering.

5. Deep dive

On subscription creation, validate the query and preferences, persist the record, then asynchronously update the matching index using a transactional outbox. On a price event, normalize currency, product identity, and source timestamp; reject stale versions; and publish the event. A worker queries the index for candidate searches, then evaluates each full predicate against the new price. For example, notify only when new_price <= max_price and the prior price was above the threshold, or when the configured percentage drop is crossed. This transition check avoids repeatedly alerting on every update while the product remains below the threshold.

sequenceDiagram
  participant Source
  participant Ingest
  participant Stream
  participant Matcher
  participant Index
  participant Store
  participant Sender
  Source->>Ingest: Price update with version
  Ingest->>Stream: Publish normalized event
  Stream->>Matcher: Consume by product partition
  Matcher->>Index: Find candidate searches
  Index-->>Matcher: Candidate alert IDs
  Matcher->>Store: Check state and idempotency key
  Store-->>Matcher: Eligible and unseen
  Matcher->>Store: Insert notification and outbox
  Matcher->>Sender: Queue delivery
  Sender-->>Store: Persist delivery outcome

Use an outbox or equivalent atomic publish pattern so a committed notification is not lost between the database write and queue send. Delivery workers retry transient failures with exponential backoff and jitter; dead-letter after a bounded number of attempts. Recheck pause state and consent immediately before sending. For a digest preference, aggregate eligible events over a window rather than enqueueing each one.

6. Scale, bottlenecks & trade-offs

Scale stream partitions and workers independently, keyed by product so updates for a product are ordered. Hot products can create extreme fan-out; rate-limit per event, process candidate IDs in batches, and use a dedicated path or partition strategy for hot keys. Index writes can lag, so monitor index freshness and reco

Model answer

1. Requirements & scale

Functional requirements

• Accept campaigns and recipient lists, validate consent and suppression status, and schedule email delivery.
• Personalize content, send through one or more email providers, process bounces, complaints, and delivery callbacks, and expose campaign-level status.
• Support retries, cancellation where possible, per-customer quotas, and idempotent submission.

Non-functional requirements

• Durable acceptance, high throughput, at-least-once internal processing, and controls against duplicate sends.
• Provider and tenant rate limits; bounce and complaint handling; tenant isolation and auditability.
• Keep recipient PII encrypted and restrict access. Do not promise exactly-once delivery across an external provider boundary.

Back-of-the-envelope estimates

Assume 100M emails/day: about 1,160 emails/second average; allow 10x peaks, or 12K/second. At 2 KB of metadata per recipient, daily metadata is roughly 200 GB before indexes and replication; retain full content separately and apply retention policies. If average message plus headers is 100 KB, outbound payload is around 10 TB/day, so provider bandwidth and quotas are major constraints.

2. High-level architecture

flowchart TD
  subgraph Client["Client"]
    U["Campaign UI and API clients"]
  end
  subgraph Edge["Edge/CDN"]
    W["WAF and API edge"]
  end
  subgraph LB["Load Balancer"]
    L["Regional load balancer"]
  end
  subgraph API["API / Services"]
    G["API gateway"]
    C["Campaign service"]
    P["Policy and consent service"]
    T["Template renderer"]
    S["Scheduling service"]
    D["Delivery service"]
    H["Webhook service"]
  end
  subgraph Cache["Cache"]
    R["Quota and suppression cache"]
  end
  subgraph DB["Datastores"]
    Q["SQL campaign and recipient metadata"]
    O["Object storage for templates"]
    A["Analytics store"]
  end
  subgraph MQ["Message Queue"]
    K["Scheduled and ready queues"]
    F["Retry and dead letter queues"]
  end
  subgraph Workers["Workers"]
    B["Batch expansion workers"]
    E["Send workers"]
    X["Event and reporting workers"]
  end
  U -->|"create campaign"| W
  W -->|"validated API request"| L
  L -->|"route request"| G
  G -->|"campaign and consent check"| C
  C -->|"persist campaign"| Q
  C -->|"store content"| O
  C -->|"schedule job"| S
  S -->|"due campaign"| K
  K -->|"expand recipients"| B
  B -->|"check policy"| P
  P -->|"suppression and quota"| R
  B -->|"eligible message jobs"| K
  K -->|"ready message"| E
  E -->|"provider API"| X
  X -->|"acceptance and event records"| Q
  X -->|"reporting data"| A
  X -->|"bounce or complaint"| H
  H -->|"update suppression"| Q
  E -->|"retry or poison job"| F

3. API design

• POST /v1/campaigns — create a campaign with template, audience reference, sender identity, and schedule; require an idempotency key.
• POST /v1/campaigns/{id}/send — validate and begin dispatch; return accepted status and campaign ID.
• GET /v1/campaigns/{id} — campaign progress and aggregate counts.
• POST /v1/webhooks/providers/{provider} — verify provider signatures and ingest delivery, bounce, or complaint events.
• POST /v1/campaigns/{id}/cancel — stop jobs not yet handed to a provider; state the cancellation boundary clearly.

4. Data model & storage

• SQL stores campaigns, tenant quotas, sender identities, consent references, and per-recipient delivery state. Partition large delivery records by tenant and campaign or time; use a campaign ID plus recipient ID as a deduplication key.
• Object storage keeps immutable templates and large audience imports. Encrypt data at rest and expire imports and rendered bodies according to retention policy.
• A durable queue holds scheduled campaign jobs and ready-to-send messages. A separate delayed retry and dead-letter path prevents poison messages from blocking healthy traffic.
• Redis can accelerate quota checks and suppression lookups, but the durable consent/suppression record is authoritative. Search/reporting aggregates belong in an analytics store, not on the send path.

5. Deep dive

The send path must balance throughput, provider limits, and duplicate prevention. Accept a campaign once, persist it and an outbox event transactionally, then expand large audiences in bounded batches. Each message job carries a stable ID, tenant, recipient, campaign, provider, and attempt count. Before sending, a worker rechecks suppression and quota, reserves capacity from a token bucket for the provider and tenant, and atomically claims the job with a lease. It renders or retrieves the message, submits it, and records the provider's message ID. A timeout is ambiguous: the provider may have accepted the email even though the response was lost. Use provider idempotency keys when available; otherwise mark the result uncertain and reconcile via provider events rather than blindly resending. Exactly-once email delivery cannot be guaranteed across this boundary.

sequenceDiagram
  participant C as Campaign API
  participant D as SQL and outbox
  participant Q as Queue
  participant W as Send worker
  participant P as Policy service
  participant E as Email provider
  participant H as Webhook handler
  C->>D: Persist campaign and outbox
  D->>Q: Publish campaign expansion job
  Q->>W: Deliver recipient job
  W->>P: Check consent and reserve quota
  P-->>W: Eligible and capacity granted
  W->>E: Submit with stable idempotency key
  E-->>W: Accepted with provider ID
  W->>D: Record accepted state
  E->>H: Delivery or bounce callback
  H->>D: Update state and suppression

6. Scale, bottlenecks & trade-offs

• Apply hierarchical token buckets: global, provider, sender domain, tenant, and campaign. Pace sends to protect provider reputation and recipient domains; adapt rates using 429s, deferrals, bounce rate, and complaint rate.
• Scale workers horizontally by queue depth and oldest-job age, but cap concurrency by pro

Model answer

1. Requirements & scale

Functional requirements

• Let producers enqueue tasks with a queue, payload, priority, delay, and optional deduplication key.
• Let workers lease, acknowledge, extend, and fail tasks. Retry transient failures with backoff; move repeatedly failing tasks to a dead-letter queue.
• Support visibility into queue depth, age, task state, and worker health. Provide tenant isolation and access control.

Non-functional requirements

• Durable acceptance, horizontal throughput, low-latency dequeue, and recovery from worker, broker, and zone failure.
• At-least-once delivery as the default; make idempotency explicit because exactly-once side effects are not achievable for arbitrary workers.
• Fairness and backpressure so a noisy tenant or stuck consumer cannot exhaust the service.

Back-of-the-envelope estimates

Assume 10M tasks/day, around 116 tasks/second average; design for 10K/second peak. At 2 KB per task, raw task payload is about 20 GB/day; at 7-day retention, about 140 GB before replication and indexes. At 10K tasks/second and a 100 ms enqueue-to-lease target, at least 1,000 tasks may be in active transit, excluding backlog.

2. High-level architecture

flowchart TD
  subgraph Client["Client"]
    P["Producers"]
    C["Worker clients"]
  end
  subgraph Edge["Edge/CDN"]
    W["Auth and rate limiting"]
  end
  subgraph LB["Load Balancer"]
    L["Regional load balancer"]
  end
  subgraph API["API / Services"]
    G["Queue API"]
    M["Metadata service"]
    S["Scheduler"]
    V["Lease service"]
  end
  subgraph Cache["Cache"]
    R["Queue routing and quota cache"]
  end
  subgraph DB["Datastores"]
    D["Replicated task log"]
    Q["SQL queue metadata"]
  end
  subgraph MQ["Message Queue"]
    K["Partitioned ready queues"]
    T["Delayed task index"]
    F["Dead letter queues"]
  end
  subgraph Workers["Workers"]
    X["Dispatch and recovery workers"]
    O["Metrics and compaction workers"]
  end
  P -->|"enqueue and queue config"| W
  C -->|"lease ack or fail"| W
  W -->|"authenticated request"| L
  L -->|"route operation"| G
  G -->|"queue policy"| M
  M -->|"metadata read"| Q
  G -->|"routing and quota"| R
  G -->|"append task record"| D
  G -->|"ready task"| K
  G -->|"future task"| T
  C -->|"poll or long poll"| V
  V -->|"claim task"| K
  V -->|"lease state"| D
  T -->|"due tasks"| S
  S -->|"promote ready task"| K
  X -->|"expire lease and retry"| K
  X -->|"max attempts exceeded"| F
  D -->|"retention and state data"| O

3. API design

• POST /v1/queues/{queue}/tasks — enqueue; accept payload, delaySeconds, priority, and dedupeKey; return task ID.
• POST /v1/queues/{queue}/lease — lease up to N tasks with a visibility timeout; support long polling.
• POST /v1/tasks/{id}/ack — acknowledge completion using the lease token.
• POST /v1/tasks/{id}/extend — extend a live lease, bounded by policy.
• POST /v1/tasks/{id}/fail — record failure and request retry or dead-letter handling.
• GET /v1/queues/{queue}/stats — return approximate ready count, oldest age, and in-flight count.

4. Data model & storage

• SQL stores queue configuration, tenant ownership, retention, retry policy, and access-control metadata. This is lower volume than task traffic and benefits from transactions.
• A partitioned, replicated append log stores task transitions: enqueued, leased, acknowledged, and retry_scheduled. Partition by queue ID and task ID so operations on a task are ordered; shard queue IDs to spread hot traffic.
• Ready queues are partitioned by queue and priority. A delayed-task index ordered by due_at promotes tasks when due. Payloads beyond a size threshold go to object storage, with a reference in the task record.
• Include task ID, tenant ID, queue ID, enqueue time, state, attempt count, lease expiry, lease token, and dedupe key. Retain terminal records only as long as needed for auditing and deduplication.

5. Deep dive

Leasing is the central correctness problem. A consumer receives a task with a random lease token and expiry. The broker atomically changes it from ready to in-flight; only a matching token can acknowledge or extend it. If a worker crashes, a reaper finds expired leases and requeues the task, incrementing its attempt count. If the worker completes a side effect but crashes before acking, the task may run again. Therefore the contract is at-least-once, and producers/workers should use idempotency keys or transactional inbox/outbox patterns for effects they control. Use exponential backoff with jitter and a maximum attempt count; isolate poison tasks in a DLQ and provide a replay path that preserves audit history.

sequenceDiagram
  participant P as Producer
  participant A as Queue API
  participant L as Durable log
  participant Q as Ready queue
  participant W as Worker
  P->>A: Enqueue with dedupe key
  A->>L: Append task record
  L-->>A: Durable commit
  A->>Q: Make task ready
  A-->>P: Return task ID
  W->>Q: Lease task
  Q-->>W: Task and lease token
  W->>W: Execute idempotent work
  W->>A: Ack with lease token
  A->>L: Record completion

6. Scale, bottlenecks & trade-offs

• Partition logs and ready queues; replicate each partition across availability zones. Keep per-queue ordering optional because strict FIFO limits parallelism and creates hot partitions.
• Use long polling to reduce empty requests. Autoscale on oldest-ready age and queue depth, not depth alone; enforce worker concurrency and tenant quotas for backpressure.
• Batch enqueues and leases for throughput, while bounding batch size to limit head-of-line blocking. Use approximate counts for dashboards rather than costly global scans.
• Durability before acknowledgment increases write latency; asynchronous replicas improve latency but risk acknowledged-task loss. For high-value tasks, require quorum replication before returning success.
• Monitor enqueue/dequeue rate, oldest age, lease expiry, ret

Model answer

Consistency and availability are not global switches; I decide per operation based on the cost of stale or conflicting data. For concreteness, I’ll use a multi-region commerce service where inventory reservation needs stronger correctness than product browsing.

1. Requirements & scale

• Functional: serve reads and writes across regions, survive a regional outage, and prevent invalid inventory reservations. Some read paths tolerate stale data; reservation correctness does not.
• Non-functional: keep browse p99 below 150 ms, accept reservations only when stock is safely available, and recover from a regional failure within an explicit RTO. Choose RPO by data class; confirmed reservations should have near-zero acknowledged-write loss.
• Illustrative scale: 50k browse QPS and 2k reservation writes/s peak across three regions. If a reservation record plus indexes averages 1 KB, raw write volume is about 173 GB/day before replication and history. Capacity-test hot products, since skew matters more than the average.
• I’d clarify whether the business prefers rejecting a valid reservation during a partition or risking overselling. For inventory, I generally choose correctness over availability for the final commit.

2. High-level architecture

flowchart TD
  subgraph Client["Client"]
    C["Web / Mobile"]
  end
  subgraph Edge["Edge / CDN"]
    E["CDN for catalog"]
  end
  subgraph LB["Load Balancer"]
    L["Regional router"]
  end
  subgraph API["API / Services"]
    B["Browse API"]
    R["Reservation API"]
    O["Order service"]
  end
  subgraph Cache["Cache"]
    K["Eventually consistent catalog cache"]
  end
  subgraph DB["Datastores"]
    CDB["Replicated catalog store"]
    I["Inventory authority by shard"]
    T["Reservation transaction log"]
  end
  subgraph MQ["Message Queue"]
    Q["Outbox event stream"]
  end
  subgraph Workers["Workers"]
    W["Projection and notification workers"]
  end
  C -->|"browse"| E
  E --> L
  L --> B
  B --> K
  K -->|"cache miss"| CDB
  C -->|"reserve"| L
  L --> R
  R -->|"conditional reserve"| I
  R -->|"durable commit"| T
  T -->|"outbox event"| Q
  Q --> W
  W -->|"update views"| CDB

3. API design

• GET /v1/products/{id} and GET /v1/search?... — serve catalog reads that may be slightly stale; return freshness metadata where useful.
• POST /v1/reservations — reserve SKU quantities with an idempotency key; return confirmed, unavailable, or retryable-unavailable. A timeout is not proof the write failed, so clients must retry with the same key.
• POST /v1/reservations/{id}/confirm and DELETE /v1/reservations/{id} — transition a reservation through an explicit state machine; reject invalid transitions.

4. Data model & storage

• Catalog records are replicated for local reads and can be served from cache or a search index.
• Inventory is partitioned by sku or a carefully chosen inventory key. Each authoritative shard maintains available quantity, reserved quantity, and version. A reservation row has a unique idempotency key, SKU, quantity, state, and expiry.
• Commit the inventory decrement and reservation record atomically within the shard’s consistency boundary. Publish order and catalog projections through a transactional outbox to avoid a database/queue dual-write gap.

5. Deep dive

• For browse, stale reads are acceptable: replicate asynchronously, cache aggressively, and favor local availability. A user may see a temporarily stale quantity, but the authoritative reservation operation decides whether stock can be committed.
• For reservation, use a strongly consistent conditional update such as “decrement only if available quantity is at least requested quantity,” with the idempotency record in the same transaction. Route a SKU to its authoritative shard or leader; do not let two isolated regions independently confirm the last unit.
• During a network partition, the authoritative shard can continue if its quorum remains available. If it cannot establish the required quorum, fail closed for new confirmations, return a retryable response, and keep browse available. Use leases or fencing tokens so an old leader cannot continue writing after failover.

sequenceDiagram
  participant C as Client
  participant R as Reservation API
  participant I as Inventory shard
  participant T as Transaction log
  participant Q as Event stream
  C->>R: Reserve SKU with idempotency key
  R->>I: Conditional decrement and record key
  alt Quorum available and stock exists
    I->>T: Commit reservation
    T->>Q: Publish via outbox
    R-->>C: Confirmed reservation
  else Partition or insufficient stock
    R-->>C: Retryable unavailable or out of stock
  end

6. Scale, bottlenecks & trade-offs

• Replicate catalog reads across regions; keep inventory writes on a clear authority per shard. Shard by SKU to distribute load, then address hot SKUs with queueing or bounded regional allocations rather than weakening correctness silently.
• Strong consistency across regions raises write latency and can reduce availability during partitions. Eventual consistency improves browse availability and latency but is unsafe as the sole basis for irreversible inventory commitments.
• Use quorum-based replication or a consensus-backed transactional store for authoritative writes; define what happens when quorum is unavailable. Monitor quorum loss, leader changes, replication lag, rejected reservations, duplicate retries, oversell incidents, and p99 by operation.
• Test partitions, failovers, delayed messages, and ambiguous client timeouts. Document per-endpoint consistency guarantees, and make the fallback behavior a product decision rather than an accidental database default.

Model answer

A strong answer should connect the technical difficulty to a durable business and organizational outcome. For example, I might describe modernizing a synchronous order-processing system that had become a reliability and delivery bottleneck.

1. Challenge and stakes: Explain the system’s role, scale, and failure mode. For instance, checkout traffic spiked several times above normal during promotions, while downstream inventory and payment services had different latency and availability profiles. A timeout could leave customers unsure whether an order had been placed.
2. What made it complex: Show that this was not simply a technology swap. The system had to preserve order correctness, avoid duplicate charges, support gradual migration, and keep shipping product improvements while the legacy path remained live.
3. Approach and trade-offs: Describe how I aligned product, operations, and engineering on reliability goals; mapped the critical flows; and chose an incremental migration over a rewrite. I would explain the use of durable events, idempotency keys, retries with backoff, dead-letter handling, and clear ownership of each service. I would also mention what remained synchronous and why—for example, validating the customer’s request before acknowledging it.

flowchart LR
  C[Checkout] -->|validated order| O[Order service]
  O -->|durable event| Q[Event queue]
  Q -->|process order| I[Inventory service]
  Q -->|authorize payment| P[Payment service]
  I -->|status event| S[Order status]
  P -->|status event| S
  S -->|customer update| C

1. Validation and impact: Quantify outcomes with before-and-after measures: order success rate, p95 latency, duplicate-charge rate, incident frequency, and deployment lead time. A credible illustrative result might be fewer than half as many order-processing incidents and a materially faster recovery, while maintaining checkout conversion.
2. Long-term impact and leadership: Explain how the solution made future integrations safer, reduced operational toil, and clarified service ownership. Include the cost of the approach—such as eventual consistency and added operational complexity—and how you addressed it with reconciliation jobs, dashboards, and runbooks.

What interviewers listen for: Clear personal ownership, sound technical judgment, migration and failure planning, collaboration across teams, measurable outcomes, and evidence the solution improved the system beyond the initial launch.

Model answer

Example answer: simplifying a slow, unreliable workflow

Situation and stakes

One of the most challenging technical problems I worked on was improving a customer workflow that depended on several backend services. Users experienced intermittent timeouts, and the failures were damaging trust because the task could appear to fail even when part of the work had completed. I was the PM responsible for the customer outcome, coordinating engineering, design, and support.

My role and approach

• I first made the problem measurable. We defined end-to-end success, latency percentiles, timeout rate, and duplicate-action rate, then segmented by workflow step and customer cohort. This showed that the issue was concentrated in a dependency-heavy step, not across the entire product.
• I worked with engineering to map the request path and identify failure modes. We considered optimizing the synchronous path, making the operation asynchronous, and reducing calls to the slow dependency.
• I helped the team compare options against user impact, implementation risk, and time to learn. We chose to acknowledge the request quickly, process it asynchronously, and show a durable status to the user rather than leave them waiting on a long request.
• We agreed on idempotency so retries would not create duplicate work, and defined explicit states and recovery behavior for failures. I pushed for observability and support tooling as part of the release, not as follow-up work.
• I coordinated a staged rollout with a small cohort, a kill switch, and thresholds for latency, failure rate, and support contacts. We reviewed the data with engineering before expanding.

flowchart LR
  A[User request] --> B[Validate and acknowledge]
  B --> C[Queue work]
  C --> D[Worker processes task]
  D --> E[Update durable status]
  E --> F[User sees outcome]
  D --> G[Retry or alert on failure]

Result and learning

The team reduced timeouts and duplicate actions, while users gained a clear view of whether work was pending, complete, or needed attention. We also improved our ability to diagnose issues because the workflow had measurable stages. The experience taught me to translate a technical failure into its user-level consequence, partner closely with engineers on the mechanism, and make reliability and rollout strategy part of the product definition.

What interviewers listen for: Your actual contribution, how you reasoned about technical options, the customer and business stakes, and measurable results. Replace the illustrative scenario and outcomes with a problem you personally worked on; be precise about what the engineers owned versus what you owned as PM.

Model answer

I would communicate progress or a stoppage with a predictable cadence, a consistent format, and a clear ask. The purpose is to help each audience understand what changed, what it means for the outcome, and what decision or action is needed—not merely to report activity.

1. Set expectations up front. At kickoff, I would agree on the milestone plan, status cadence, escalation path, and who receives which level of detail. For example, delivery teams may need a weekly dependency review, while executives need a concise milestone and risk summary.
2. Report against outcomes and milestones. I would state overall status, completed and upcoming milestones, variance from the plan, and leading indicators such as unresolved dependencies or test pass rate. I would distinguish confirmed facts from estimates and assumptions.
3. Use a consistent status format. Each update should include: status and date; progress since the last update; next milestone and confidence; top risks or blockers; impact on scope, date, cost, or quality; owner; and the decision or help needed. I would avoid vague labels such as at risk without explaining why.
4. Communicate a stoppage promptly. I would notify affected owners as soon as the blocker is credible, explain what is stopped and what can continue, contain customer or operational impact, and provide the next update time. I would not wait for a complete root-cause analysis before flagging material risk.
5. Offer options and a recommendation. For a delayed dependency, I would present realistic choices—for example, resequence work, reduce scope, add capacity if that genuinely helps, or move the date—along with trade-offs and a recommendation. I would identify the decision owner and deadline.
6. Close the loop. Once the issue is resolved, I would update the plan, communicate the decision, document any new risks, and confirm owners and dates. If the same blocker recurs, I would address the systemic cause rather than normalize escalation as the process.

flowchart TD
    A[Track milestones and risks] --> B{Material change?}
    B -- No --> C[Send scheduled update]
    B -- Yes --> D[Notify affected owners]
    D --> E[Assess impact and contain]
    E --> F[Present options and recommendation]
    F --> G[Record decision and owner]
    G --> H[Update plan and communicate]

Trade-offs and pitfalls: I would tailor detail to the audience without changing the underlying facts. I would not imply green status when a critical dependency is unresolved, bury a date risk in a long report, or escalate a problem without a proposed next step. Useful measures include milestone predictability, blocker age, decision turnaround time, and how often stakeholders are surprised by a change.

Model answer

1. Set explicit team standards: I make testing and deployment practices part of the team’s definition of done, not a separate quality phase. Standards include appropriate unit, integration, and end-to-end coverage; review requirements; security checks; and a documented rollback path. I tailor the bar to the risk of the change rather than maximizing test counts.
2. Build a fast, layered feedback loop: Keep unit tests quick and deterministic, run integration tests against realistic dependencies, and reserve end-to-end tests for critical user journeys. Track flaky tests as defects: assign an owner, measure flake rate, and quarantine only with a time-bound repair plan. Useful metrics include escaped defects, change failure rate, flaky-test rate, and time to restore service.
3. Make deployment safer by design: Prefer small changes, automated CI checks, feature flags, and progressive delivery. For a high-risk change, release to an internal cohort or small traffic percentage, check predefined health signals, then expand or roll back. Use backward-compatible database migrations so application and schema changes can be deployed independently.
4. Make the release decision observable: Define service-level indicators and deployment guardrails before launch—such as error rate, latency, and saturation. Ensure alerts reach an on-call owner, dashboards show the change’s impact, and rollback steps are rehearsed rather than assumed.

flowchart LR
  A[Change] --> B[Review and CI]
  B --> C[Unit and integration tests]
  C --> D[Staging and smoke tests]
  D --> E[Canary release]
  E --> F{Health checks pass?}
  F -->|Yes| G[Expand rollout]
  F -->|No| H[Rollback and investigate]
  G --> I[Post-release review]

1. Create ownership, not bureaucracy: I review quality trends with the team, invest in test infrastructure when it slows delivery, and use incident reviews to improve the system rather than assign blame. I coach engineers to choose tests based on failure modes and customer impact.

Trade-offs and pitfalls: More tests can increase feedback time and brittle end-to-end suites can reduce confidence. Avoid treating coverage percentage as a proxy for quality, using manual release gates that do not catch real risks, or optimizing deployment frequency while ignoring customer-facing failures. The goal is frequent, low-risk change with fast detection and recovery.

Model answer

Assumptions I would state explicitly

1. The objective is a service-cost balance, not inventory reduction alone. I would assume we want to improve availability while controlling inventory value, waste, and expedite cost. Otherwise, a solution could meet a narrow target by overstocking or by accepting harmful stockouts. I would confirm the target service level and the relative costs with operations and finance.
2. The decision is SKU × location, reviewed daily. This is a practical starting point because demand and replenishment constraints often differ by product and site. I would validate the review cadence against ordering calendars and system capabilities; a daily recommendation does not imply that every item can be ordered daily.
3. Sales are an imperfect proxy for demand. When an item is unavailable, observed sales can be zero even when customers wanted to buy it. I would assume some stockout censoring exists, identify affected periods, and estimate or bound lost demand. I would test how sensitive replenishment recommendations are to that correction.
4. Lead time is variable, not a fixed number. The time between order placement and receipt affects both expected demand and safety stock. I would use historical supplier and lane data where reliable, and fall back to documented estimates when it is not. I would separately flag suppliers with sparse or unstable histories.
5. Operational constraints apply to recommendations. Minimum order quantities, case packs, shelf life, storage capacity, budgets, and supplier limits can make a mathematically optimal order unusable. I would include known constraints in the first version and identify which ones need manual review.
6. Historical data is informative but not a guarantee of future conditions. Seasonality, promotions, assortment changes, and unusual events can break a simple extrapolation. I would use time-based backtests, segment performance, and a pilot before scaling; I would not rely on a random train/test split for a time-dependent decision.

How I would validate them

flowchart TD
  A[State assumption] --> B[Find data or owner]
  B --> C[Measure uncertainty and impact]
  C --> D{Decision sensitive?}
  D -->|Yes| E[Run sensitivity test or pilot]
  D -->|No| F[Document and monitor]
  E --> G[Revise policy or proceed]
  F --> G

I would prioritize assumptions by impact if wrong × uncertainty. For example, if correcting stockout-censored demand materially changes orders for a high-revenue category, that assumption deserves early investigation. If a low-volume item has a minor effect, a conservative fallback may be sufficient for the pilot.

Finally, I would document each assumption, its rationale, owner, validation method, and review date. This makes the case study auditable and turns assumptions into a plan for learning rather than hidden facts.