stubhub·Backend Engineer·Technical Phone Screen·Senior

Senior

May 2026

Summary

StubHub backend interview focused on a single meaty design problem: build a filterable event recommendation engine from scratch. The whole conversation was around data structures, filter composition, and complexity tradeoffs. Pretty technical for a phone screen but not unreasonable for the role.

Questions Asked (1)

Design a simple event recommendation engine where each event has a location, date, and price. Support filters for proximity (distance in miles), date or date range, radius, and price range, and allow those filters to be combined into a single query. Walk through your data structures, how the filters compose, and the time complexity of each operation.

System DesignAlgorithms & Data StructuresTechnical Trade-offs

Author's notes

This is basically a mini system design plus algorithms question rolled into one.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and scale, then propose a hybrid indexing strategy: a spatial index (e.g., geohash or R-tree) for proximity, a time-ordered index (e.g., B-tree or sorted list) for date filtering, and a price index (e.g., balanced BST or sorted array) for price range. Explain how to intersect candidate sets from each index efficiently, and analyze time complexity for each filter and their combination.

Pro tip: Mention that for real-world systems like StubHub, you'd likely use a search engine like Elasticsearch with geo-point and range queries, but for this exercise, focus on core data structures and trade-offs. Also, discuss how to handle updates and scalability.

1. Clarify Requirements and Assumptions

Ask about scale (number of events, queries per second), data distribution, and whether filters are conjunctive (AND) or disjunctive. Assume events are static or have low update rate for simplicity.

2. Design Data Structures for Each Filter

For location: use a spatial index like geohash with a hash map from geohash to event IDs, or an R-tree. For date: use a balanced BST or sorted array of events by date. For price: use a balanced BST or sorted array by price.

3. Compose Filters Efficiently

For a combined query, retrieve candidate sets from each index (e.g., all events within radius, within date range, within price range), then intersect them. Choose the smallest candidate set first to minimize intersection cost.

4. Analyze Time Complexity

For each filter: proximity query O(log n + k) with R-tree or O(1) with geohash (but need to check neighbors), date range O(log n + m), price range O(log n + p). Intersection of sets of sizes k, m, p takes O(min(k,m,p) * log(max)) using hash sets or sorted merge.

5. Discuss Trade-offs and Optimizations

Mention trade-offs: geohash is simple but requires checking neighboring cells; R-tree is more accurate but complex. For high update rates, consider LSM-trees or inverted indices. Also, discuss caching frequent queries and using approximate filters (e.g., Bloom filters) to reduce work.

Key Points to Mention

Spatial indexing techniques: geohash, quadtree, R-tree, and their trade-offs in terms of precision and update cost.
Time complexity of range queries on balanced BSTs and sorted arrays, and how to handle duplicates.
Set intersection algorithms: hash join vs. sort-merge join, and choosing the smallest set to start.
Handling combined filters: using bitmaps or inverted indices for fast intersection.
Scalability considerations: sharding by location, caching, and using a search engine like Elasticsearch.
Edge cases: no events in range, overlapping filters, and dynamic updates.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.