eBay interview questions & answers

Model answer

Illustrative STAR example—replace the context and metrics with a real achievement from your experience.

Situation

At a prior marketplace company, leadership was debating whether to expand a new dispatch policy across several regions. The analysis was fragmented: operations used delivery-time dashboards, finance focused on cost, and the data science team had not established whether the policy caused the observed changes. As the data science manager, I saw a risk that we would scale based on incomplete evidence and create avoidable customer or Dasher harm.

Task

I took ownership of producing a decision-ready evaluation and aligning product, operations, and finance on what “success” meant. The key constraint was to get credible evidence quickly without disrupting live marketplace operations.

Action

• I brought the leads together and agreed on a primary metric, such as contribution margin per order, plus guardrails for on-time delivery, cancellations, and Dasher earnings per active hour.
• I asked the team to map where treatment could affect control outcomes. Because dispatch changes can alter local Dasher supply, we chose a zone-and-time switchback design rather than relying on simple order-level randomization.
• I set a clear analysis plan before launch: eligibility rules, exposure logging, sample-size assumptions, minimum detectable effect, and a decision threshold tied to business value.
• I worked with engineering and operations to validate assignment and metric instrumentation, then established a gradual rollout with an explicit rollback owner and guardrail alerts.
• When early results varied by market, I resisted presenting a single average as the whole story. I partnered with regional operators to investigate the differences and separated genuine heterogeneity from data-quality issues.

Result

The evaluation gave leadership a defensible scale-or-stop decision and replaced competing interpretations with shared metrics. In a real answer, quantify the outcome—for example, the measured change in margin or delivery quality, the number of markets informed, and the time saved in decision-making. I’m proud of the work because it improved not just a metric, but the organization’s ability to make responsible marketplace decisions.

Model answer

Situation

“An example I would adapt is a disagreement between two engineers about whether to ship a feature using a quick synchronous integration or delay the launch to build a more resilient asynchronous path. The debate had become personal: each person felt the other was dismissing their concerns. The feature had a fixed customer-facing date, and I was the engineering manager accountable for the team’s decision and delivery.”

Task

“I needed to restore a productive working relationship, make a technically sound decision, and ensure the team understood how we would manage risk. I did not want to resolve it by seniority or force an artificial compromise.”

Action

• “I spoke with each engineer separately to understand their concern and impact. I reflected back what I heard: one was protecting the launch date and limiting scope; the other was worried about dependency failures and difficult recovery.”
• “I brought them together and reset the discussion around shared goals: customer impact, failure behavior, operational ownership, and reversibility. I asked each to explain the strongest version of the other person’s argument before defending their own.”
• “We compared options against explicit criteria: delivery time, expected failure modes, recovery time, and the cost of changing course later. I asked for evidence, such as dependency reliability and expected request volume, rather than debating architecture preferences in the abstract.”
• “We chose a narrow launch with timeouts, bounded retries, idempotency, monitoring, and a feature flag, while putting the asynchronous redesign behind a follow-up decision gate. I made clear that this was a risk-managed decision, not a judgment that one engineer had ‘won.’”
• “After launch, I reviewed the decision and team interaction in a retrospective. I coached both engineers on raising disagreement early, criticizing ideas rather than motives, and writing down risks so they could be evaluated consistently.”

Result

“The team reached a decision without slipping the launch, and the flag and monitoring gave us a controlled way to limit exposure if the dependency behaved poorly. The engineers resumed collaborating on the follow-up work, and the written decision made the trade-off clear to product and operations. I learned that managing conflict is not the same as removing disagreement: my responsibility is to make disagreement safe, evidence-based, and time-bounded, while retaining clear ownership of the final call. I would adapt the technical details and measured outcome to a real example from my experience.”

Model answer

Situation

At a company preparing to launch a new analytics feature, I found that the proposed implementation would retain identifiable customer data longer than our privacy commitments allowed. The launch had executive visibility, several teams had already invested in it, and delaying it could affect a committed customer date. I was the Staff Engineer responsible for the architecture review, so I needed to raise the issue and help the organization make a decision—not just point out a risk.

Task

I had to protect customer trust and meet our privacy commitments while finding a credible path to deliver the feature. The difficult part was balancing a real launch cost against a risk that was easy to discount because it had not yet caused an incident.

Action

• I first verified the facts with the privacy and security teams: what data was collected, where it flowed, how long it persisted, and which commitments applied. I separated confirmed issues from assumptions so the discussion would be evidence-based.
• I wrote a short decision document describing the risk, affected systems, options, and consequences. The options included launching as proposed, delaying, or shipping a narrower version that removed the sensitive fields and enforced a shorter retention period.
• I recommended the narrower launch. It preserved the main customer benefit while reducing exposure, though it meant cutting one planned analytics capability and doing additional engineering work.
• I brought product, legal, security, and engineering leads together. I made the trade-off explicit, invited challenges to my assumptions, and ensured the accountable business leader—not engineering alone—made the final go/no-go decision.
• I helped the teams define deletion checks, access controls, and launch gates, then established an owner and review date for the deferred capability.

Result

We shipped the reduced feature on the agreed date, with the risky data path removed. We tracked [privacy or deletion compliance metric] and [customer adoption or feature-use metric] after launch; I would use the actual measured values in an interview rather than estimate them. The experience reinforced for me that acting on company values is strongest when I pair a clear principle with a workable delivery plan.

What interviewers listen for

• A real tension and a decision you personally owned.
• Customer or company values translated into concrete engineering choices.
• Influence across functions, explicit trade-offs, and a measurable outcome.
• Reflection without presenting yourself as the sole hero.

Model answer

Situation

At a previous company, I joined a small product engineering group that was moving from an early product to a more repeatable business. We had a lean team, changing customer evidence, and a few operational gaps that would have been handled by dedicated functions at a larger company. My role was to help the team deliver reliably while building enough structure to scale.

Task

I needed to adapt my management approach to the company’s stage: keep decision-making fast and ownership clear, without letting urgency become chronic rework or burnout. The central tension was adding just enough process to improve outcomes without importing heavyweight practices that did not fit our size.

Action

