rippling·Software Engineer·Onsite - System Design / Architecture·Senior

SeniorPrefer not to say

Jun 2026

Summary

Rippling system design round, one big open-ended question about building an expense rules engine from scratch. The scope was wider than I expected and I spent probably too long on the condition modeling before they nudged me toward the engine logic itself.

Questions Asked (1)

Design and implement an expense rules engine that takes an expense record and a configurable set of rules, then returns a decision of APPROVE, FLAG_FOR_REVIEW, or REJECT. Cover class design, rule combination policies, extensibility for new condition types, and how you'd test the system.

System DesignTechnical Trade-offsData Modeling

Author's notes

I started by talking through the data model for an expense record which felt safe, but the real meat was the condition abstraction.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and defining the core domain model (Expense, Rule, Decision). Then walk through the design of the rules engine, focusing on extensibility, rule combination policies, and testing strategy. Emphasize trade-offs and how your design supports adding new condition types without modifying existing code.

Pro tip: Demonstrate maturity by discussing how you'd handle conflicting rules and the importance of a deterministic, explainable decision. Mention that you'd log which rules fired and why, which is crucial for auditing and debugging in a financial system.

1. Clarify Requirements and Define Domain Model

Ask clarifying questions about rule types, combination policies, and performance needs. Define core classes: Expense, Rule, Condition, Action, Decision, and RuleEngine.

2. Design Rule and Condition Abstractions

Use the Strategy pattern for conditions (e.g., AmountCondition, CategoryCondition) and rules (e.g., SimpleRule, CompositeRule). Ensure new condition types can be added without modifying the engine.

3. Define Rule Combination Policies

Explain how multiple rules combine: e.g., priority-based, first-match, or weighted scoring. Discuss how to resolve conflicts and ensure deterministic outcomes.

4. Implement Extensibility and Configuration

Show how rules are loaded from configuration (e.g., JSON/YAML) and instantiated via factories. Highlight plugin architecture for new condition types.

5. Outline Testing Strategy

Cover unit tests for individual conditions and rules, integration tests for the engine with various rule sets, and property-based tests for combination policies. Mention mocking and test data generation.

Key Points to Mention

Use of design patterns: Strategy for conditions, Composite for rules, Factory for rule creation.
Rule combination policies: priority, first-match, or scoring; handling conflicts and ensuring determinism.
Extensibility: how to add new condition types without modifying existing code (Open/Closed Principle).
Configuration-driven rules: externalizing rules in JSON/YAML for flexibility.
Testing: unit, integration, and property-based tests; test doubles for isolation.
Explainability and auditing: logging which rules fired and why for transparency.

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