← Uber Interview Insights

Uber·Software Engineer·Technical Phone Screen·Intermediate

IntermediatePrefer not to say
May 2026

Summary

Uber SWE interview with a classic sliding window design problem. The question itself was clean but the follow-up about scale is where things get interesting and where I felt a bit underprepared.

Questions Asked (1)

Q1

Design a hit counter that tracks the number of hits received in the past 300 seconds. It should support a hit(timestamp) method and a getHits(timestamp) method. Timestamps are monotonically increasing and multiple hits can share a timestamp. Follow-up: how does your design hold up if hits per second can be extremely large?

Algorithms & Data StructuresSystem DesignTechnical Trade-offs
Author's notes

My first pass was a queue, just append timestamps on hit() and prune anything older than 300 seconds on getHits().

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and constraints, then propose a solution using a circular buffer or a queue with timestamp buckets. Discuss trade-offs between time and space complexity, and address the follow-up by considering scalability and concurrency.

Pro tip: Mention that timestamps are monotonically increasing, so you can use a queue and evict old entries efficiently. Also, for the follow-up, suggest sharding or using a distributed counter to handle high throughput.

1. Clarify Requirements

Ask about the expected scale, whether timestamps are in seconds, and if multiple hits per timestamp are allowed. Confirm that getHits should return hits in the past 300 seconds inclusive.

2. Design Basic Solution

Propose using a queue of timestamps or a circular buffer of size 300. For each hit, add timestamp; for getHits, remove timestamps older than timestamp-300 and return the count.

3. Optimize for Space and Time

If hits per second are high, use a bucket approach: an array of 300 buckets, each storing count for that second. Use modulo arithmetic to map timestamps to buckets and handle wraparound.

4. Address Follow-up: High Throughput

Discuss scaling: shard by timestamp or user, use distributed counters, or approximate counting with probabilistic data structures if exact count not required. Mention concurrency control.

5. Analyze Trade-offs

Compare queue vs bucket approach: queue uses O(n) space where n is hits in 300s, bucket uses O(300) space but may have collisions if multiple hits per second. Discuss precision vs memory.

Key Points to Mention

  • Monotonically increasing timestamps allow efficient eviction of old hits.
  • Circular buffer or bucket array of size 300 for O(1) time per operation.
  • Handling multiple hits per timestamp: bucket approach aggregates counts per second.
  • Space-time trade-off: queue stores individual hits, buckets store counts.
  • Scalability: sharding, distributed counters, or approximate counting for high throughput.
  • Concurrency: locking or atomic operations for thread safety.

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