PayPal·Data Scientist·Technical Phone Screen·Senior

SeniorPrefer not to say

Jul 2026Remote

Summary

PayPal data scientist round focused entirely on a streaming anomaly detection problem. Pretty deep systems-thinking question for a DS role, felt more like a software engineering interview at points.

Questions Asked (1)

Design and implement a streaming login event processor that fires an alert whenever a user logs in from 4 or more distinct devices within any 10-minute sliding window. The function consumes a time-ordered stream of (user_id, timestamp, device_id, success) events. Walk through your data structures, eviction strategy, how you handle late-arriving events (up to 30 seconds), and the exact alerting semantics at window boundaries. Provide pseudocode.

Algorithms & Data StructuresSystem DesignTechnical Trade-offs

Author's notes

This was the whole interview basically.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and edge cases, then propose a per-user sliding window using a deque or timestamp-indexed structure to track distinct devices. Explain eviction, late-event handling with a 30-second buffer, and precise alerting semantics at boundaries. Finally, provide pseudocode and discuss trade-offs.

Pro tip: Explicitly define the window as half-open [t-10min, t) and state that alerts fire only when the distinct device count transitions from 3 to 4, avoiding duplicate alerts. This shows attention to boundary conditions and production readiness.

1. Clarify requirements and edge cases

Ask about event ordering, definition of 'distinct devices', alert frequency (once per window or per event), and handling of failed logins. Confirm the sliding window is half-open [t-10min, t) to avoid ambiguity.

2. Design data structures

Propose a per-user deque of (timestamp, device_id) for successful logins, plus a hash map from device_id to count for O(1) distinct device tracking. Alternatively, use a balanced BST or timestamp-indexed structure for efficient eviction.

3. Define eviction and late-event handling

Evict events older than t-10min from the front of the deque, updating device counts. For late events (up to 30s), maintain a small buffer and reorder by timestamp before processing, or use a watermark to allow out-of-order processing within the allowed lateness.

4. Specify alerting semantics

Alert when the distinct device count reaches 4 within the window. To avoid duplicates, alert only on the transition from 3 to 4 distinct devices. After an alert, either suppress further alerts until the window clears or reset the count, depending on requirements.

5. Provide pseudocode and discuss trade-offs

Write clear pseudocode for the streaming processor, including eviction, late-event handling, and alert logic. Discuss time/space complexity, scalability, and potential optimizations like approximate counting for high-cardinality users.

Key Points to Mention

Sliding window semantics: half-open interval [t-10min, t) to avoid double-counting at boundaries.
Data structures: deque for ordered events and hash map for distinct device counts, enabling O(1) updates and O(1) eviction per event.
Late-arriving events: buffer up to 30 seconds, use watermarks or reordering to process out-of-order events correctly.
Alerting semantics: fire only on transition from 3 to 4 distinct devices; define cooldown or reset behavior to prevent alert storms.
Handling failed logins: filter out events where success is false, or clarify if they count toward the threshold.
Scalability and trade-offs: per-user state, memory usage, and potential for approximate algorithms (e.g., HyperLogLog) for high-cardinality users.

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