Design a Tunable Recurring-Transaction Detector
Company: Ramp
Role: Software Engineer
Category: Software Engineering Fundamentals
Difficulty: hard
Interview Round: Onsite
# Design a Tunable Recurring-Transaction Detector
You receive a file of transactions and need to identify likely recurring payments such as subscriptions. Real recurring charges may vary slightly in amount and interval, so the detector must expose tunable policies rather than hard-code one universal recurrence rule.
Design the record model, grouping strategy, detection algorithm, configuration, and output. Explain how an operator can adjust interval and price tolerances without rewriting the algorithm, and how you would evaluate whether a setting is useful.
### Constraints & Assumptions
- The input schema may include a transaction ID, timestamp, description or merchant identity, amount, account, and currency; state which fields your design requires.
- The full file may be unsorted, and duplicate records may occur.
- Different products can have weekly, monthly, annual, or irregular billing patterns.
- The base task asks for an explainable detector, not one fixed predicate or a guaranteed ground-truth label.
### Clarifying Questions to Ask
- Which fields reliably identify the same merchant or subscription family?
- Should the detector infer likely cadence, receive expected cadences as configuration, or support both?
- Are interval and amount tolerances absolute, relative, or cadence-specific?
- How should skipped charges, refunds, free trials, price changes, and multiple subscriptions to one merchant behave?
### What a Strong Answer Covers
- Normalization, deduplication, grouping, and chronological ordering
- Explicit configuration for minimum evidence, interval tolerance, amount tolerance, and allowed missed cycles
- Candidate-cadence inference without an all-pairs comparison
- A score or explanation that exposes why a group was classified as recurring
- Complexity, threshold calibration, edge cases, and tests
### Follow-up Questions
- How would you detect two subscriptions charged by the same merchant?
- How would the design work as transactions arrive continuously?
- Which labeled examples and metrics would you use to tune thresholds?
- When would a probabilistic model be preferable to deterministic rules?
Quick Answer: Design an explainable recurring-transaction detector for noisy subscription data. Explore normalization, grouping, cadence inference, configurable amount and interval tolerances, missed cycles, price changes, duplicate records, threshold evaluation, and the transition from batch files to streaming input.