• I started by learning the business model, customer commitments, and current constraints directly from the founders, product partners, and engineers. I used that context to distinguish urgent work from work that merely felt urgent.
• I made priorities visible in a short rolling plan, with a named owner, expected outcome, and explicit trade-offs for each major initiative. When new work arrived, I asked what we would stop or defer rather than silently adding it.
• I kept planning lightweight: brief written proposals for risky changes, small milestones, and frequent customer or stakeholder feedback. For example, instead of committing to a broad platform rebuild, I proposed a narrow slice that tested the riskiest assumption first.
• I encouraged engineers to take end-to-end ownership, while clarifying where they could decide independently and where a product, security, or business partner needed to be involved.
• I treated reliability and team health as product constraints. We tracked incidents and delivery predictability, reserved capacity for operational work, and addressed recurring sources of interruption rather than celebrating unsustainable heroics.

Result

The team shipped the initial customer-facing capability in smaller increments, reduced surprises late in delivery, and gave stakeholders clearer choices when priorities changed. We also established a repeatable planning rhythm without slowing day-to-day decisions. I learned that adapting to a startup is not about doing everything informally; it is about applying the minimum structure that protects focus, learning, and trust.

What interviewers listen for

• Comfort with ambiguity and changing priorities.
• Pragmatism without using startup speed as an excuse for chaos.
• Customer, business, and team-health awareness.
• Evidence of outcomes; replace example metrics with your own verified results.

Model answer

Find the first adjacent pair that violates strict increase. If there is no violation, return true. Otherwise, try removing either element in that pair and validate the resulting sequence. Any valid one-removal solution must remove one of those two elements.

function canBeStrictlyIncreasing(nums) {
  function isIncreasingAfterSkipping(skipIndex) {
    let previous;
    let hasPrevious = false;

    for (let i = 0; i < nums.length; i++) {
      if (i === skipIndex) continue;

      if (hasPrevious && previous >= nums[i]) return false;
      previous = nums[i];
      hasPrevious = true;
    }

    return true;
  }

  let violation = -1;
  for (let i = 1; i < nums.length; i++) {
    if (nums[i - 1] >= nums[i]) {
      violation = i;
      break;
    }
  }

  if (violation === -1) return true;

  // Either the earlier or later value in the first bad pair must be removed.
  return (
    isIncreasingAfterSkipping(violation - 1) ||
    isIncreasingAfterSkipping(violation)
  );
}

console.log(canBeStrictlyIncreasing([1, 2, 10, 5, 7])); // true
console.log(canBeStrictlyIncreasing([2, 3, 1, 2]));     // false
console.log(canBeStrictlyIncreasing([1, 1]));           // true

• Use >=, not >, because the remaining sequence must be strictly increasing.
• The input is not mutated; each validation pass skips one index.

Complexity: Time O(n); space O(1).

Model answer

I would keep the business logic pure and independent of HTTP, persistence, and UI code. Since the question does not specify pricing rules, this example makes them explicit: each item has weight in grams and unit price in cents; shipping is a base fee plus a fee per started kilogram; tax applies to merchandise plus shipping. I would confirm these rules, rounding, and currency requirements with the business before shipping.

function calculateOrder(items, pricing) {
  if (!Array.isArray(items) || items.length === 0) {
    throw new Error("At least one item is required");
  }

  const { taxRateBps, shippingBaseCents, shippingPerKgCents } = pricing;
  for (const [name, value] of Object.entries(pricing)) {
    if (!Number.isSafeInteger(value) || value < 0) {
      throw new Error(`${name} must be a non-negative integer`);
    }
  }

  let totalWeightGrams = 0;
  let subtotalCents = 0;

  for (const item of items) {
    const { quantity, weightGrams, unitPriceCents } = item;
    if (![quantity, weightGrams, unitPriceCents].every(Number.isSafeInteger) ||
        quantity <= 0 || weightGrams < 0 || unitPriceCents < 0) {
      throw new Error("Item quantity, weight, or price is invalid");
    }

    totalWeightGrams += quantity * weightGrams;
    subtotalCents += quantity * unitPriceCents;
  }

  // Charge for each started kilogram; zero weight incurs no per-kg fee.
  const billableKg = Math.ceil(totalWeightGrams / 1000);
  const shippingCents = shippingBaseCents + billableKg * shippingPerKgCents;
  const taxableCents = subtotalCents + shippingCents;
  const taxCents = Math.round((taxableCents * taxRateBps) / 10000);

  return {
    totalWeightGrams,
    subtotalCents,
    shippingCents,
    taxCents,
    totalCents: taxableCents + taxCents,
  };
}

const result = calculateOrder(
  [{ quantity: 2, weightGrams: 750, unitPriceCents: 1200 }],
  { taxRateBps: 825, shippingBaseCents: 300, shippingPerKgCents: 150 }
);
console.log(result);

• Store money as integer minor units (for example, cents) and weight in a defined base unit to avoid floating-point drift.
• Keep rules configurable and test boundaries: zero weight, partial kilograms, invalid quantities, tax rounding, and large totals. In production, also guard multiplication and addition against exceeding safe integer limits.

Complexity: O(n) time over n line items; O(1) auxiliary space.

Model answer

“Minimum-cost problem” can refer to different problems, so I’d clarify the operation and cost model first. A standard greedy example is connecting ropes: each time, join the two shortest ropes, pay their combined length, and put the joined rope back. This is optimal because shorter pieces should be combined earlier, and the problem reduces to repeatedly extracting the two minima. I’d implement a min-heap without relying on a library.

class MinHeap {
  constructor(values = []) {
    this.data = [];
    for (const value of values) this.push(value);
  }

  get size() {
    return this.data.length;
  }

  push(value) {
    this.data.push(value);
    let index = this.data.length - 1;

    while (index > 0) {
      const parent = Math.floor((index - 1) / 2);
      if (this.data[parent] <= this.data[index]) break;
      [this.data[parent], this.data[index]] = [this.data[index], this.data[parent]];
      index = parent;
    }
  }

  pop() {
    if (this.data.length === 0) return undefined;

    const minimum = this.data[0];
    const last = this.data.pop();

    if (this.data.length > 0) {
      this.data[0] = last;
      let index = 0;

      while (true) {
        const left = 2 * index + 1;
        const right = left + 1;
        let smallest = index;

        if (left < this.data.length && this.data[left] < this.data[smallest]) {
          smallest = left;
        }
        if (right < this.data.length && this.data[right] < this.data[smallest]) {
          smallest = right;
        }
        if (smallest === index) break;

        [this.data[index], this.data[smallest]] = [this.data[smallest], this.data[index]];
        index = smallest;
      }
    }

    return minimum;
  }
}

