Marketplace Seller SQL Interview Questions

Marketplace analytics interviews are not generic SQL screens. They test whether you can reconcile gross GMV against actual seller payout across a stack of fees, surface Buy Box loss windows that destroy daily revenue without a price change, identify cross-marketplace cannibalization where the same SKU is listed twice and split units across platforms, and build a board-pack waterfall that walks orders to fees to refunds to net cash. This guide walks through the SQL skills multi-marketplace sellers and platform-side analytics teams get asked about, with worked examples on an Amazon + Etsy + eBay-shaped schema and a 25-mission path that drills each pattern.

If you are interviewing for a marketplace operations seat at a brand running on Amazon Seller Central / Etsy / eBay, an analytics role at a marketplace platform, or a 3PL / aggregator with multi-marketplace inventory, the patterns below are the ones that show up in take-home assignments and live whiteboards.

What marketplace data actually looks like

Marketplace seller warehouses are organized around a fundamental reconciliation problem: GMV (gross merchandise value, the order amount) doesn’t equal payout (the cash the seller actually receives). Between gross and net sit four fee categories — marketplace fee (the platform’s take, 6.5–15% depending on platform), ad fee (sponsored-listing spend), fulfillment fee (FBA / shipping / pick-pack-ship), and refund amount (orders that came back). The job is to write the queries that walk gross to net cleanly, per marketplace, per month, per listing.

The caseSQL Marketplace database models that exact shape: fact_orders (~25K rows, GMV at the order grain), fact_settlements (~25K rows, 1:1 with orders, the four fee categories + net_payout), fact_listing_views (~108K rows, view stream for CTR analytics with organic / sponsored / external sources), and fact_buybox_snapshots (~10K rows, hourly Buy Box win-rate samples for Amazon listings only).

Around the facts sit two dimensions: dim_marketplaces (3 rows: Amazon at 15% take + FBA, Etsy at 6.5% take, eBay at 10% take), and dim_listings (~150 listings across 6 categories — Home Goods / Apparel / Beauty / Kitchen / Electronics / Outdoors). Listings include 20 deliberate cross-marketplace twins (same product_title, different listing_ids, different marketplaces) — the cannibalization signal you’ll detect in M18.

Question patterns you’ll be asked

Across multi-marketplace seller and platform-side interviews, six patterns dominate. Each one has a distinct SQL shape, and once you can recognize the shape you can almost always write the query. The worked examples below are deliberately adjacent to the exercises in the mission path — same skill, different angle — so you can read the example, then go practice the variant.

Settlement reconciliation (GMV ≠ payout)

“Why is your payout $215K when your gross was $312K?” is the most-asked question in marketplace interviews. The answer is the settlement reconciliation walk: gross minus marketplace_fee minus ad_fee minus fulfillment_fee minus refund_amount equals net_payout. The skill is aggregating four fee categories side-by-side and proving the equation balances.

Worked example, all-time settlement summary:

SELECT 'all' AS scope,
       ROUND(SUM(gross_amount)::numeric, 2) AS gross_total,
       ROUND(SUM(marketplace_fee)::numeric, 2) AS marketplace_fee_total,
       ROUND(SUM(ad_fee)::numeric, 2) AS ad_fee_total,
       ROUND(SUM(fulfillment_fee)::numeric, 2) AS fulfillment_fee_total,
       ROUND(SUM(refund_amount)::numeric, 2) AS refund_total,
       ROUND(SUM(net_payout)::numeric, 2) AS payout_total
FROM   fact_settlements;

Practice this in Mission #16 — and Mission #21 extends it to the per-(marketplace, month) three-way reconciliation report the CFO uses for audit-grade evidence.

Buy Box loss-window detection

Amazon-specific: ~80–90% of Amazon sales come through the Buy Box (the default buy button). Losing the Buy Box for several hours destroys daily revenue without you changing your price — a competitor underbid you. Detection is conditional aggregation on hourly snapshots, with a HAVING threshold to surface listings with multi-hour loss runs.

Worked example, listings that lost the Buy Box for at least 5 hours:

SELECT l.listing_id, l.product_title,
       COUNT(*) AS total_hours,
       SUM(CASE WHEN b.won_buybox_pct < 0.50 THEN 1 ELSE 0 END) AS loss_hours,
       ROUND(100.0 * SUM(CASE WHEN b.won_buybox_pct < 0.50 THEN 1 ELSE 0 END) / COUNT(*), 1) AS loss_pct
FROM   fact_buybox_snapshots b
       JOIN dim_listings l ON l.listing_id = b.listing_id
GROUP  BY l.listing_id, l.product_title
HAVING SUM(CASE WHEN b.won_buybox_pct < 0.50 THEN 1 ELSE 0 END) >= 5
ORDER  BY loss_pct DESC, l.listing_id ASC;

Practice this in Mission #17 — paired with Mission #23’s defense playbook ranking listings by loss volume + competitor count to prioritize the repricer-tool rollout.

Cross-marketplace cannibalization

