Stripe Interview Questions
- DSA
- LLD
- HLD
Q1: Application ID Parsing and Whitelist Filtering
You are given a string representing application IDs where each application ID is prefixed by its length (the number of characters in the ID), followed by the ID itself, and the string ends with a 0. For example, the input “10A13414124218B124564356434567430” contains two IDs. The first ID has length 10, so extract the next 10 characters (“A134141242”), then the next ID has length 18, extract those 18 characters (“B12456435643456743”), and finally the string terminates with 0. In Part 1, write a function to extract all application IDs from the input string. In Part 2, given a whitelist array of application IDs, filter the extracted IDs to return only those that appear in the whitelist array. Handle edge cases such as malformed input, empty strings, and ensure efficient lookup using data structures like hash sets for whitelist checking.
Example Input: “10A13414124218B124564356434567430”
Example Output: [“A134141242”, “B12456435643456743”]
Part 2 Input: “10A13414124218B124564356434567430”, [“A134141242”]
Part 2 Output: [“A134141242”]
Q2: Invoice Reconciliation with Payment Matching
Stripe’s invoicing product allows businesses to create and send invoices to their customers, and when standalone payments are received, they must be reconciled with open invoices. You are given a payment string in the format “paymentID,amount,Paying off: invoiceID” and an array of invoices in the format “invoiceID,dueDate,amount”. Write a program to parse the payment string to extract the payment ID, payment amount, and the target invoice ID from the memo line. Then search the invoices array to find the matching invoice and return a formatted string showing which payment pays off how much for which invoice and its due date. Handle edge cases where the invoice ID doesn’t exist in the array, or where multiple invoices have the same amount (in which case return the invoice with the earliest due date). Use efficient data structures like hash maps to store invoices for O(1) lookup time.
Example Input:
Payment: “payment5,1000,Paying off: invoiceC”
Invoices: [“invoiceA,2024-01-01,100”, “invoiceB,2024-02-01,200”, “invoiceC,2023-01-30,1000”]
Example Output:
“payment5 pays off 1000 for invoiceC due on 2023-01-30”
Q3: Shipping Cost Calculator with Multi-Hop Routing
Given an input string representing shipping routes in the format “origin,destination,carrier,cost” separated by colons (for example, “US,UK,UPS,5:US,CA,FedEx,3:CA,UK,DHL,7”), implement a solution to calculate the cost to ship an item from location X to location Y. Parse the input string to build a graph or map data structure where each route is stored with its associated cost. For Part 1, find the direct shipping cost from one location to another (for example, US to UK costs 5). For Part 2, extend the solution to handle multi-hop routes where shipping requires an intermediate step (for example, shipping from US to UK via CA would cost 3 + 7 = 10). Implement efficient graph traversal algorithms such as BFS or Dijkstra’s algorithm to find the shortest or cheapest path. Handle edge cases where no route exists between two locations, and consider optimizing for scenarios with large numbers of routes.
Example Input: “US,UK,UPS,5:US,CA,FedEx,3:CA,UK,DHL,7”
Question: Find cost to ship from US to UK
Direct Answer: Cost of 5
Multi-hop Answer: Cost of 10 (US → CA → UK)
Q4: Bracket Expansion with Prefix and Suffix Handling
You are given a string expression that contains comma-separated tokens enclosed within opening ‘{‘ and closing ‘}’ curly braces. The string may have a prefix before the opening brace and a suffix after the closing brace. Your task is to return a list of strings as output where each string is formed by combining the prefix with each comma-separated token and the suffix. For example, given “/2022/{jan,feb,march}/report”, you should return three strings: “/2022/jan/report”, “/2022/feb/report”, and “/2022/march/report”. Handle multiple tokens correctly and consider edge cases such as empty tokens (like “read.txt{,.bak}” which should produce “read.txt” and “read.txt.bak”). Follow-up requirements include validation checks: if there are fewer than two tokens enclosed within braces, or if the expression is malformed (opening brace without closing brace, closing brace before opening brace, or only one brace present), return the original input string unchanged. Implement recursive or iterative solutions to handle nested or multiple brace expressions in a single string.
Example 1 Input: “/2022/{jan,feb,march}/report”
Example 1 Output: [“/2022/jan/report”, “/2022/feb/report”, “/2022/march/report”]
Example 2 Input: “over{crowd,eager,bold,fond}ness”
Example 2 Output: [“overcrowdness”, “overeagerness”, “overboldness”, “overfondness”]
Example 3 Input: “read.txt{,.bak}”
Example 3 Output: [“read.txt”, “read.txt.bak”]
Edge Case Input: “sun{mars}rotation” (only one token)
Edge Case Output: “sun{mars}rotation” (unchanged)
Q5: Accept-Language Header Parsing and Server Language Matching
In HTTP requests, the Accept-Language header describes the list of languages that the requester would like content to be returned in, formatted as a comma-separated list of language tags (for example, “en-US, fr-CA, fr-FR”). Your task is to write a function that processes this header to determine which languages from the server’s supported language set can satisfy the request. The function receives two arguments: an Accept-Language header value as a string and a set of supported languages. Return the list of matching language tags in descending order of preference (the same order as they appeared in the header). Consider edge cases including case sensitivity, duplicate entries, malformed language tags, and empty inputs. Implement proper validation to ensure language tags follow the format “language-COUNTRY” where language is two lowercase letters and COUNTRY is two uppercase letters. Write comprehensive test cases to demonstrate correctness.
Example Input: “en-US, fr-CA, fr-FR”, Supported: [“fr-FR”, “en-US”]
Example Output: [“en-US”, “fr-FR”]
Example Input: “fr-CA, fr-FR”, Supported: [“en-US”, “fr-FR”]
Example Output: [“fr-FR”]
Q6: Weighted Language Preference with Quality Values
Extending the Accept-Language header parsing, HTTP allows quality values (q-values) to specify preference weights for each language tag in the format “language-COUNTRY;q=value” where q-value ranges from 0 to 1. For example, “en-US;q=1.0, fr-CA;q=0.8, fr-FR;q=0.5” indicates English US is most preferred (weight 1.0), followed by French Canadian (weight 0.8), and French France (weight 0.5). Write a function that parses the Accept-Language header with q-values, matches against server-supported languages, and returns results sorted by quality value in descending order. When q-value is not specified, assume q=1.0. Handle edge cases like invalid q-values, q-values outside the 0-1 range, and languages with equal quality values (maintain original order for ties). Implement proper decimal parsing and comparison logic for floating-point quality values.
Example Input: “en-US;q=1.0, es-MX;q=0.9, fr-FR;q=0.8”, Supported: [“en-US”, “fr-FR”, “de-DE”]
Example Output: [“en-US”, “fr-FR”] (sorted by q-value: 1.0, 0.8)
Q7: Partial Invoice Payment with Multiple Payment Methods
Extend the invoice reconciliation system to handle partial payments and multiple payment methods. A customer can make multiple partial payments toward a single invoice using different payment methods (credit card, bank transfer, PayPal, etc.). Given an invoice with amount due and a list of payments, determine which payments apply to the invoice, calculate the remaining balance, and track payment history. Each payment contains paymentID, amount, payment method, timestamp, and optional memo referencing the invoice. Handle scenarios where payments exceed the invoice amount (overpayment), payments are made before the invoice is created, concurrent payments, and refunds. Design a system that maintains payment state transitions (pending, completed, refunded) and ensures accurate balance calculation with proper rounding for currency minor units. Return a detailed payment breakdown showing invoice status, total paid, remaining balance, and individual payment contributions.
Example Input:
Invoice: {invoiceID: “INV-001”, amount: 5000, dueDate: “2026-03-15”}
Payments: [{paymentID: “PAY-1”, amount: 2000, method: “card”}, {paymentID: “PAY-2”, amount: 1500, method: “bank”}, {paymentID: “PAY-3”, amount: 1000, method: “paypal”}]
Example Output:
Invoice Status: Partially Paid, Total Paid: 4500, Remaining: 500, Payments: 3
Q1. Email Subscription System with Scheduled Notifications
Design a system that manages subscription-related emails for users in Stripe’s invoicing platform. The system needs to send three types of emails: subscription confirmation (when a subscription starts), expiration reminder (before subscription expires), and renewal notification (when subscription is renewed). Given a list of user subscriptions with start dates, expiration dates, and subscription types, along with a scheduling configuration that specifies when each email type should be sent (e.g., send reminder 7 days before expiration), your task is to generate a comprehensive email sending schedule. The output should be a list of email events showing when each email should be sent, to which user, and for which subscription. Handle edge cases such as overlapping subscriptions for the same user, expired subscriptions that shouldn’t send reminders, and ensure proper date calculation. Design appropriate classes following object-oriented design principles including User, Subscription, EmailScheduler, and EmailEvent classes with proper encapsulation and separation of concerns. Consider extensibility for adding new email types and scheduling rules.
Q2. Bug Squash Round - Large Codebase Debugging (Mako Templating Library)
This is Stripe’s unique debugging round where candidates are given access to a large, complex codebase of a templating library (similar to Mako) that contains several intentional bugs. Your task is to identify and fix these bugs by navigating the unfamiliar codebase, analyzing failing unit tests, and using debugger tools effectively. The codebase includes multiple modules, extensive unit test coverage, and realistic production-like code structure. Start by running the provided test suite to identify which tests are failing. Then use debugging techniques including breakpoints, step-through execution, variable inspection, and stack trace analysis to trace the root cause of failures. The round tests your ability to understand code you didn’t write, navigate large codebases efficiently, reproduce issues systematically, and implement proper fixes without breaking existing functionality. Focus on demonstrating your debugging methodology: hypothesis formation, systematic elimination of possibilities, and verification of fixes. Consider edge cases and ensure your fix doesn’t introduce new bugs. This round emphasizes practical engineering skills over algorithmic problem-solving.
Q3. Request Deduplication System with JSON Comparison
Design and implement a request deduplication system for Stripe’s payment processing infrastructure that prevents duplicate request processing. The system must track incoming requests, compare them for equality, and consolidate duplicates to process each unique request only once. Your implementation should handle parsing JSON objects from both strings and files, comparing JSON objects for deep equality (considering nested objects and arrays), and maintaining an efficient data structure for request lookup. Design appropriate classes including Request, RequestDeduplicator, and JSONParser with proper abstraction and encapsulation. The system should support operations like addRequest (check if request already exists, if not add it), isDuplicate (check if incoming request is a duplicate), and getUniqueRequests (return all unique requests processed). Consider edge cases such as JSON objects with keys in different orders but semantically identical, handling null values, and dealing with large JSON payloads. Implement appropriate hashing or comparison strategies for efficient O(1) or O(log n) duplicate detection. This problem tests object-oriented design, understanding of data structures (hash maps, sets), JSON processing, and system design for handling duplicate requests reliably in a distributed payment system.
Q1. Stripe API Integration Round - Payment Platform Integration Architecture
Design a comprehensive system architecture for integrating Stripe’s payment processing APIs into a third-party e-commerce platform. Your design should cover the complete payment flow from checkout initiation to payment confirmation, including webhook handling for asynchronous events. Address key architectural components including the API gateway for handling Stripe API requests, the webhook receiver service for processing payment events (payment succeeded, failed, refunded), idempotency layer to prevent duplicate payment processing, retry mechanism with exponential backoff for API failures, and payment state machine for tracking payment lifecycle transitions. Consider distributed system challenges such as handling network failures, ensuring exactly-once payment processing semantics, managing API rate limits (requests per second constraints), implementing circuit breaker patterns for fault tolerance, and designing for horizontal scalability. Your solution should include database schema design for storing payment transactions, event sourcing for audit trails, caching strategy for frequently accessed data, monitoring and alerting infrastructure, and security considerations including PCI DSS compliance, API key management, and data encryption at rest and in transit. Discuss trade-offs between consistency and availability in the context of payment processing, and explain how you would handle edge cases like partial refunds, disputed transactions, and webhook replay attacks.
Q2. Multi-Part Problem Solving with Progressive Complexity and Edge Cases
Stripe’s advanced programming rounds involve multi-part problem scenarios that progressively increase in complexity, testing your ability to build scalable solutions iteratively. Design a system that starts with a basic requirement and evolves through multiple follow-ups, each adding new constraints or features. For example, starting with a simple invoice reconciliation system, Part 1 might ask for basic matching logic, Part 2 introduces multiple payment methods and partial payments, Part 3 adds currency conversion and international payments, and Part 4 requires handling disputed transactions and refund workflows. Your architecture must demonstrate how to design systems that can evolve and scale without requiring complete rewrites. Focus on proper abstraction layers, separation of concerns using design patterns (Strategy, Factory, Observer), API design that allows for extensibility, database schema that supports future requirements without breaking changes, and proper error handling and validation at each stage. Consider how you would handle edge cases such as concurrent payment attempts for the same invoice, race conditions in distributed systems, eventual consistency challenges, handling timezone differences for international transactions, and managing backward compatibility as the system evolves. This problem tests your ability to think ahead, design for change, handle progressive requirements gathering (similar to real product development), and communicate trade-offs clearly when adding complexity.
Q3. Real-Time Stock Price Alert Notification System
Design a scalable real-time notification system where users can subscribe to favorite stocks and set custom price alert rules. Users define rules such as “notify when stock price rises above $100”, “alert when price drops by 5%”, “notify on moving average crossover”, or “alert when opening price exceeds threshold”. The system must handle millions of user-defined rules, process real-time stock price updates from market data feeds, evaluate rules efficiently, and deliver notifications within one minute of rule satisfaction. Design the architecture including components like the Market Data Ingester (consuming real-time price feeds), Rule Engine (efficiently matching prices against millions of rules using indexing strategies), Notification Service (supporting email, SMS, push notifications with rate limiting), User Profile Service (managing subscriptions and preferences), and Database Schema (storing users, stocks, rules, notification history). Address scalability challenges: how to scan 1 million+ rules per stock price update efficiently, handle burst traffic during market volatility, ensure exactly-once notification delivery, implement circuit breakers for external notification providers, and design for horizontal scaling. Discuss trade-offs between consistency and availability, choose appropriate data structures for rule evaluation (hash maps, interval trees, priority queues), and explain caching strategies for frequently traded stocks.
