← Google Interview Insights

Google·Software Engineer·Technical Phone Screen·Intermediate

IntermediatePrefer not to say
May 2026

Summary

Google SWE interview that came down to a hit counter design problem. Not the hardest thing in the world but the follow-up on complexity analysis took more time than I expected.

Questions Asked (1)

Q1

Design a hit counter class with a hit(timestamp) method and a getHits(timestamp) method that returns the number of hits recorded in the last 300 seconds.

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

Started with a queue of timestamps, which works fine but I fumbled explaining the space complexity when hits pile up.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements: hits are recorded at given timestamps, and getHits returns the count of hits in the last 300 seconds (inclusive of current timestamp). Then propose a solution using a queue or circular buffer to store timestamps, removing outdated hits on each call. Discuss time and space complexity, and consider optimizations for high throughput.

Pro tip: Mention that timestamps are monotonically increasing (a common assumption in such problems) and that you can use a circular array of size 300 for O(1) operations if timestamps are in seconds. This shows you think about practical constraints and efficiency.

1. Clarify requirements and assumptions

Ask about timestamp granularity (seconds vs milliseconds), whether timestamps are monotonically increasing, and if multiple hits can occur at the same timestamp. Confirm the definition of 'last 300 seconds' (e.g., inclusive of current timestamp).

2. Choose data structure

Select a queue (or deque) to store hit timestamps in chronological order, or a circular buffer if timestamps are in seconds and range is fixed. Explain why this structure supports efficient removal of outdated hits.

3. Implement hit and getHits

For hit(timestamp), append the timestamp to the queue. For getHits(timestamp), remove all timestamps from the front that are <= timestamp - 300, then return the queue size. Ensure operations are O(1) amortized.

4. Analyze complexity and trade-offs

Discuss time complexity: O(1) amortized per operation. Space complexity: O(number of hits in last 300 seconds). Compare with alternative approaches like using a hash map of counts per second, which uses O(300) space but may be less flexible.

5. Consider scalability and edge cases

Address high concurrency (e.g., using locks or thread-safe structures), memory usage under high hit rates, and edge cases like empty queue or timestamps far apart. Mention potential optimizations for distributed systems if relevant.

Key Points to Mention

  • Use of a queue/deque to maintain sliding window of hits
  • Amortized O(1) time per operation by removing outdated hits only when needed
  • Space complexity proportional to number of hits in the last 300 seconds
  • Assumption of monotonically increasing timestamps and its implications
  • Alternative approach: circular buffer of size 300 for O(1) space if timestamps are in seconds
  • Handling concurrency and thread safety in a real-world system

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