Same product, two marketplaces. The seller listed it twice (different ASINs, same product). Now the inventory pools split, the price coherence breaks, and the channel-strategy team needs to know which products are cannibalized. Detection is a self-join on product_title with a marketplace_id mismatch.

Worked example, finding products listed on multiple marketplaces:

SELECT l.product_title,
       COUNT(DISTINCT l.marketplace_id) AS marketplace_count,
       SUM(o.units) AS total_units
FROM   fact_orders o
       JOIN dim_listings l ON l.listing_id = o.listing_id
GROUP  BY l.product_title
HAVING COUNT(DISTINCT l.marketplace_id) >= 2
ORDER  BY total_units DESC, l.product_title ASC;

Practice this in Mission #18 — and Mission #24 takes it deeper with per-side revenue split, surfacing pairs where one marketplace dominates 80%+ (a delisting candidate).

ROAS at listing grain

Marketplace-side ad spend lives on the settlement record (sponsored listings on Amazon, promoted listings on Etsy, promoted on eBay). ROAS at listing grain answers “which products are advertising profitably?” — pair it with a HAVING threshold to skip listings with statistically thin ad spend.

Worked example, top 20 listings by ROAS with ad spend ≥ $50:

SELECT l.listing_id, l.product_title,
       ROUND(SUM(s.ad_fee)::numeric, 2) AS ad_spend,
       ROUND(SUM(s.gross_amount)::numeric, 2) AS revenue,
       ROUND((SUM(s.gross_amount) / NULLIF(SUM(s.ad_fee), 0))::numeric, 2) AS roas
FROM   fact_settlements s
       JOIN fact_orders o ON o.order_id = s.order_id
       JOIN dim_listings l ON l.listing_id = o.listing_id
WHERE  s.ad_fee > 0
GROUP  BY l.listing_id, l.product_title
HAVING SUM(s.ad_fee) >= 50
ORDER  BY roas DESC, l.listing_id ASC LIMIT 20;

Practice this in Mission #14 — and Mission #19 extends it to the per-marketplace ad-attribution waterfall the marketing team uses for budget reallocation.

Dead-stock detection (anti-join)

Listings with view traffic but zero orders are budget bleeders — especially when the views are sponsored. Detection is a classic anti-join: dim_listings where listing_id NOT IN (SELECT DISTINCT listing_id FROM fact_orders).

Worked example, sponsored-view dead-zone listings:

SELECT l.listing_id, l.product_title, COUNT(*) AS sponsored_views, 0 AS orders
FROM   fact_listing_views v
       JOIN dim_listings l ON l.listing_id = v.listing_id
WHERE  v.source = 'sponsored'
  AND  l.listing_id NOT IN (SELECT DISTINCT listing_id FROM fact_orders)
GROUP  BY l.listing_id, l.product_title
HAVING COUNT(*) >= 50
ORDER  BY sponsored_views DESC, l.listing_id ASC;

Practice this in Mission #15 — for the broader case (any source) — and Mission #20 for the sponsored-only refinement that drives the pause-or-relist decision.

Per-marketplace P&L capstone

The board-pack capstone: per marketplace, last 12 months, the full waterfall — orders, gross, fees, refunds, net payout, margin pct. Six aggregates against a three-table join, scoped by settlement date.

Worked example, year-end capstone:

SELECT m.marketplace_name, COUNT(*) AS orders,
       ROUND(SUM(s.gross_amount)::numeric, 2) AS gross_revenue,
       ROUND(SUM(s.marketplace_fee + s.ad_fee + s.fulfillment_fee)::numeric, 2) AS total_fees,
       ROUND(SUM(s.refund_amount)::numeric, 2) AS refund_total,
       ROUND(SUM(s.net_payout)::numeric, 2) AS net_payout,
       ROUND((100.0 * SUM(s.net_payout) / SUM(s.gross_amount))::numeric, 1) AS margin_pct
FROM   fact_settlements s
       JOIN fact_orders o ON o.order_id = s.order_id
       JOIN dim_marketplaces m ON m.marketplace_id = o.marketplace_id
WHERE  s.settle_ts >= '2025-04-01'
GROUP  BY m.marketplace_name
ORDER  BY gross_revenue DESC, m.marketplace_name ASC;

Mission #25 is the path capstone — it composes M7 + M16 + M19 + M22 patterns into one query the CEO presents quarterly.

Gotchas that cost you the offer

Six mistakes show up reliably on marketplace seller analytics screens. They’re the difference between a candidate who has “done some SQL” and a candidate who has worked on a real multi-marketplace warehouse.

The 25-mission curriculum

The path is structured to walk from listing-catalog and order-shape fundamentals (free tier, M1–M10) through Buy Box and settlement-drift mechanics (Hard tier, M11–M15), the unit-economic constructions every seller-side CFO ships (Expert tier, M16–M20), and the multi-CTE capstones every senior marketplace analyst writes (Master tier, M21–M25). M25 is the per-marketplace P&L capstone — the metric every marketplace operator presents quarterly.

Frequently asked