PracHub
QuestionsLearningGuidesInterview Prep
|Home/Software Engineering Fundamentals/Ramp

Design a Tunable Recurring-Transaction Detector

Last updated: Jul 22, 2026

Quick Overview

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.

  • hard
  • Ramp
  • Software Engineering Fundamentals
  • Software Engineer

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.

Related Interview Questions

  • Build a Resilient Chain of Clue-Driven HTTP Requests - Ramp (hard)
  • Build a Wordle-Style Game in React - Ramp (medium)
  • Implement Spreadsheet Cells with Dependencies - Ramp (medium)
  • Implement a Single-Screen Tic-Tac-Toe Game with State Management - Ramp (medium)
|Home/Software Engineering Fundamentals/Ramp

Design a Tunable Recurring-Transaction Detector

Ramp logo
Ramp
Jul 18, 2026, 12:00 AM
hardSoftware EngineerOnsiteSoftware Engineering Fundamentals
1
0

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 Guidance

  • 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 Guidance

  • 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 Guidance

  • 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?
Loading comments...

Browse More Questions

More Software Engineering Fundamentals•More Ramp•More Software Engineer•Ramp Software Engineer•Ramp Software Engineering Fundamentals•Software Engineer Software Engineering Fundamentals

Write your answer

Your first approved answer each day earns 20 XP.

Sign in to write your answer.
PracHub

Master your tech interviews with 8,500+ real questions from top companies.

Product

  • Questions
  • Learning Tracks
  • Interview Guides
  • Resources
  • Premium
  • For Universities

Browse

  • By Company
  • By Role
  • By Category
  • Topic Hubs
  • SQL Questions
  • AI Coding Questions
  • Compare Platforms
  • Discord Community

Support

  • support@prachub.com
  • (916) 541-4762

Legal

  • Privacy Policy
  • Terms of Service
  • About Us

© 2026 PracHub. All rights reserved.