Goldman Sachs·Software Engineer·Technical Phone Screen·Intermediate

Intermediate

Apr 2026

Summary

Goldman Sachs software engineer round focused on a transaction approval system, building it up incrementally with extensibility as the core concern. Pretty design-heavy for what looked like a coding question on the surface.

Questions Asked (1)

Write a function that approves or rejects a transaction based on its merchant category code, starting with a single rule (reject if MCC equals 9999), and design it so additional rules like blocklists and velocity checks can be added cleanly later.

System DesignTechnical Trade-offsAPI & Integrations

Author's notes

The first rule itself is trivial, one if-statement and you're done.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the requirements and constraints, then propose a clean, extensible design using a rule-based or strategy pattern. Implement the initial rule (reject if MCC equals 9999) as a simple function or class, and outline how additional rules like blocklists and velocity checks can be plugged in without modifying the core logic. Emphasize separation of concerns, testability, and scalability.

Pro tip: Mention that in a real payments system, rules are often configured externally (e.g., via a rules engine or database) rather than hardcoded, so the design should allow dynamic rule updates without redeployment.

1. Clarify Requirements and Constraints

Ask about expected rule types, performance needs, and whether rules should be configurable at runtime. Confirm that the function should return a decision (approve/reject) and possibly a reason.

2. Design an Extensible Rule Interface

Define a common interface for rules, such as a Rule interface with an evaluate method that takes a transaction and returns a decision. This allows adding new rules without changing the core approval logic.

3. Implement the Initial Rule and Core Engine

Create a concrete rule for MCC 9999 and a simple engine that iterates over a list of rules, applying them in order. The engine returns reject if any rule rejects, otherwise approve.

4. Outline Future Rule Integration

Explain how blocklists and velocity checks can be added as new Rule implementations. For velocity checks, discuss the need for state (e.g., a counter or cache) and how to inject dependencies.

5. Discuss Trade-offs and Testing

Highlight trade-offs like rule ordering, short-circuiting, and performance. Emphasize unit testing each rule and the engine, and consider using a rules engine for complex scenarios.

Key Points to Mention

Single Responsibility Principle: each rule handles one specific check.
Open/Closed Principle: open for extension (new rules) but closed for modification (core engine).
Rule ordering and short-circuit evaluation for performance.
Dependency injection for rules that require external data (e.g., velocity checks).
Configuration-driven rules (e.g., via database or config files) for flexibility.
Testing strategy: unit tests for individual rules and integration tests for the engine.

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