Design a Data-Driven Expense Rule Evaluator

Quick Overview

Design an expense-policy evaluator whose rules are stored as validated JSON so policies can be added or changed without deploying code. Make the API or object boundaries explicit, then cover invariants, edge cases, testing strategy, and operational trade-offs.

Design a Data-Driven Expense Rule Evaluator

Company: Rippling

Role: Software Engineer

Category: Software Engineering Fundamentals

Difficulty: medium

Interview Round: Onsite

# Design a Data-Driven Expense Rule Evaluator Design an expense-policy evaluator whose rules are stored as validated JSON so policies can be added or changed without deploying code. ### Constraints & Assumptions - Rules use allowlisted operators and versioned schemas. - Every decision must be explainable. ### Clarifying Questions to Ask - Can rules conflict, and what precedence applies? - Who may publish a version? ### What a Strong Answer Covers - Typed rule schema, validation, safe interpretation, versioning, audit, and tests. ### Follow-up Questions - How would staged rollout work? - How would historical decisions be reproduced?

Quick Answer: Design an expense-policy evaluator whose rules are stored as validated JSON so policies can be added or changed without deploying code. Make the API or object boundaries explicit, then cover invariants, edge cases, testing strategy, and operational trade-offs.

|Home/Software Engineering Fundamentals/Rippling
Rippling logo
Rippling
Jul 27, 2026, 12:00 AM
mediumSoftware EngineerOnsiteSoftware Engineering Fundamentals
1
0

Design a Data-Driven Expense Rule Evaluator

Design an expense-policy evaluator whose rules are stored as validated JSON so policies can be added or changed without deploying code.

Constraints & Assumptions

  • Rules use allowlisted operators and versioned schemas.
  • Every decision must be explainable.

Clarifying Questions to Ask Guidance

  • Can rules conflict, and what precedence applies?
  • Who may publish a version?

What a Strong Answer Covers Guidance

  • Typed rule schema, validation, safe interpretation, versioning, audit, and tests.

Follow-up Questions Guidance

  • How would staged rollout work?
  • How would historical decisions be reproduced?
Loading comments...