Stripe Interviews

This section focused on building foundational data-integrity checks for fraud detection. The prompt was very long, but the logic itself was simple. I was tasked to read six fields from a CSV file and verify that all fields were non-empty.

On top of the basic transaction information, this part introduced two core risk-control rules:

• Amount rule: the transaction amount must fall within the business-defined normal range.
• Payment-method rule: the payment method must not appear in the blocked method list.

If a transaction violated any of these conditions, it was flagged as SUSPICIOUS.

This section required validating whether the transaction aligned with the user’s behavioral baseline. I had to ensure that at least 50% of the behavioral attributes—such as commonly used spending countries, typical time ranges, and average transaction-amount intervals—matched the user’s historical behavior. The implementation involved feature extraction, normalization, and computing a match ratio. If the current transaction’s match ratio was below 50%, it was classified as a behavior mismatch and flagged as SUSPICIOUS.

The final section implemented smart error reporting, replacing the vague label “SUSPICIOUS” with specific error codes. The system outputs up to two error codes according to priority. If there are no issues, it outputs “OK”. The output report must maintain column alignment for readability.

Stripe's Invoicing product allows businesses to create and send invoices to their customers. While many invoices can be paid directly, there are cases where standalone payments need to be reconciled with open invoices for a customer.

Your task is to write a program that matches incoming payments to their corresponding invoices based on the payment's memo line. An example input string for a payment looks like this:

payment="paymentABC,500,Paying off: invoiceC", invoices=["invoiceA,2024-01-01,100", "invoiceB,2024-02-01,200", "invoiceC,2023-01-30,1000"]

(Payment Format) Each comma-separated element represents a different piece of information about the payment:1. The payment ID (e.g. payment123)
2. The payment amount (in USD minor units e.g. $1.00 = 100)
3. The memo line, which always follows the format "Paying off: {INVOICE}"

(Invoices format) Each comma-separated element represents a different piece of information about the payment:
1. The invoice ID
2. The due-date for that invoice
3. The amount due on the invoice (in USD minor units e.g. $1.00 = 100)

Example input:

 f("payment5,1000,Paying off: invoiceC", ["invoiceA,2024-01-01,100", "invoiceB,2024-02-01,200", "invoiceC,2023-01-30,1000"])
Should return:

 payment5 pays off 1000 for invoiceC due on 2023-01-30

Each order contains a country, a product, and a quantity; each product has a fixed unit shipping fee. I was asked to compute the total shipping cost for all orders.

The unit price was no longer fixed; instead, it changed based on quantity tiers. For example: 1–10 units cost USD 1 per unit, and 11–20 units cost USD 0.8 per unit. I needed to calculate the total cost by summing across these pricing tiers.

The first problem involved calculating the total price based on an order object and a country-specific flat shipping table. I needed to compute the total price by summing each item’s unit price multiplied by its quantity, and then add a flat shipping fee based on the country. For example, in the U.S., if a mouse has a unit price of 550 and a laptop is 1000, the total shipping fee for the U.S. might be 16,000. Canada would have similar logic. The main tasks were handling JSON parsing and basic loop logic to aggregate the costs.

Building upon Level 1, shipping costs were no longer a fixed price but dynamically varied based on quantity—an “incremental cost” model. Each product could have multiple cost brackets, defined by quantity ranges. My task was to determine which bracket the current item's quantity fell into, then multiply the corresponding unit price from that bracket by the quantity, and sum it up. The problem highlighted the need for clear logic and correct handling of edge cases, such as maxQuantity = null, which indicated no upper bound for a bracket. Correctly matching the rule and accumulating the price was critical.

This stage introduced a new layer on top of Level 2: a 'type' concept with two calculation modes—'fixed' and 'incremental.' The 'incremental' mode functioned identically to Level 2. However, the 'fixed' mode meant that within a specific quantity bracket, the total price for that item was fixed and did not increase linearly with the quantity. For example, if I bought two laptops and they fell into a 'fixed' cost bracket of 1000, the total charge for those laptops would be 1000, not 2000. The primary challenge was integrating both these pricing logics ('fixed' and 'incremental') within the same calculation loop while ensuring correctness.

You are given two JavaScript objects: order and shipping. You need to calculate the total shipping cost for the given country in the order object.

order = {
    "country": "US",
    "items": [
        {"product": "mouse", "quantity": 5},
        {"product": "laptop", "quantity": 2}
    ]
}
shipping = {
"US": [
{"product": "mouse", "cost": 500},
{"product": "laptop", "cost": 1000}
],
"CA": [
{"product": "mouse", "cost": 700},
{"product": "laptop", "cost": 1200}
]
}

In this example, the total shipping cost would be 5 * 500 + 2 * 1000 = 4500.

Extend the previous problem. Now, if discounts are given for different quantities, how would you calculate the shipping cost? The shipping object has been modified to include quantity-based cost slabs.

shipping = {
    "CA": [
        {"product": "mouse", "cost": 500},
        {"product": "laptop", "cost": 1000}
    ],
    "US": [
        {"product": "mouse", 
         "cost": [{
                    minQuantity:0,
                    maxQuantity:2,
                    cost: 200
                    },
                  {
                    minQuantity:3,
                    maxQuantity:null,
                    cost: 700
                    }
                    ]
            },
        {"product": "laptop", 
            "cost": [{
                    minQuantity:0,
                    maxQuantity:null,
                    cost: 700
                    }
                    ]
                }
    ]
}

Using the original order (5 mice, 2 laptops in US), the shipping cost would be (3 * 200 + 2 * 700) + (2 * 700) = 600 + 1400 + 1400 = 3400. (Note: The provided example calculation 3 * 200 + 2 * 700 + 2 * 700 implicitly assumes 5 mice, where 3 fall into the minQuantity:3 slab and 2 into the minQuantity:0, maxQuantity:2 slab, which is a bit ambiguous; a more direct interpretation would be finding the *single* applicable slab for the *total* quantity of 5 mice, which is minQuantity:3, cost: 700, making it 5 * 700. However, following the example calculation 3 * 200 + 2 * 700 + 2 * 700, it implies a weighted average or a specific interpretation of how to apply multiple slabs for a single quantity. For clarity, I will assume finding the *single best matching slab* for the total quantity based on minQuantity being less than or equal to item quantity and maxQuantity being greater than or equal to item quantity, or null.)

Stripe’s Invoicing product allows businesses to create and send invoices to their customers. While many invoices can be paid directly, there are cases where standalone payments need to be reconciled with open invoices for a customer.

Your task is to write a program that matches incoming payments to their corresponding invoices based on the payment’s memo line.

You are given: • A payment string • A list of invoice strings

The payment string is a comma-separated string containing:

1. The payment ID (e.g., “payment123”)
2. The payment amount in USD minor units (e.g., $1.00 = 100)
3. The memo line, which always follows the format “Paying off: {INVOICE_ID}”

Each invoice string is also comma-separated and contains:

1. The invoice ID
2. The due date of the invoice (e.g., “2024-01-01”)
3. The amount due in USD minor units

You need to: • Parse the payment and invoices. • Find the invoice mentioned in the memo line. • Output a formatted string describing the reconciliation.

Input Example: payment = "payment5,1000,Paying off: invoiceC" invoices = [ "invoiceA,2024-01-01,100", "invoiceB,2024-02-01,200", "invoiceC,2023-01-30,1000" ]

Expected Output: payment5 pays off 1000 for invoiceC due on 2023-01-30

Be ready to generate the input on your own and write your own test cases to test the solution(more than 2).