function minimumCostToConnectRopes(ropes) {
  if (ropes.length < 2) return 0;

  const heap = new MinHeap(ropes);
  let totalCost = 0;

  while (heap.size > 1) {
    const first = heap.pop();
    const second = heap.pop();
    const combined = first + second;

    totalCost += combined;
    heap.push(combined);
  }

  return totalCost;
}

// Example: minimumCostToConnectRopes([4, 3, 2, 6]) returns 29.

• Each merge is locally cheapest; the min-heap maintains the two smallest remaining lengths efficiently.
• The total cost is the sum of every combined length. Empty or single-rope input requires no joins.
• Complexity: O(n log n) time and O(n) space.

Model answer

Use a hash map for key lookup and a doubly linked list for recency order. Keep the most recently used node immediately after the head sentinel and the least recently used node immediately before the tail sentinel. Both get and put then take constant time.

class LRUCache {
  constructor(capacity) {
    this.capacity = Math.max(0, capacity);
    this.nodes = new Map();

    this.head = { key: null, value: null, prev: null, next: null };
    this.tail = { key: null, value: null, prev: this.head, next: null };
    this.head.next = this.tail;
  }

  get(key) {
    const node = this.nodes.get(key);
    if (!node) return -1;

    this._remove(node);
    this._addToFront(node);
    return node.value;
  }

  put(key, value) {
    if (this.capacity === 0) return;

    const existing = this.nodes.get(key);
    if (existing) {
      existing.value = value;
      this._remove(existing);
      this._addToFront(existing);
      return;
    }

    const node = { key, value, prev: null, next: null };
    this.nodes.set(key, node);
    this._addToFront(node);

    if (this.nodes.size > this.capacity) {
      const leastRecentlyUsed = this.tail.prev;
      this._remove(leastRecentlyUsed);
      this.nodes.delete(leastRecentlyUsed.key);
    }
  }

  _remove(node) {
    node.prev.next = node.next;
    node.next.prev = node.prev;
  }

  _addToFront(node) {
    node.prev = this.head;
    node.next = this.head.next;
    this.head.next.prev = node;
    this.head.next = node;
  }
}

const cache = new LRUCache(2);
cache.put(1, 1);
cache.put(2, 2);
console.log(cache.get(1)); // 1; key 1 becomes most recently used
cache.put(3, 3);           // evicts key 2
console.log(cache.get(2)); // -1

• The map provides direct lookup; the linked list supports constant-time promotion and eviction.
• Updating an existing key changes its value and makes it most recently used. A zero-capacity cache stores nothing.

Complexity: get and put are O(1) average time; space is O(capacity).

Model answer

Clarify

“I start by separating the decision from the requests. What outcome are we optimizing for, what is the planning horizon, and which items are already contractual, regulatory, or incident-driven obligations? I also clarify whether the competition is between features, or whether one option is foundational work that changes the cost or feasibility of the others.”

Define the decision criteria

“I make a consistent set of criteria visible: customer reach and severity, expected business impact, confidence in the evidence, time to value, engineering effort, strategic fit, dependencies, and operational risk. I distinguish urgency from importance; an executive escalation can be a signal to investigate, but not automatically a reason to displace higher-impact work.”

Break down the options

“I ask each request owner to state the user, problem, evidence, expected outcome, and smallest testable solution. Then I compare the alternatives at the same level. A large feature should not be compared with a tiny bug fix without including its full delivery and maintenance cost. I also identify whether a platform investment unlocks multiple roadmap items.”

Hypotheses and trade-offs

“For example, imagine a sales team asks for a custom enterprise workflow while product data shows a broad onboarding drop-off. I would quantify the account value and deadline, estimate the affected cohort and conversion opportunity, and explore whether a smaller enterprise capability satisfies the commitment. If onboarding has stronger reach and evidence, I might prioritize that while assigning a time-boxed discovery or a scoped commitment for the account.”

Decision & prioritization

“I use a tool such as RICE or impact-versus-effort to make assumptions comparable, but I do not let the score make the decision. I consider capacity constraints, dependencies, portfolio balance, and the cost of delay. If the evidence is weak and the decision is expensive to reverse, I prioritize discovery. If it is reversible, I may ship a small experiment.”

MVP, measurement & review

“I communicate the decision, rationale, owner, and what we are not doing. I reserve capacity for reliability and unplanned work instead of pretending the team is 100% available. For the selected work, I define a leading indicator and guardrails, launch to a limited cohort, and set a review date. I revisit the ranking when results, customer commitments, or business priorities change—not every time a new request arrives.”

Model answer

Clarify & scope

I’d first confirm which Amazon policy changed, in which marketplace and categories, and whether it affects return windows, eligibility, fees, or refund timing. Those details vary, so I wouldn’t assume one change applies to every seller. I’ll assume we’re a brand selling on Amazon and need to protect customer trust and profitable growth.

User segments & pain points

I’d segment customers by purchase type and return behavior, and our business by category, margin, and return rate. I’d focus first on customers buying high-consideration products: a more restrictive policy could reduce conversion if they perceive more risk, while a more generous policy could increase returns and reverse-logistics costs. Sellers also need clear operational guidance so policy changes don’t create avoidable disputes.

Goals & success metrics

My North Star would be profitable customer growth on Amazon—not minimizing returns in isolation. I’d track conversion, revenue and contribution margin, return rate and reason, refund and return-related contacts, customer ratings, and policy-related account-health signals. I’d compare affected products with similar unaffected products, while controlling for seasonality and promotions.

Solutions

• Understand the change: Map the policy to our catalog, customer journey, and seller obligations; confirm the effective date and exceptions with Amazon’s official guidance.
• Reduce preventable returns: Improve sizing, compatibility, condition, and use-case information on listings; investigate return reasons and fix product or packaging issues.
• Adapt the offer: Where economics support it, test clearer product guidance, bundles, or a more suitable assortment. Don’t make promises that conflict with Amazon’s policy.

Recommendation: Start with a policy-impact and catalog audit, then prioritize fixes for products where customer confusion or margin exposure is highest. Avoid broad price increases or restrictive practices until the data shows they’re needed.

Prioritization & trade-offs

I’d rank actions by expected customer and margin impact, confidence, effort, and policy risk. Listing corrections are often faster and lower-risk than changing assortment or fulfillment. I’d also distinguish a genuine product-quality problem from opportunistic or abusive returns; the response should be different.

