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

SeniorPrefer not to say

Jun 2026Remote

Summary

Rippling system design round focused on extending an expense rule engine to handle trip-level aggregations. The problem was meaty and had a lot of moving parts, more than I expected for a single session.

Questions Asked (1)

You have an existing expense rule evaluation system. Extend it to support trip-level aggregate rules, such as a cap on total trip expenses and a cap on total meal expenses per trip. Trip '002' violates both rules in the sample data. How do you redesign the system and update the return type of the rule evaluation function to surface both per-expense and per-trip violations?

System DesignAPI & IntegrationsTechnical Trade-offs

Author's notes

This is the kind of question where you feel okay for the first five minutes and then realize you've been thinking too small.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the existing system's architecture and the current rule evaluation function's return type. Then propose a redesign that separates per-expense and per-trip rule evaluation, likely introducing a new aggregate rule type and a result object that encapsulates both types of violations. Finally, discuss how to update the return type to include trip-level violations, ensuring backward compatibility and extensibility.

Pro tip: Emphasize the importance of maintaining a clean separation of concerns: per-expense rules should remain stateless and independent, while trip-level rules require aggregation. This shows you understand scalability and maintainability.

1. Understand current system and requirements

Ask clarifying questions about the existing rule evaluation flow, data model, and how rules are currently defined and executed. Confirm the expected behavior for trip-level aggregates.

2. Design rule abstraction for aggregates

Introduce a new rule type (e.g., TripAggregateRule) that operates on a collection of expenses for a trip. Define how these rules are registered and evaluated alongside existing per-expense rules.

3. Redesign evaluation function return type

Change the return type to a structured object that contains both per-expense violations and per-trip violations, possibly grouped by trip ID. Ensure it's extensible for future rule types.

4. Implement aggregation and evaluation logic

Describe how to compute aggregates (e.g., sum of expenses, sum of meal expenses) per trip and apply trip-level rules. Discuss efficiency considerations like single-pass aggregation.

5. Handle sample data and validate

Walk through how trip '002' would be evaluated, showing both violations are surfaced. Discuss testing strategy and potential edge cases.

Key Points to Mention

Separation of concerns: per-expense vs. per-trip rules
Extensible rule engine design (e.g., strategy pattern, rule registry)
Return type design: use of DTOs or result objects with clear fields
Aggregation efficiency: avoid multiple passes over expenses
Backward compatibility: how existing consumers of the function are affected
Error handling and reporting: how violations are represented and communicated

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