AI & Technical question

Ramp needs to support changing tax rules across US entities and international VAT/GST regimes. How would you design the product and underlying rule system so that most tax logic can be updated through configuration or data rather than bespoke code? Be specific about the abstractions, versioning, and auditability you would need.

Practice this question out loud. An AI interviewer asks it, follows up like a real interviewer would, and scores your answer. Type or speak.

What this question tests

Whether you can design a configuration-driven system architecture for a domain (tax rules) that changes constantly and requires strict auditability.

Model tax rules as versioned, structured data (rates, thresholds, jurisdiction-specific logic) rather than hardcoded conditionals, so updates are configuration changes, not code deploys.
Design a jurisdiction abstraction layer that separates universal tax-calculation logic from jurisdiction-specific parameters, so adding a new US entity type or VAT regime means adding data, not new code paths.
Version every rule set with an effective date range, so historical transactions always calculate against the rules that were active at the time, which is essential for audit and amendment.
Build an approval and staging workflow for rule changes: a tax or compliance owner reviews and approves before a new rule version goes live, with a clear audit trail of who changed what and when.
Add automated regression tests that run new rule versions against a fixed set of known-correct historical transactions before activation, catching unintended side effects.
Expose a reporting layer that can reconstruct exactly which rule version applied to any past transaction, satisfying audit requirements without engineering involvement.

Names the core architectural pattern precisely: versioned, dated rule sets over a jurisdiction abstraction layer, rather than a vague 'make it configurable' answer.
Explicitly separates calculation logic from jurisdiction data, which is the real technical unlock for scaling to new regimes without new code.
Requires effective-dated versioning specifically because tax rules change retroactively and historical transactions must remain reproducible for audits.
Includes a regression-test gate before any rule change goes live, since a bad tax rule change has direct compliance and financial consequences.

Describing configurability in general terms without the specific mechanism (jurisdiction abstraction, effective dating).
No mention of auditability or historical reproducibility, which is core to the question.
No approval or testing gate before a rule change goes live in a compliance-sensitive system.

How would you handle a jurisdiction whose tax logic genuinely cannot fit the standard abstraction?
What would you do if two rule versions conflict during a transition period?
How would you decide who has authority to approve a rule change?