MVP, measurement & rollout

Pilot the highest-priority listing and product improvements on a small, comparable set of SKUs. Review weekly against a holdout group, tracking conversion, contribution margin, return reasons, and customer complaints. Expand what improves profitable outcomes without harming customer trust, and revisit the plan as Amazon clarifies or changes enforcement.

Model answer

Clarify & scope

“I treat feature prioritization as a way to maximize customer and business outcomes while keeping the team sustainable—not as a vote on which request is loudest. I first clarify the company goal for the quarter, the user problem we are solving, and whether the team has a committed roadmap or operational obligations.”

User segments & pain points

“I identify who is affected and how severely: for example, new users who cannot complete onboarding, established users blocked by a workflow, or internal teams carrying costly manual work. I look for evidence from customer interviews, support volume, funnel data, and reliability incidents, rather than relying only on stakeholder confidence.”

Goals & success metrics

“I connect candidate work to an outcome metric, such as activation, task completion, retention, or revenue. I also set guardrails: reliability, latency, support contacts, accessibility, and engineering capacity. A feature without a measurable hypothesis is usually discovery work, not yet a delivery commitment.”

Solutions

“I compare the smallest useful options, including doing nothing, fixing an existing workflow, or addressing a platform constraint. For each, I estimate impact, confidence, effort, dependencies, and risk. I make the assumptions visible and ask engineers to help estimate—not just implementation time, but ongoing operational cost.”

Recommendation: “I’d use a lightweight scoring model as a conversation aid, not an automatic ranking. For example, a high-confidence onboarding fix expected to improve activation for a large segment may beat a complex feature requested by one strategic account, unless that account represents a clear business commitment.”

Prioritization & trade-offs

“I reserve capacity for reliability, tech debt, and unplanned work so the roadmap is credible. I explain what we are not doing, who bears that cost, and what evidence would change the decision. If two candidates are close, I favor the one with faster learning or a reversible rollout.”

MVP, measurement & rollout

“I define a thin slice, an owner, a launch gate, and a review date. I release behind a flag to a limited cohort, compare results with a baseline or control group, and expand only if the primary metric improves without violating guardrails. Then I revisit the backlog with what we learned.”

Model answer

Clarify & scope

I’d first clarify what “PN” means and ask to see the actual notification, its destination screen, and the context in which it appears. Assuming PN means a mobile push notification, I can’t judge this specific one without the copy and user journey. I’d assess whether it has a clear user problem and useful next step—not just whether the wording sounds engaging.

User segments & pain points

I’d identify who receives it, what they were doing, and whether they expect this message. For example, a timely delivery update may help a user waiting for an order; a generic promotion may interrupt them without adding value. I’d pay particular attention to new users, users who have disabled notifications, and users with different levels of product engagement.

Goals & success metrics

The goal should be a meaningful user outcome, such as completing a time-sensitive task—not maximizing opens. I’d track the relevant downstream conversion or task completion, notification opt-out and uninstall rates, and complaint or “not relevant” signals. Open rate is a diagnostic metric, not the definition of success.

Solutions

I’d review the notification against four questions: Is it relevant to this user? Is the timing appropriate? Does it explain the value of acting now? Does the tap lead to the promised destination?

Possible improvements include personalizing eligibility, delaying delivery until a more useful moment, or replacing a broad push with an in-app message. Recommendation: test the smallest change that addresses the observed failure—such as sending only to users with an active, relevant event—and compare it with the current experience.

Prioritization & trade-offs

I’d prioritize by expected user benefit, reach, confidence, and implementation cost. A more targeted notification may reduce reach but improve trust; that is often preferable to sending more messages that increase opt-outs.

MVP, measurement & rollout

I’d run a randomized test with a holdout, define a minimum detectable effect, and monitor downstream outcomes and guardrails by segment. I’d ramp gradually, stop if opt-outs or complaints exceed a pre-agreed threshold, and expand only if the notification improves the user outcome without harming long-term trust.

Model answer

1. Requirements & scale

I’d first ask what the service does, who depends on it, and which constraints are fixed: traffic shape, data sensitivity, consistency, regional needs, budget, and operational maturity. If those details are not provided, I’d state an assumption and design a reference API service: 99.95% monthly availability, p99 latency under 200 ms for reads, durable acknowledged writes, 1,000 average requests/second and 10,000 at peak.

• Functional: authenticate requests; create and retrieve tenant-owned resources; support idempotent writes; expose health and operational signals.
• Non-functional: availability, latency, durability, security, and recovery targets must be explicit. A 99.95% 30-day SLO allows about 21.6 minutes of unavailability per month.
• Capacity estimate: 1,000 average RPS is 86.4 million requests/day. At 10% writes, 8.64 million 1 KB records/day is about 8.6 GB/day raw, or roughly 0.5 TB for 30 days including indexes and replication. At 10,000 peak RPS and a 10 KB response, outbound traffic is about 100 MB/s, or 800 Mbps.

2. High-level architecture

flowchart TD
  subgraph Client
    C["Web and mobile clients"]
  end
  subgraph EdgeCDN["Edge / CDN"]
    E["CDN, WAF, rate limits"]
  end
  subgraph LoadBalancer["Load Balancer"]
    L["Regional load balancer"]
  end
  subgraph APIServices["API / Services"]
    A["Stateless API service"]
    S["Resource service"]
    O["Outbox publisher"]
  end
  subgraph Cache["Cache"]
    R["Redis cache"]
  end
  subgraph Datastores["Datastores"]
    D["Sharded SQL primary"]
    F["Read replicas"]
  end
  subgraph MessageQueue["Message Queue"]
    Q["Durable event queue"]
  end
  subgraph Workers["Workers"]
    W["Async workers"]
  end
  C -->|"HTTPS requests"| E
  E -->|"filtered traffic"| L
  L -->|"balanced requests"| A
  A -->|"business operations"| S
  S -->|"read-through lookup"| R
  R -->|"cache miss"| D
  S -->|"consistent write"| D
  D -->|"replication"| F
  D -->|"outbox rows"| O
  O -->|"published events"| Q
  Q -->|"async work"| W

The edge enforces coarse rate limits and blocks abusive traffic; the API performs authentication and authorization. Stateless service instances scale horizontally. The transactional database is the source of truth; cache and workers are not required to acknowledge a synchronous write.

3. API design

