rippling·Software Engineer·Technical Phone Screen·Intermediate

IntermediatePrefer not to say

May 2026

Summary

Rippling SWE interview with a system design coding problem around building a rules engine for a corporate expense card product. The problem was more design-heavy than pure algo, which I wasn't fully expecting going in.

Questions Asked (1)

Design and implement a rules engine for a corporate expense card system. Given a list of rules and a list of expenses, return which rules were violated by which expenses. Rules can include things like 'no restaurant charge over $75', 'no airfare', 'no expense over $250', 'trip total under $2000', and 'meal expenses per trip under $200'. The design should be extensible since new rule types will be added later via an API.

System DesignTechnical Trade-offsAPI & Integrations

Author's notes

The core of the question was really about abstraction, not the algorithm.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and defining the core entities (Rule, Expense, Violation) and the evaluation flow. Then design an extensible rule engine using a strategy or plugin pattern, where each rule type is a separate class implementing a common interface. Walk through the implementation for the given rules, and discuss trade-offs like performance, scalability, and API design for adding new rules.

Pro tip: Emphasize that rules should be stateless and idempotent, and consider pre-compiling rules or indexing expenses for performance. Also, mention the importance of a clear rule definition schema and versioning for the API to allow safe evolution.

1. Clarify Requirements and Scope

Ask questions to understand the exact behavior: Are rules evaluated per expense or per trip? What defines a trip? How are violations reported? What are the extensibility and performance requirements?

2. Define Core Entities and Interfaces

Identify the main objects: Rule, Expense, Violation, and RuleEngine. Define a Rule interface with a method like evaluate(expense, context) that returns a list of violations.

3. Design Extensible Rule Engine

Use a plugin or strategy pattern: each rule type is a class implementing the Rule interface. The engine loads rules dynamically (e.g., from a registry or via API) and evaluates them against expenses.

4. Implement Example Rules and Evaluation Logic

Show how to implement the given rules (e.g., RestaurantChargeRule, AirfareRule) and how the engine iterates over expenses and rules to collect violations. Consider context for trip-level rules.

5. Discuss Trade-offs and Extensibility

Talk about performance (e.g., indexing, parallel evaluation), API design for adding rules (e.g., JSON schema, versioning), and how to handle complex rules that depend on multiple expenses.

Key Points to Mention

Use of design patterns (Strategy, Plugin, Factory) for extensibility
Clear separation of concerns: rule definition, rule evaluation, and violation reporting
Handling of trip-level rules that require aggregation across expenses
API design for adding new rules dynamically, including validation and versioning
Performance considerations: indexing, caching, and parallel processing
Error handling and idempotency of rule evaluation

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