Katkat
Back

Design a String-Rule Validator for Transaction Records

StripeSoftware Engineer · Onsite
MediumSoftware EngineerOnsiteSoftware Engineering Fundamentals

Last updated

Specify transaction validation rules, parse them safely, evaluate name restrictions, and distinguish malformed input from ordinary rule rejection.

Design a validator for transaction records using rules supplied as strings. Example rule concepts prohibit a particular credit-card name or merchant name. Explain how you would define the rule language, parse transactions, evaluate rules, and test the behavior.

Constraints

The exact rule grammar, transaction encoding, combination semantics, and output format are unspecified. The examples establish name-based restrictions but do not define a complete language. Do not execute rule strings as unrestricted code. This is a specification-and-implementation discussion rather than a fixed console contract.

Clarifying Questions

  • How are field names, operators, values, quoting, and escaping represented in a rule?
  • Must a transaction satisfy every rule, any rule, or an explicitly grouped expression?
  • Are name comparisons case-sensitive, and what happens when a field is missing?
  • Should output contain accepted records, rejected records, or per-rule explanations?

Hints

Hint 1

Separate parsing from evaluation: A malformed rule and a well-formed rule that rejects a transaction are different outcomes.

Follow-up questions

  • How would an unknown field or unsupported operator be reported?
  • How would you retain useful rejection explanations without exposing unnecessary transaction data?