• POST /v1/resources — create a resource; accept an Idempotency-Key and return 201 plus its ID.
• GET /v1/resources/{id} — retrieve an authorized resource, with an ETag for conditional reads.
• PATCH /v1/resources/{id} — update with an expected version to detect conflicting edits.
• GET /health/live and /health/ready — distinguish process health from dependency readiness.

Use cursor pagination rather than large offsets. Return stable error codes, request IDs, and Retry-After for throttling.

4. Data model & storage

Use SQL for resource metadata and transactions: resources(tenant_id, id, version, payload, created_at, updated_at), with primary key (tenant_id, id) and indexes that match measured query patterns. Hash-shard by tenant_id only if a single database no longer meets capacity; isolate unusually large tenants to avoid hot shards. Store large immutable blobs in object storage and keep references in SQL. Redis holds short-lived, versioned read-through entries. A durable queue carries derived work, not the only copy of business state.

5. Deep dive

The key SLA decision is to define which work must complete before returning success. A create is acknowledged only after its SQL transaction commits. In the same transaction, write an outbox row; a publisher later delivers it to the queue. This avoids losing an event between committing data and publishing it. Consumers are idempotent because delivery may be at least once.

sequenceDiagram
  participant C as Client
  participant A as API
  participant D as SQL database
  participant O as Outbox publisher
  participant Q as Queue
  participant W as Worker
  C->>A: POST with idempotency key
  A->>D: Commit resource and outbox row
  D-->>A: Commit confirmed
  A-->>C: 201 Created
  O->>D: Read unpublished outbox rows
  O->>Q: Publish event
  Q->>W: Deliver at least once
  W->>D: Apply idempotent effect

I’d set timeouts from an end-to-end latency budget, propagate deadlines, and retry only transient failures with bounded exponential backoff and jitter. Retries must be safe through idempotency; otherwise they can amplify an outage.

6. Scale, bottlenecks & trade-offs

• Use multi-AZ database replication and automated failover; test recovery against explicit RPO and RTO targets. Add read replicas for read scale, accepting replication lag for non-critical reads.
• Cache hot reads, but define invalidation and tolerate cache loss. Protect the database with admission control, connection pools, and load shedding before it saturates.
• Keep the write path synchronous for durability and make secondary effects asynchronous. This trades immediate completeness for lower latency and better fault isolation.
• Within a region, favor strongly consistent SQL writes. For multi-region operation, choose explicitly between single-region write authority with simpler consistency and active-active writes with conflict-resolution complexity.
• Track availability, p50/p95/p99 latency, error rate, saturation, queue age, replication lag, and cache hit rate. Alert on user-facing SLO burn, not just host health; rehearse failover and rollback before relying on them.

Model answer

1. Requirements & scale

• Goal: reduce the risk and capacity limits of a system whose application depends on one database, without requiring a risky all-at-once rewrite.
• Functional requirements: preserve existing product behavior; support reads and writes; keep data consistent; enable recovery and incremental migration.
• Non-functional requirements: establish availability and latency targets, protect durability, support growth, and make database load and failure modes observable.
• Clarify first: Is the database a single instance or a managed cluster? What are its engine, workload, data size, write/read ratio, hot queries, and recovery objectives? “One database” could mean one server, or one logical database already backed by replicas.
• Illustrative scale assumptions: 10,000 requests/second, 70% reads and 30% writes, with 2 database operations per request gives about 20,000 database operations/second before batching or caching. At 1 KB per stored record and 100 million new records/year, raw growth is about 100 GB/year; indexes, replicas, and backups increase that substantially. Measure actual query fan-out and row sizes before sizing infrastructure.

2. High-level architecture

flowchart TD
    subgraph Client
        C[Web and mobile clients]
    end
    subgraph Edge
        E[CDN and WAF]
    end
    subgraph Load_Balancer
        L[Load balancer]
    end
    subgraph API_Services
        A[API services]
        R[Read routing]
        W[Write service]
    end
    subgraph Cache
        K[Distributed cache]
    end
    subgraph Datastores
        P[SQL primary]
        RR[Read replicas]
        S[Shard groups]
        B[Backup storage]
    end
    subgraph Message_Queue
        Q[Event queue]
    end
    subgraph Workers
        X[Async workers]
        M[Migration worker]
    end
    C -->|HTTPS requests| E
    E -->|filtered traffic| L
    L -->|API calls| A
    A -->|cache lookup| K
    K -->|miss| R
    R -->|read queries| RR
    A -->|transactional writes| W
    W -->|committed writes| P
    P -->|replication stream| RR
    W -->|outbox events| Q
    Q -->|async events| X
    P -->|snapshots and logs| B
    P -->|backfill reads| M
    M -->|validated data| S
    A -->|routed requests| S

I would not introduce every component immediately. The diagram shows a destination and transition options: first stabilize and measure the existing database, then add only the components justified by its bottleneck.

3. API design

• GET /v1/resources/{id} — read one resource; support cacheable responses where freshness permits.
• GET /v1/resources?cursor=... — paginated list; use cursor pagination rather than large offsets.
• POST /v1/resources — create with an idempotency key to make client retries safe.
• PATCH /v1/resources/{id} — update with a version or If-Match condition when lost updates matter.
• Keep external APIs stable while changing internal data routing. Add an internal migration or reconciliation endpoint only when operational access is required, and restrict it carefully.

4. Data model & storage

• Keep transactional, relational data in the current SQL engine initially. Use a highly available primary with synchronous durability appropriate to the recovery-point objective, plus asynchronous read replicas for scalable reads.
• Use a distributed cache for frequently read, non-sensitive data with explicit TTLs and invalidation behavior; never make it the source of truth.
• Publish asynchronous side effects through a transactional outbox and message queue, rather than attempting a database write and queue publish as an unsafe dual write.
• Back up to object storage and regularly test restore. Define RPO and RTO rather than assuming backups imply recoverability.
• If sharding becomes necessary, select a key that distributes load and matches common access patterns, such as tenant ID when tenant traffic is reasonably balanced. Keep a routing directory or deterministic mapping, and plan for hot tenants and cross-shard queries.

5. Deep dive

The first step is to find the actual constraint using query latency percentiles, lock waits, CPU, IOPS, connection saturation, replication lag, table growth, and top query patterns. Then I would make the lowest-risk improvement that addresses it: index or rewrite expensive queries, eliminate N+1 access, pool connections, bound queries, and add read replicas for read pressure. Replicas are not a fix for write saturation, and replication lag means they may serve stale reads.

