Goldman Sachs·Software Engineer·Technical Phone Screen·Intermediate

Intermediate

Apr 2026

Summary

Goldman Sachs SWE round focused on extending a fraud rules engine with MCC-based filtering. One coding problem, but it had enough layers to keep you busy for the full session.

Questions Asked (1)

You have an existing fraud rules engine. Extend it to reject transactions whose MCC code appears in a global blocklist, and also in a per-user blocklist (each user can have their own set of blocked MCC codes). The function signature stays the same. Keep the design extensible for future rule additions.

System DesignTechnical Trade-offsAlgorithms & Data Structures

Author's notes

The global blocklist part was fine, basically a set lookup.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the existing rules engine architecture and the function signature, then propose a rule-based design where each rule is a separate class implementing a common interface. For the MCC blocklist, implement two rules: one for global blocklist and one for per-user blocklist, and integrate them into the engine without changing the signature. Emphasize extensibility by showing how new rules can be added with minimal changes.

Pro tip: Discuss the trade-offs between checking global and per-user blocklists in terms of performance and data consistency, and suggest caching strategies for per-user blocklists to reduce latency. Also, mention the importance of logging and monitoring for fraud rules to detect false positives.

1. Clarify Requirements and Constraints

Ask about the existing engine's design, the function signature, and how rules are currently evaluated. Confirm whether the blocklists are static or dynamic, and the expected latency and throughput.

2. Design Rule Abstraction

Propose a Rule interface with a method like `evaluate(transaction, userContext)` returning a boolean or decision. Each rule encapsulates its logic, promoting extensibility and separation of concerns.

3. Implement MCC Blocklist Rules

Create two concrete rules: GlobalMCCBlocklistRule and UserMCCBlocklistRule. The global rule checks a static set, while the user rule checks a per-user set fetched from a data store.

4. Integrate with Existing Engine

Register the new rules with the engine's rule registry or pipeline, ensuring the function signature remains unchanged. The engine should evaluate all rules and reject if any rule triggers.

5. Address Extensibility and Performance

Discuss how to add future rules (e.g., velocity checks) by simply adding new Rule implementations. Mention caching per-user blocklists and using efficient data structures like sets for O(1) lookups.

Key Points to Mention

Strategy pattern or chain of responsibility for rule evaluation
Separation of global and per-user blocklists as distinct rules
Use of efficient data structures (HashSet) for O(1) MCC lookups
Caching per-user blocklists to reduce database calls
Maintaining backward compatibility by not changing the function signature
Logging and metrics for rule triggers to monitor effectiveness

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