Model ownership before checkout. Search results can be stale, so define where availability becomes authoritative and what a reservation owns.
Official StubHub pages describe a live-event ticket marketplace and an API for marketplace access. Those sources support marketplace context; they do not verify a universal interview loop or the exact exercises below.
Version listing changes. Seller edits, imports and search projections can arrive out of order. Keep raw evidence and make the projected state rebuildable.
Treat timeout as uncertainty. A lost response after reservation, payment or order creation requires lookup by stable identity before the system repeats a scarce-inventory action.
Explore your preparation priorities
Choose a focus to see how to prepare.
Define the contract
Contract: identify durable state and the evidence that confirms it.
YOUR PREPARATION- Name the logical operation and the state visible before confirmation.
- List the invariants a retry must preserve.
PracHub practice map for marketplace. Select a checkpoint to connect the contract, concurrency boundary and failure response to a practice prompt.
Define inventory ownership
editorialName listing, reservation, checkout and order identities plus the transition that grants temporary ownership.
What to demonstrate
- Concurrency boundaries
- Expiry semantics
How to prepare
- Race two buyers.
- State what expiry means during payment.
Protect listing versions
editorialReject stale or conflicting updates without losing the raw marketplace event.
What to demonstrate
- Versioning
- Auditability
How to prepare
- Deliver updates out of order.
- Rebuild the search projection.
Reconcile ambiguous checkout
editorialSeparate reservation, payment and order evidence before releasing inventory or asking a buyer to try again.
What to demonstrate
- Idempotency
- Incident response
How to prepare
- Lose the checkout response.
- List evidence needed before release.
13 candidate reports. Individual accounts describe a particular role and hiring cycle.
Stubhub Software Engineer interview with a 75-minute pair programming round
My interview process started with an HR behavioral round, followed by a CodeSignal assessment and then a face-to-face technical sequence. The technical portion included a 75-minute pair programming round and a system design round. The process ended after the system design interview, and I was rejected at that final technical stage. It felt like a typical multi-round pipeline, but the rejection se…
Read full experienceStubhub Software Engineer interview with a shortened project deep dive
I started with a recruiter screen that already felt off. There was a missed call, and after I reached back out, I waited about two weeks just to hear about moving to the next round. When I was scheduled for the hiring manager interview, the hiring manager I was connected with didn't match what the email said. The project deep dive also didn't match the schedule. It was supposed to last 45 minutes…
Read full experienceStubhub Software Engineer interview with repeated scheduling problems
The process started with scheduling, and it quickly became clear that it wasn't being handled with much care. The recruiter didn't show up for the originally scheduled interview at all. After I reached out to reschedule, I didn't get a real response. I joined the rescheduled call anyway, only for the recruiter to arrive late and act as if the situation was an inconvenience rather than something t…
Read full experienceStubhub Software Engineer: email-system design and an early coding cutoff
My process started with a friendly recruiter screen about my background and previous work. I could tell the recruiter was listening for specifics, and we went past the scheduled time because I kept adding context. A couple of weeks later, I still hadn’t heard back, and I eventually received an automated rejection. The technical rounds focused more on practical engineering ideas than on algorithms…
Read full experienceStubhub Software Engineer interview: Codility, CodeSignal, and resume-based technical screen
The process moved quickly into online testing and stopped just as fast. I took a Codility-style assessment with a limited time window and submitted everything before time ran out, but I never heard back. At another stage, I completed a CodeSignal assessment with several LeetCode-style questions. The focus was on getting working solutions rather than writing the most elegant algorithms. I ran out…
Read full experiencePracHub editorial advice for the preparation topics above.
Follow the state, not just the happy path
Choose a scenario to trace what changes.
The expected version still matches the stored state.
- 01Edit version 3Edit version 3.
- 02Compare versionCompare version.
- 03Save version 4Save version 4.
Commit one new version and return durable confirmation.
Use three outcomes to reason about marketplace: a confirmed write, a version conflict and a lost response.
Treating search as authoritative inventory
Recheck availability at an atomic reservation boundary.
Creating a new checkout identity after timeout
Reuse the logical checkout and return its recorded result.
Projecting stale listing updates
Require monotonic versions and retain an auditable conflict path.
Joining tickets directly to payouts
Aggregate both sides at order grain before reconciliation.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Merge available seat ranges
Given inclusive seat-number ranges within one row, validate and merge overlapping or adjacent ranges without mutating the input.
Approach
- Sort a copy by start.
- Extend the last range when the next start is at most last_end + 1.
Worked solution 35 min
- Validate integer inclusive ranges.
- Merge overlap or adjacency.
def merge_seat_ranges(ranges):
clean = []
for start, end in ranges:
if not isinstance(start, int) or not isinstance(end, int) or start < 1 or end < start:
raise ValueError("invalid seat range")
clean.append((start, end))
clean.sort()
merged = []
for start, end in clean:
if merged and start <= merged[-1][1] + 1:
merged[-1] = (merged[-1][0], max(merged[-1][1], end))
else:
merged.append((start, end))
return merged
Scroll sideways to view long lines.
Follow-up
- How would obstructed-view or price attributes change the merge key?
Accept listing updates once
Given seller, listing ID, version and payload records, keep the newest version, ignore exact replays and reject conflicting payloads for one version.
Approach
- Store the latest version and a fingerprint per listing.
- Reject version regression and conflicting reuse before changing availability.
Follow-up
- How do you support an authorized correction to an older event?
Count recent reservation attempts
Implement add(timestamp) and count(now) for attempts in (now - 10, now]. Timestamps are nondecreasing and equal timestamps are distinct.
Which events still count?
The left boundary is excluded; the right boundary is included. Drag past an event to see it enter, then expire 10 seconds later.
See the event values
- At 0s: +1 — expired
- At 5s: +1 — in window
- At 10s: +1 — in window
- At 14s: +1 — not arrived
- At 19s: +1 — not arrived
Synthetic reservation attempts at 0, 5, 10, 14 and 19 seconds. Drag the clock: the interval is (now - 10, now], so the lower boundary is excluded.
Approach
- Use a deque.
- Expire timestamps at or before the lower boundary.
Follow-up
- How would you apply independent limits per event and account?
Find the latest state for every listing
Given listing_events(listing_id, version, received_at, state), return the latest row per listing using version as a deterministic tiebreaker.
Approach
- Rank within listing by received_at and version descending.
- Select rank one before filtering by state.
Follow-up
- How should a late lower version be audited?
Reconcile orders and seller payouts
For each completed order, return sold cents and total payout cents without multiplying payouts when an order has multiple tickets.
Approach
- Aggregate payouts at order grain before joining.
- Join on stable order identity and preserve orders awaiting payout.
Worked solution 35 min
- Insert completed orders and payout events.
- Aggregate payout events by order.
- Left join to keep unpaid completed orders.
CREATE TABLE orders (order_id TEXT PRIMARY KEY, sold_cents INTEGER, state TEXT);
CREATE TABLE payouts (order_id TEXT, payout_cents INTEGER);
INSERT INTO orders VALUES ('o1',10000,'completed'),('o2',6000,'completed'),('o3',5000,'pending');
INSERT INTO payouts VALUES ('o1',4000),('o1',5000);
WITH paid AS (SELECT order_id,SUM(payout_cents) AS cents FROM payouts GROUP BY order_id)
SELECT o.order_id,o.sold_cents,COALESCE(p.cents,0)
FROM orders o LEFT JOIN paid p ON p.order_id=o.order_id
WHERE o.state='completed' ORDER BY o.order_id;
Scroll sideways to view long lines.
Follow-up
- How would refunds and chargebacks alter the ledger?
Design a ticket reservation flow
Design search-to-checkout for scarce ticket inventory when many buyers can select the same listing and clients may retry.
Approach
- Keep listing availability authoritative and create a short-lived reservation atomically.
- Use one checkout identity, explicit expiry and reconciliation with order creation.
Worked solution 35 min
- Atomically reserve available inventory with expiry.
- Bind checkout retries to one logical ID.
- Create at most one order per reservation.
- Reconcile unknown payment and order outcomes before release.
Follow-up
- What user experience should follow an expiry during payment?
Design replay-safe listing ingestion
Ingest seller listing updates that may be duplicated, delayed or out of order while preserving an audit trail.
Approach
- Use listing identity plus monotonic version.
- Store raw events, reject conflicts and project search state asynchronously with lag metrics.
Follow-up
- How do you rebuild the search projection safely?
Stop a retry from overselling a listing
Checkout times out after reservation succeeds. The client retries with a new checkout ID and both paths create orders. Reproduce the race and repair it.
Approach
- Trace reservation and order identities across the lost response.
- Enforce one order per reservation and return the recorded result to the same logical retry.
Worked solution 35 min
- Pause after reservation and order commit but before reply.
- Retry with the original checkout identity.
- Enforce uniqueness on reservation-to-order.
- Reconcile before releasing inventory.
Follow-up
- What evidence is required before releasing or extending the reservation?
A seven-session PracHub practice plan with one reviewable artifact per session. Adjust the pace to your experience and interview date.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Map marketplace identities
- Define listing through order IDs.
- Mark authoritative state.
Deliverable: An inventory state map
02Practice interval logic
- Run the range solution.
- Add adjacent and invalid ranges.
Deliverable: A tested range function
Practice prompt ↗03Query payout evidence
04Design scarce inventory
- Race two reservations.
- Define expiry during payment.
Deliverable: A reservation design
Practice prompt ↗05Design listing replay
- Deliver updates out of order.
- Rebuild the search view.
Deliverable: A listing ingestion design
Practice prompt ↗06Debug overselling
- Reproduce the lost-response race.
- Name the uniqueness rule.
Deliverable: A failure timeline
Practice prompt ↗07Rehearse decisions
- Explain one user-trust decision.
- Review one peak-event plan.
Deliverable: Two evidence-backed stories
Practice prompt ↗Practice prompt ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Use real examples. Name your responsibility, the evidence available at the time and what changed after the decision.
Explain a customer-impact decision
Describe a real incident or product decision where user trust and delivery speed were in tension.
Approach
- Name the affected workflow and evidence.
- Explain containment, communication and the decision threshold.
Follow-up
- Which metric or user signal changed afterward?
Resolve a marketplace trade-off
Tell a story where two user groups or business partners needed incompatible behavior.
Approach
- Represent both constraints fairly.
- Show the reversible experiment or policy boundary that supported the decision.
Follow-up
- What did you choose not to optimize?
Prepare for a high-demand event
Describe a time you prepared a system for a predictable traffic spike or critical deadline.
Approach
- Explain capacity evidence and failure modes.
- Show load testing, degradation and rollback choices.
Follow-up
- What surprised you under real load?
- 01
Bring one result you improved and one decision you changed after seeing evidence.
Are these verified Stubhub interview questions?
No. They are PracHub editorial exercises informed by official marketplace and careers context. The reviewed official pages do not publish a universal question list.
StubHub — About us ↗StubHub — Marketplace API introduction ↗Should I use one particular language?
Use the language named in your invitation. The runnable examples use Python and SQLite to expose the contracts; translate the tests and invariants to your interview stack.
Is seven days enough?
The checklist is a suggested sequence, not a readiness guarantee. Repeat weak areas and follow the schedule for your exact interview.
Sources & methodology 5 sources ↗
Official role evidence, timestamped platform data and clearly labeled preparation advice.
- 01StubHub — About us ↗
Official context only; no universal interview process is stated.
official · Accessed 2026-09-20 - 02StubHub — Marketplace API introduction ↗
Official API and marketplace context; not an interview-process source.
official · Accessed 2026-09-20 - 03StubHub — How StubHub was born ↗
Official marketplace history and trust context.
official · Accessed 2026-09-20 - 04PostgreSQL — Window functions ↗
Technical reference for SQL reasoning. Runnable fixtures use SQLite.
official · Accessed 2026-09-20 - 05PracHub — Software Engineer practice ↗
Cross-company practice; not evidence of company interview questions.
platform · Accessed 2026-09-20