For a larger migration, I would use an expand-and-contract approach. Add the new schema compatibly, backfill in bounded batches, capture concurrent changes through a change-data-capture stream or outbox, and compare records and aggregates. Route a small, reversible slice of reads to the new path; only move writes when consistency, rollback, and ownership are clear. Avoid uncontrolled dual writes: if temporary dual writes are unavoidable, make them idempotent, observable, and reconciled. The migration flow is:

sequenceDiagram
    participant App
    participant OldDB
    participant CDC as Change stream
    participant NewDB
    participant Check as Reconciliation
    App->>OldDB: Read and write current path
    OldDB-->>CDC: Publish committed changes
    CDC->>NewDB: Apply idempotently
    Check->>OldDB: Compare sampled records
    Check->>NewDB: Compare sampled records
    App->>NewDB: Gradually route validated reads
    App->>NewDB: Move writes after rollback checks

6. Scale, bottlenecks & trade-offs

• Availability: replicas and automated failover reduce single-instance risk, but failover can lose recent asynchronous writes or create brief unavailability. Choose consistency and RPO deliberately.
• Reads versus writes: replicas and caching help read-heavy workloads; they do not increase primary write capacity. Partitioning writes introduces routing, rebalancing, and cross-shard tran

Model answer

1. Requirements & scale

Functional requirements

• Sellers can schedule and host live shopping events, stream video, present items, and manage inventory.
• Buyers can discover and watch events, chat, follow a seller, and place bids or buy-now orders.
• The system must show a trustworthy current price, auction status, and winner, then support checkout and seller fulfillment.
• Moderators and sellers can remove content, pause an event, and manage abuse or policy violations.

Non-functional requirements

• Video should start quickly and remain watchable on variable networks; target startup under 3 seconds for most viewers.
• Bids must be serialized per auction, idempotent, auditable, and confirmed within roughly 500 ms at p99 under normal load.
• Viewing should remain available if chat or recommendations degrade. Protect against fraud, bot bidding, and abusive traffic.

Back-of-the-envelope estimates

• Assume 1 million concurrent viewers at peak and 10,000 active events. At 2 Mbps average video bitrate, CDN delivery is about 2 Tbps; origin must not serve each viewer independently.
• If 5% of viewers are active bidders and they average one bid-related action every 10 seconds, baseline bid traffic is about 5,000 requests/s. Allow 10x bursts, or 50,000 requests/s across the platform; a hot auction can be much more concentrated.
• At 1 million connected viewers sending a small heartbeat every 30 seconds, that is roughly 33,000 heartbeats/s. A 200-byte message is about 6.6 MB/s before protocol overhead.
• At 10,000 events per day, storing 2 MB of event metadata per event is only about 20 GB/day. Video is far larger, so it belongs in object storage and CDN workflows, not the transactional database.

2. High-level architecture

flowchart TD
  subgraph Client["Client"]
    B["Buyer app"]
    S["Seller studio"]
    M["Moderator console"]
  end
  subgraph Edge["Edge CDN"]
    CDN["Video CDN"]
    WAF["WAF and edge routing"]
  end
  subgraph LB["Load Balancer"]
    ALB["Regional API and socket balancers"]
  end
  subgraph API["API / Services"]
    E["Event service"]
    A["Auction service"]
    C["Chat service"]
    O["Order service"]
    V["Video control service"]
  end
  subgraph Cache["Cache"]
    R["Redis event and price cache"]
  end
  subgraph DB["Datastores"]
    SQL["SQL orders and auctions"]
    ES["Search index"]
    OBJ["Object storage for video"]
  end
  subgraph MQ["Message Queue"]
    Q["Partitioned event stream"]
  end
  subgraph Workers["Workers"]
    T["Transcode and package"]
    N["Notifications and analytics"]
    F["Fraud and moderation"]
  end
  B -->|"watch video"| CDN
  S -->|"upload live stream"| V
  V -->|"ingest stream"| T
  T -->|"segments and playlists"| OBJ
  OBJ -->|"origin fetch"| CDN
  B -->|"API and bid socket"| WAF
  S -->|"event controls"| WAF
  WAF -->|"validated requests"| ALB
  ALB -->|"event and catalog calls"| E
  ALB -->|"bid commands"| A
  ALB -->|"chat messages"| C
  E -->|"read and write"| SQL
  E -->|"discovery updates"| ES
  A -->|"current state"| R
  A -->|"durable bid transaction"| SQL
  A -->|"bid and auction events"| Q
  C -->|"chat events"| Q
  Q -->|"fanout and analysis"| N
  Q -->|"risk signals"| F
  N -->|"push updates"| ALB
  M -->|"moderation actions"| WAF

3. API design

• POST /v1/events — create or schedule an event; seller authorization required.
• POST /v1/events/{eventId}/stream-session — issue short-lived ingest credentials.
• GET /v1/events/{eventId} — event, items, and current status.
• POST /v1/auctions/{auctionId}/bids — submit a bid with Idempotency-Key, amount, and expected version.
• GET /v1/auctions/{auctionId} — retrieve authoritative price, state, and version.
• POST /v1/orders/{orderId}/checkout — initiate payment for a won or buy-now item.
• WebSocket /v1/events/{eventId}/stream — subscribe to bid, item, and chat updates; send chat, not authoritative bids.

4. Data model & storage

Use SQL for correctness-critical state: Auction(auction_id, event_id, item_id, status, current_price, leader_id, end_time, version), append-only Bid(bid_id, auction_id, bidder_id, amount, accepted_at, idempotency_key), and Order(order_id, auction_id, buyer_id, amount, payment_state). Partition bids by auction_id and time; shard auctions by auction_id, while routing each auction to one write owner. A transaction checks auction status, minimum increment, eligibility, and version before appending a bid and updating the leader.

Redis holds disposable read views, presence, and rate-limit counters; it is never the authority for accepting a bid. Search indexes events and items. Object storage keeps recordings and packaged video segments. The event stream carries durable state changes to notifications, analytics, and risk systems.

5. Deep dive

Auction correctness is the core challenge. Route every bid for one auction to the same logical partition or leader, which gives a total order without a global lock. The service validates the bidder and bid against the latest committed state, then commits the bid and auction update atomically. A duplicate idempotency key returns the original result. A stale client version receives a conflict and current state; a rejected bid never appears as accepted.

