← Google Interview Insights

Google·Software Engineer·Technical Phone Screen·Intermediate

Intermediate
May 2026

Summary

Google SWE interview that mixed OOD with an algorithm problem, which I wasn't fully expecting. The core question was about activity timeout detection from event logs, and the follow-ups kept coming until I was basically designing a mini distributed monitoring system.

Questions Asked (3)

Q1

Given a log of activity events (each with an activity ID, an event type of start/end/heartbeat, and a timestamp) plus a timeout threshold T, design clean data structures and classes to model this, and return all activity IDs that have timed out. An activity is timed out if it started but never received an end event or a recent enough heartbeat within T time units of its last event.

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

I started with the algorithm and they pulled me back to the class design first, which threw me off a bit.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and edge cases, then design a class-based model with an Activity class and an ActivityTracker that maintains a hash map from activity ID to activity state. For timeout detection, use a min-heap or balanced BST keyed by last event time to efficiently find expired activities, and discuss trade-offs between different approaches.

Pro tip: Mention that you would use a lazy deletion strategy with a min-heap to avoid scanning all activities, and highlight that this design supports efficient real-time timeout detection in a streaming scenario.

1. Clarify requirements and edge cases

Ask about input format, whether events are processed in real-time or batch, how to handle duplicate events, and what to do with activities that end before timeout.

2. Design data structures and classes

Define an Activity class with ID, last event timestamp, and status. Design an ActivityTracker class that uses a hash map for O(1) activity lookup and a min-heap for timeout ordering.

3. Outline event processing logic

Explain how to update activity state on start, heartbeat, and end events, including updating the last event time and adjusting the heap.

4. Implement timeout detection

Describe how to periodically check the min-heap for activities whose last event time is older than T, remove them, and return their IDs.

5. Discuss trade-offs and optimizations

Compare using a min-heap versus a balanced BST or sorted list, and discuss time/space complexity, concurrency, and scalability.

Key Points to Mention

  • Use a hash map for O(1) access to activity state by ID.
  • Use a min-heap keyed by last event timestamp to efficiently find the earliest expiring activity.
  • Lazy deletion: only remove timed-out activities when they reach the top of the heap.
  • Handle edge cases: activity ends before timeout, heartbeat after timeout, duplicate start events.
  • Time complexity: O(log n) for updates, O(1) amortized for timeout checks.
  • Consider concurrency and thread-safety if events arrive concurrently.

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

Q2

How would your approach change if the event log is guaranteed to arrive sorted by timestamp?

Algorithms & Data StructuresTechnical Trade-offs
Author's notes

Pretty clean answer here.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

First, clarify the problem context and what 'event log' entails (e.g., merging logs, detecting patterns). Then, explain how sorted input enables simpler, more efficient algorithms—like streaming or two-pointer techniques—and discuss trade-offs such as reduced memory and time complexity. Finally, mention any remaining challenges (e.g., out-of-order within same timestamp) and how to handle them.

Pro tip: Emphasize that sorted input often allows you to replace complex data structures (e.g., heaps) with simple pointers or queues, but always verify if the sort is stable and if timestamps are unique. This shows you consider edge cases and real-world data quirks.

1. Clarify the problem and assumptions

Restate the problem to ensure you understand what 'event log' means in this context (e.g., merging multiple logs, finding patterns). Confirm that the log is sorted by timestamp and ask about tie-breaking or duplicate timestamps.

2. Identify the impact of sorted input

Explain how sorted order eliminates the need for sorting or complex data structures, enabling single-pass algorithms with O(1) or O(n) space. Mention that you can process events in order, which is crucial for time-series analysis.

3. Propose an optimized algorithm

Describe a specific approach, such as using two pointers to merge logs, a sliding window for pattern detection, or a simple iteration for aggregation. Highlight the time and space complexity improvements.

4. Discuss trade-offs and edge cases

Acknowledge that sorted input may not always be guaranteed in production, so you might still need a fallback. Address edge cases like equal timestamps, missing data, or late-arriving events.

5. Summarize and connect to broader system design

Conclude by relating the approach to real-world systems (e.g., log processing pipelines) and mention how sorted input can simplify distributed processing or streaming architectures.

Key Points to Mention

  • Time complexity reduction: from O(n log n) to O(n) by avoiding sorting.
  • Space complexity: can use streaming with O(1) extra space instead of storing all events.
  • Algorithmic techniques: two-pointer, sliding window, or simple iteration.
  • Trade-offs: sorted input may not be guaranteed; need to handle unsorted data or verify sort stability.
  • Edge cases: duplicate timestamps, out-of-order events within same timestamp, and missing data.
  • Real-world application: log processing, event sourcing, and stream processing systems.

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

Q3

How would you handle this problem if the events were arriving as a continuous stream, potentially out of order, with a very large number of concurrent activities?

System DesignTechnical Trade-offsAdaptability & Ambiguity
Author's notes

This is where I started hand-waving a little.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the problem constraints and requirements, then propose a scalable architecture that handles out-of-order events and high concurrency. Discuss trade-offs between different approaches, focusing on correctness, scalability, and fault tolerance.

Pro tip: Demonstrate awareness of real-world challenges like exactly-once processing and late data by mentioning watermarks and windowing strategies. Show that you consider both theoretical guarantees and practical implementation details.

1. Clarify Requirements and Constraints

Ask questions to understand the scale, latency requirements, ordering guarantees, and fault tolerance needs. This shows you don't jump to solutions without understanding the problem.

2. Propose a High-Level Architecture

Outline a stream processing pipeline with components like message queues, stream processors, and state stores. Mention technologies like Apache Kafka, Flink, or Google Cloud Dataflow.

3. Address Out-of-Order Events

Explain techniques like event-time processing, watermarks, and windowing to handle out-of-order data. Discuss how to manage late events with allowed lateness or side outputs.

4. Ensure Scalability and Concurrency

Describe partitioning strategies, parallel processing, and load balancing to handle many concurrent activities. Mention auto-scaling and backpressure mechanisms.

5. Discuss Trade-offs and Failure Handling

Compare at-least-once vs exactly-once semantics, and discuss checkpointing, replication, and recovery strategies. Highlight trade-offs between latency, throughput, and cost.

Key Points to Mention

  • Event-time vs processing-time semantics and the use of watermarks
  • Windowing strategies (tumbling, sliding, session) and handling late data
  • Exactly-once processing guarantees and idempotent operations
  • Partitioning and key-based routing for scalability
  • Checkpointing and state management for fault tolerance
  • Backpressure and flow control to handle load spikes

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