Goldman Sachs·Software Engineer·Technical Phone Screen·Intermediate

IntermediatePrefer not to say

Apr 2026

Summary

Goldman Sachs SWE interview with a coding round focused on extending a fraud rules engine. The problem had real design weight to it, not just a leetcode warmup.

Questions Asked (1)

You're extending a fraud detection rules engine. Add a sliding 60-minute window check that rejects a transaction if the user's total approved amount within the past hour plus the new transaction's amount would exceed $5000. What data structure do you use, and what's the time complexity per check?

Algorithms & Data StructuresSystem DesignTechnical Trade-offs

Author's notes

I went with a per-user deque of (timestamp, amount) pairs.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the requirements: per-user sliding window, need to track approved transactions with timestamps, and compute sum of amounts in last 60 minutes. Propose a data structure like a deque (or balanced BST) per user to maintain the window, and analyze time complexity for each check, considering both average and worst-case scenarios.

Pro tip: Mention that in a real trading system, you'd also consider concurrency and persistence, and that the deque approach gives O(1) amortized time per check, which is crucial for high-throughput fraud detection.

1. Clarify Requirements and Assumptions

Confirm that the window is sliding (not fixed), that only approved transactions count, and that the check is per user. Ask about expected transaction volume and whether the system is distributed.

2. Choose Data Structure

Propose a per-user deque (double-ended queue) storing (timestamp, amount) pairs in chronological order. Alternatively, mention a balanced BST or a Fenwick tree if updates are frequent, but deque is simpler and efficient for sliding window.

3. Explain Algorithm for Check

On each new transaction, remove from the front of the deque all entries older than 60 minutes, maintain a running sum of amounts in the window, then check if running sum + new amount > 5000. If approved, add the new transaction to the back and update the sum.

4. Analyze Time Complexity

Each transaction is added once and removed once, so amortized O(1) per check. Worst-case for a single check could be O(n) if many expired entries are removed, but amortized over all checks it's O(1). Space complexity is O(n) per user for the window.

5. Discuss Trade-offs and Scalability

Mention alternatives like using a circular buffer or a balanced BST for O(log n) worst-case, and discuss how to handle multiple users (e.g., hash map from user ID to deque) and distributed scenarios (e.g., sharding by user).

Key Points to Mention

Sliding window semantics: only transactions within the last 60 minutes count.
Use of a deque (or queue) to maintain the window efficiently.
Running sum to avoid recomputing the sum each time.
Amortized O(1) time per check, with worst-case O(n) for a single check.
Space complexity O(n) per user, where n is the number of transactions in the window.
Considerations for concurrency, persistence, and distributed systems in a real-world setting.

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