Use server timestamps. For anti-sniping, define the rule explicitly—for example, a valid bid in the final 10 seconds extends the end by 10 seconds, up to a configured cap. Apply that rule in the same transaction as bid acceptance. Emit the accepted event only after commit; downstream fanout is at-least-once and deduplicated by bid_id.

sequenceDiagram
  participant Buyer
  participant Auction as Auction service
  participant DB as SQL leader
  participant Stream as Event stream
  participant Fanout as Socket fanout
  Buyer->>Auction: Bid with idempotency key and version
  Auction->>DB: Validate and commit bid atomically
  DB-->>Auction: Accepted bid and new version

Model answer

1. Requirements & scale

Functional requirements

• Enforce configurable request limits for eBay public API clients, with quotas by application, endpoint, and where appropriate seller or buyer identity.
• Protect the platform from bursts and sustained abuse while allowing legitimate partners to grow through published quotas and a review path.
• Return clear limit headers and retry guidance; support emergency blocks, allowlists, and quota changes without deploying code.
• Provide auditability and near-real-time usage visibility to partners and internal teams.

Non-functional requirements

• Add less than 5 ms p99 in-region for the rate-limit decision; remain available during regional or datastore failures with an explicit degraded mode.
• Make decisions consistently for a given key across API gateway instances, resist spoofing, and scale horizontally.

Back-of-the-envelope estimates

Assume 100,000 active applications, 50,000 requests/second average, and a 3x peak of 150,000 requests/second. At roughly 200 bytes per decision event, raw analytics ingestion is about 10 MB/s at peak before compression. If active counters average 100 bytes and each app has 20 active endpoint windows, the hot counter set is around 200 MB; replication, metadata, and headroom make a multi-GB in-memory deployment reasonable. The request path should avoid writing every decision to durable storage synchronously.

2. High-level architecture

flowchart TD
  subgraph Client
    C[Partner applications]
  end
  subgraph Edge
    E[CDN and WAF]
  end
  subgraph Load_Balancer
    L[Regional load balancer]
  end
  subgraph API_Services
    G[API gateway]
    R[Rate limit library]
    P[Quota control plane]
  end
  subgraph Cache
    H[Local lease cache]
    X[Redis counter cluster]
  end
  subgraph Datastores
    D[Quota SQL store]
    A[Usage analytics store]
  end
  subgraph Message_Queue
    Q[Usage event stream]
  end
  subgraph Workers
    W[Usage and abuse workers]
  end
  C -->|API requests| E
  E -->|filtered traffic| L
  L -->|regional requests| G
  G -->|identity and route| R
  R -->|cached quota lease| H
  H -->|lease miss or atomic check| X
  P -->|quota updates| D
  P -->|publish policy| X
  R -->|decision event| Q
  Q -->|usage events| W
  W -->|aggregates and alerts| A
  W -->|abuse signals| P

The gateway authenticates first, derives a trusted app identity, and invokes a rate-limit library before expensive business logic. The control plane is separate from the low-latency data plane.

3. API design

• GET /sell/inventory/v1/offer — representative protected public API; gateway applies policy before forwarding.
• GET /developer/usage/v1/quotas — partner reads current limits and recent consumption.
• POST /developer/usage/v1/quota-requests — authenticated partner requests a quota increase with use case and forecast.
• PUT /internal/rate-limits/apps/{appId} — authorized internal control-plane update, with validation and audit record.
• POST /internal/rate-limits/blocks — emergency block or temporary restriction.

Responses include RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset, and Retry-After when denied. Return HTTP 429 for quota exhaustion, distinct from 401/403 authentication failures.

4. Data model & storage

• SQL stores authoritative policy: AppQuota(app_id, endpoint_group, identity_scope, limit, window_seconds, burst, policy_version, status). Partition by app_id; index by app and endpoint group. Store policy changes in an append-only audit table.
• Redis Cluster holds short-lived counters and token-bucket state. Hash by a stable key such as region|app_id|endpoint_group|subject_id; use TTLs aligned with the longest active window. Redis is a fast decision store, not the source of policy truth.
• A durable event stream carries sampled or aggregated usage and every denial; analytics storage supports partner dashboards, abuse investigations, and capacity planning without adding synchronous writes to the request path.

5. Deep dive

Use a hierarchical token bucket: a per-application bucket enforces the overall contract, while endpoint-group and sensitive-identity buckets prevent one route or account from consuming the whole allocation. A token bucket allows controlled bursts while bounding long-term rate. For capacity C, refill rate r, and elapsed time dt, compute tokens = min(C, tokens + r * dt); allow only if at least one token remains, then decrement atomically. Use Redis Lua or an equivalent atomic operation so concurrent gateway instances cannot double-spend tokens.

For hot applications, gateways can obtain small, short-lived token leases from Redis and spend locally, reducing central calls. Bound each lease to a small fraction of the global quota; otherwise many gateways could collectively overshoot. Reconcile lease usage asynchronously and revoke or stop renewing leases when policy changes. Keep a strict central check for high-risk operations.

sequenceDiagram
  participant Partner
  participant Gateway
  participant Redis
  participant API
  participant Stream
  Partner->>Gateway: Request with app credential
  Gateway->>Gateway: Authenticate and derive policy key
  Gateway->>Redis: Atomic bucket check
  Redis-->>Gateway: Allow or deny and remaining
  alt allowed
    Gateway->>API: Forward request
    API-->>Gateway: API response
  else denied
    Gateway-->>Partner: 429 with retry guidance
  end
  Gateway->>Stream: Publish usage decision asynchronously

If Redis is unavailable, do not blindly allow all traffic. Use a short-lived local lease for low-risk routes, fail closed for expensive or security-sensitive operations, and apply WAF emergency limits. Alert on degraded decisions and make the behavior configurable by route. Authenticate before choosing a quota key; never trust a caller-supplied app ID.

6. Scale, bottlenecks & trade-offs

Shard Redis by the complete quota key and replicate within

Model answer

1. Define the conversion

I’d start by specifying the desired action, eligible population, and time window. For example: “Of users who land on the sign-up page, what share completes account creation within seven days?” Conversion rate is not meaningful until numerator, denominator, and attribution rules are explicit.

1. Choose the formula

For a user-level funnel:

Conversion rate = unique eligible users who complete the target action / unique eligible users exposed to the opportunity

For an order funnel, I might instead use completed orders divided by checkout starts. The unit should match the question: users, sessions, leads, or opportunities. I would not mix user-level numerators with session-level denominators.

1. Instrument and calculate

I’d log a stable entity ID, event name, timestamp, eligibility or exposure, and relevant experiment assignment. I’d deduplicate repeated events and define what counts as completion—for example, a confirmed purchase rather than a button click. If attribution is within seven days, I’d count a user who completes within seven days of their first eligible exposure once in the numerator.

flowchart LR
  A[Eligible users exposed] --> B[Started target flow]
  B --> C[Completed target action]
  A --> D[Compute completed users divided by eligible users]

Example: if 1,000 unique users are exposed and 120 complete the defined action within the window, conversion is 120 / 1,000 = 12%.

1. Validate and interpret

I’d check event coverage, duplicate IDs, bot or employee traffic, timezone boundaries, and whether all users had equal opportunity to convert. I’d segment by channel, device, new versus returning users, and funnel step to locate differences, while avoiding conclusions from tiny samples. For experiments, I’d compare randomized groups and report uncertainty, not just a point estimate.

I’d also distinguish conversion rate from step conversion and overall conversion: a checkout-start-to-purchase rate answers a different question from landing-page-to-purchase. If users can convert multiple times, I’d clarify whether the metric is the share of users converting at least once or conversions per user.

What interviewers listen for: a precise denominator, consistent unit of analysis, explicit attribution window, clean event definitions, and careful interpretation.

Model answer

Definition

A microservice is a small, independently deployable service organized around a cohesive business capability. It owns a clear boundary, exposes that capability through an explicit interface, and can usually be developed and operated by a team with meaningful autonomy.

flowchart LR
    C[Client] --> G[API gateway]
    G --> O[Order service]
    G --> P[Payment service]
    O -->|payment request| P
    O --> OD[(Order data)]
    P --> PD[(Payment data)]

The key idea is not that every service must be tiny or use a particular language. It is that changes to one capability should not routinely require coordinated releases of the whole system. Services communicate through APIs or events, and each service owns its data rather than relying on unrestricted access to another service’s tables.

What the boundary needs

• Business cohesion: the service represents a capability or domain boundary, not merely a technical layer such as “all database calls.”
• Explicit contracts: APIs and events have versioning, validation, and compatibility expectations.
• Operational ownership: a team is accountable for deployment, monitoring, on-call response, and reliability.
• Data ownership: other services request behavior through the owning service instead of writing directly to its database.

Trade-offs

Microservices can improve independent deployment, team ownership, and targeted scaling. They also introduce network latency, partial failure, distributed tracing needs, data consistency challenges, and operational overhead. A monolith can be the better choice when a product or team is small, domain boundaries are still changing, or the organization cannot support reliable service operations.

As an Engineering Manager, I would avoid splitting services for fashion or org-chart symmetry. I would look for a real need—such as independent scaling, a stable domain boundary, or release coordination becoming a bottleneck—and compare that benefit with the added ownership and reliability cost. Useful measures include deployment lead time, change failure rate, service availability, cross-team dependency frequency, and the cost of operating each service.

Model answer

A microservice is a small, independently deployable service that owns a clearly defined business capability and exposes that capability through a stable interface, such as an HTTP API or message contract. For example, an ordering system might have separate Catalog, Checkout, and Payment services.

A good microservice has:

• A bounded responsibility: one team can understand and change its domain without coordinating every implementation detail with other teams.
• Clear ownership of data: the service is the source of truth for its domain; other services use its APIs or events rather than directly editing its tables.
• Independent deployment and scaling: teams can release or add capacity to one service without releasing the whole application.
• Operational responsibility: owners monitor availability, latency, errors, and dependencies, and have a plan for incidents and recovery.

flowchart LR
  A[Client] -->|Place order| B[Checkout service]
  B -->|Authorize payment| C[Payment service]
  B -->|Order event| D[Message broker]
  D -->|Update inventory| E[Inventory service]

The trade-off is that microservices reduce some forms of organizational and deployment coupling, but add network failure, data consistency, observability, and operational complexity. I would not split a system into services just because it is growing: I’d first look for a stable domain boundary, a team that can own the service end to end, and a measurable need for independent change or scaling. A modular monolith can be the better choice when those conditions aren’t present.

Model answer

I’d choose one recent project where I personally owned a meaningful technical decision, then use a smaller past project to show how my scope or judgment evolved. I would not try to list every project; I’d make the implementation and organizational impact easy to follow.

1. Context and stakes: Explain the product, users, team, scale, and business or reliability problem. Give a baseline—for example, request volume, latency, incident rate, or deployment frequency—and clarify what you owned versus what the team owned.
2. Architecture: Draw the system at a useful level, then trace one important request or data flow. Cover the API boundary, core services, storage, asynchronous work, and external dependencies. Be ready to explain the data model, consistency requirements, and failure behavior.
3. Your decisions: Pick two or three consequential choices. Explain the alternatives, constraints, trade-offs, and why you selected the design. For example: “We considered synchronous fan-out, but chose an outbox and queue because a downstream outage should not block the user write.” Be precise about what you personally designed, implemented, reviewed, or aligned across teams.
4. Operations and evolution: Describe rollout stages, observability, alerts, capacity planning, security, and recovery. Explain one real failure or unexpected result, how you diagnosed it, and what changed afterward. Mention how you handled migration or compatibility if the design replaced an existing system.
5. Impact and reflection: Quantify the result and connect it to user or organizational outcomes. State what you would change now and why.

flowchart LR
  U["User or client"] -->|"request"| A["API and service"]
  A -->|"read or write"| D["Primary data store"]
  A -->|"async event"| Q["Queue"]
  Q -->|"background processing"| W["Worker"]
  A -->|"metrics and traces"| O["Observability"]
  W -->|"metrics and traces"| O

A speakable opening could be: “The project I’ll focus on is [project]. We were trying to [user/business outcome] for [scale], and the main constraint was [constraint]. I owned [scope]. I’ll walk through the architecture, the hardest trade-off, and the measured result.”

At Principal level, I’d emphasize how the work changed more than one component: alignment across teams, reusable standards or platforms, migration strategy, risk reduction, and durable operational ownership. Interviewers listen for clear personal contribution, sound trade-off reasoning, credible metrics, and honest learning—not just a tour of technologies.