Stripe Software Engineer Interview Prep Guide

With less than a week and no solved-question signals, focus most on Stripe-flavored coding and engineering fundamentals: CSV/data validation, time-window scheduling, ledgers, and transaction rule evaluators. Your concept step did not mark any topic as shaky or new, so narrow areas like Luhn checks, frontend DOM behavior, and unfamiliar-template debugging stay brief. The Stripe-specific emphasis is payment ledgers, deterministic rule engines, reliable API/idempotency design, and a focused Stripe Connect marketplace architecture addendum. Budget roughly two hours across these sections, prioritizing Technical Screen and Onsite material before the Online Assessment-only topics.

Technical Screen — 52 min

Coding & Algorithms

• CSV Parsing, Validation, And Joins (Focus) — covered in depth under Online Assessment below.

• Time Windows, Scheduling, And Notifications (Focus) — covered in depth under Online Assessment below.

• Graph Algorithms For Routing And Conversion — covered in depth under Onsite below.

Software Engineering Fundamentals

• Payment Ledgers, Reconciliation, And State Machines (Focus) — covered in depth under Onsite below.

• Python Requests HTTP 307 Stream Replay — covered in depth under Onsite below.

System Design

• Reliable API Integration And Distributed Design (Focus) — covered in depth under Onsite below.

• Stripe Connect Marketplace Architecture (Focus) — covered in depth under Onsite below.

Behavioral & Leadership

Eight years of experience means ownership stories matter; prepare concise evidence for tradeoffs, leadership, and why Stripe.

What's being tested

These conversations test whether you can explain your engineering judgment, motivation, adaptability, and values with concrete evidence rather than polished generalities. The interviewer is probing how you make tradeoffs among correctness, reliability, delivery speed, maintainability, and customer impact when requirements are incomplete or stakeholders disagree. Stripe cares because Software Engineers operate systems where a seemingly small decision can affect payment correctness, developer trust, availability, security, and financial outcomes at scale.

Core knowledge

• STAR-L (Situation, Task, Action, Result, Learning) is useful for behavioral answers, but the “Action” must dominate: explain your technical choices, alternatives rejected, collaborators involved, and measurable result rather than narrating the team’s activity.

• A strong engineering tradeoff names the competing axes explicitly: latency versus consistency, delivery speed versus technical debt, operational simplicity versus flexibility, or local optimization versus platform-wide reuse. State which constraint mattered most and why.

• For financial or state-changing workflows, recall idempotency: retries must not duplicate an operation. An idempotency key stored with the request result lets clients safely retry after timeouts; discuss key scope, expiration, concurrent requests, and payload mismatches.

• SLOs turn reliability into an explicit constraint: for availability target $99.99\%$, the monthly error budget is approximately $43.2$ minutes. A responsible shortcut spends budget deliberately and includes rollback, monitoring, and a plan to repay resulting debt.

• Observability should connect symptoms to causes through structured logs, metrics, and traces. Mention request rate, error rate, latency distributions such as `p50`/`p99`, saturation, correlation IDs, and dashboards or alerts that distinguish regressions from normal variance.

• When adapting to an unfamiliar codebase, use a bounded-learning loop: read the architecture and ownership docs, reproduce the failure, trace one request end-to-end, run targeted tests, and ask focused questions. Avoid broad rewrites before understanding invariants and operational constraints.

• Technical debt is not simply “old code”; it is a deferred cost that increases change risk or slows delivery. Make it concrete through additional review time, incident frequency, coupling, or latency, then propose a proportional repayment plan such as a follow-up issue or staged refactor.

• For an MVP, distinguish reversible from irreversible decisions. Feature flags, adapters, and versioned APIs preserve optionality; data migrations, public contracts, and persisted schemas require stronger review, compatibility planning, and rollback or backfill procedures.

• Disagreement handling should separate facts, assumptions, and preferences. Use a small experiment, failure-mode analysis, prototype, benchmark, or design review to resolve uncertainty; if the decision remains subjective, document the owner, rationale, and revisit condition in an ADR.

• Discussing AI-assisted development responsibly means naming the task, verification method, and boundary. Generated code still requires tests, static analysis, dependency and license review, security checks, human ownership, and caution around secrets or sensitive payment data.

• For value or ethics conflicts, distinguish personal discomfort from an actionable engineering risk such as abuse enablement, privacy exposure, security weakness, or legal/compliance concern. Raise it through the appropriate manager, security, legal, or ethics channel while remaining factual and professional.

Worked example

For “Improving a Product After Shipping Its MVP: Deciding What to Iterate On,” I would first clarify my ownership, the MVP’s success criteria, the observed production signals, and whether the prompt expects an individual or team decision. I would state that I am answering from a Software Engineer’s perspective: prioritize user-visible reliability and correctness, then use evidence to sequence maintainability and capability improvements. I would organize the answer around four pillars: validate the highest-impact failure modes, rank work by customer impact and engineering risk, preserve compatibility while reducing debt, and ship incrementally with observability and rollback.

I would describe a concrete example such as an API that works for the primary flow but has poor retry behavior, unclear errors, and an unbounded query path. I would explicitly trade a broader feature expansion for idempotency, validation, pagination, and `p99` monitoring because correctness and operational safety are prerequisites for scale. I would explain how I aligned with product and support partners without turning the answer into a product roadmap: I brought failure rates, support examples, and implementation estimates to a review. I would close with the result—such as fewer duplicate operations, lower tail latency, or faster debugging—and the lesson about making MVP shortcuts visible. If I had more time, I would also explain how I would test migration safety, review API versioning, and define the conditions for revisiting the prioritization.

A second angle

For “Describe adapting quickly to unfamiliar problems,” the same judgment appears under time pressure rather than post-launch prioritization. I would frame the answer around how I reduced uncertainty, identified the system’s invariants, and chose the smallest safe intervention instead of pretending to understand everything immediately. The key tradeoff might be a targeted mitigation that protects an SLO now versus a deeper redesign that requires more evidence. I would show how I communicated unknowns, used logs and traces to test hypotheses, and kept stakeholders updated as the diagnosis changed. I would end with the durable improvement—runbook, test, alert, or documentation—that made the next incident easier.

Common pitfalls

Pitfall: Saying “I prioritized what customers wanted” without explaining how you identified impact. A stronger answer names engineering signals such as error rate, duplicate writes, `p99` latency, incident severity, support frequency, or the number of affected integrations, then explains the limits of those signals.

Pitfall: Turning “why Stripe” into generic praise about innovation or fintech. Connect your motivation to building reliable developer-facing infrastructure, handling correctness and scale in financial workflows, and the specific kind of engineering responsibility you want—without claiming knowledge of internal projects you cannot verify.

Pitfall: Giving a technically deep story with no personal ownership or learning. “We migrated the service” is weaker than explaining your decision, what you got wrong, how you handled disagreement, and what changed in your engineering practice afterward.

Connections

An interviewer may pivot from these answers to incident response, API and schema evolution, reliability engineering, security and privacy, or code review and technical leadership. Be ready to connect a behavioral story to concrete mechanisms such as feature flags, canary releases, idempotency keys, ADRs, and error budgets.

Further reading

• Designing Data-Intensive Applications — Martin Kleppmann’s treatment of consistency, reliability, schemas, and distributed-systems tradeoffs.

• Accelerate — research-backed discussion of delivery speed, stability, measurement, and high-performing engineering teams.

Practice questions

Onsite — 44 min

Coding & Algorithms

• CSV Parsing, Validation, And Joins (Focus) — covered in depth under Online Assessment below.

• Time Windows, Scheduling, And Notifications (Focus) — covered in depth under Online Assessment below.

Important for routing and conversion questions, but not singled out as weak; keep BFS, Dijkstra, and ratios fresh.

What's being tested

These problems test graph modeling: represent currencies, data centers, or map locations as vertices and relationships as directed or undirected weighted edges. You must choose the right traversal or shortest-path strategy, maintain clean adjacency structures, and reason about unreachable nodes, cycles, dynamic updates, and tie-breaking. Strong solutions also explain complexity and separate domain logic—such as Haversine distance or exchange-rate multiplication—from traversal.

Patterns & templates

• Weighted directed graph for conversions: store adj[src] = [(dst, rate)]; compose rates along DFS/BFS paths while tracking visited nodes.

• Use BFS for any reachable conversion when edge count is unweighted; return immediately on target discovery, with O(V + E) time and O(V) space.

• For multiplicative paths, carry amount *= rate; avoid revisiting nodes, and define behavior for missing currencies, self-conversions, and inconsistent cycles.

• Topological sort applies only to a DAG: compute indegrees with Kahn’s algorithm or use postorder DFS; detect cycles when fewer than V nodes are emitted.

• For nearest healthy data centers, filter unhealthy nodes first, compute Haversine distance, then select the minimum with deterministic tie-breaking; scan in O(D) per query.

• For bicycle routing, use Dijkstra’s algorithm for nonnegative costs; use a priority queue and relax edges, yielding O((V + E) log V).

• For multi-criteria routes, define one scalar cost or use Pareto frontiers; do not silently optimize distance while claiming to optimize time and safety.

Common pitfalls

Pitfall: Treating exchange rates as additive weights; conversion along a path multiplies rates, while shortest-path algorithms generally compare additive costs.

Pitfall: Using topological sort on a graph that may contain cycles, or assuming DFS visitation alone proves a valid ordering without tracking the active recursion state.

Pitfall: Mixing latitude/longitude degrees with Euclidean distance; convert degrees to radians and handle antimeridian, duplicate, empty, and unreachable cases explicitly.

Practice these

The practice cards below cover the canonical variants—solve all of them and time yourself.

Practice questions

Software Engineering Fundamentals

Focus area — Core Stripe domain; prioritize money state transitions, reconciliation, retries, and deterministic balances.

What's being tested

These problems test whether you can model money movement as explicit state transitions rather than as ad hoc mutations to a balance. You need to preserve monetary precision, deterministic ordering, idempotency, and invariants while handling rejection, retries, cancellation, capture, overdraft, and settlement. Stripe cares because a small correctness bug in a ledger can create duplicated funds, missing funds, or unreconcilable records; interviewers are probing both implementation discipline and your ability to explain tradeoffs clearly.

Core knowledge

• Integer fixed-point money stores the smallest currency unit, such as cents, rather than floating-point values. For a percentage fee, calculate with integer arithmetic and document rounding: fee = floor(amount * rate / denominator) or the explicitly specified half-up rule.

• A ledger should be append-oriented: record immutable entries such as debit, credit, fee, reversal, and settlement, then derive balances. A mutable balance cache improves reads, but it must be reproducible from entries and updated atomically with the authoritative write.

• Use a state machine with enumerated states and an explicit transition table. For example, accepted -> captured -> settled, while accepted -> canceled may be valid; reject illegal transitions such as settled -> canceled unless a separate reversal operation exists.

• Keep acceptance, authorization or limit usage, and settlement distinct. A payment can be accepted by business validation, consume an account limit, and remain unsettled; collapsing these into one boolean makes refunds, retries, and reconciliation ambiguous.

• Idempotency means repeating the same logical command has the same effect as applying it once. Key commands by a stable operation or idempotency key, persist the result, and reject reuse with different payloads rather than silently applying a second mutation.

• Define ordering precisely: sort by timestamp only when timestamps are guaranteed unique; otherwise use (timestamp, sequence_number) or another stable tie-breaker. Never rely on input order unless the contract explicitly guarantees it.

• Maintain invariants such as $\sum \text{debits} - \sum \text{credits} = \text{net balance change}$ and, for a double-entry ledger, total debits equaling total credits. Assert these during tests and expose violations rather than repairing balances silently.

• Reconciliation compares two independently produced views, such as internal ledger entries and processor settlement records. Match on stable identifiers, amount, currency, and lifecycle status; classify unmatched, duplicated, amount-mismatched, and timing-difference cases for deterministic remediation.

• Process each account-currency pair independently. A balance for USD must not offset a balance for EUR, and an account identifier alone is insufficient as a key; use a composite key such as (account_id, currency).

• For overdrafts, make the coverage rule explicit: consume the account’s available balance first, then debit a platform or reserve account for the deficit, or reject atomically. Preserve the invariant that the resulting account balance and platform coverage reflect the same accepted transaction.

• Transactional atomicity matters whenever a command changes multiple records. In Postgres, a database transaction with row-level locking can protect a balance update; optimistic concurrency with a version column can work when conflicts are expected to be low.

• Parsing is part of correctness: preserve empty fixed-position fields, validate field count and types before indexing, and separate syntax errors from semantic rejection. A parser should produce a typed command; the state machine should decide whether that command is legal.

Worked example — Design a Ledger with Separate Acceptance, Limit, and Settlement States

For “Design a Ledger with Separate Acceptance, Limit, and Settlement States,” I would first clarify the command grammar, whether deposits can be retried, whether timestamps determine ordering, and whether query output must reflect accepted commands only or settled funds. I would state that amounts are integer minor units, account balances are keyed by (account_id, currency), and commands are processed deterministically in the specified order. I would organize the solution around four pillars: parsing and validation, account initialization, explicit acceptance/limit/settlement state, and balance-query generation. I would represent each command’s lifecycle separately rather than using one status, because acceptance can succeed while settlement is delayed or limit usage remains active. I would also define the invariant that rejected commands have no financial side effects and that repeated command identifiers cannot create additional balance. A key tradeoff is whether to store only current balances or append immutable ledger entries plus a balance projection; the latter is easier to audit and replay, while the former is simpler and faster for a small coding exercise. I would explain atomic updates if acceptance changes both an account and a platform limit, using a transaction or a version check. If I had more time, I would add property-based tests for illegal transitions, duplicate commands, zero or negative amounts, currency isolation, and replaying the same input to obtain identical results.

A second angle

For “Design a Fixed-Position Payment Command State Machine,” the same principles apply, but the primary risk shifts from aggregation to parsing and transition legality. I would first preserve empty fields and validate exact field positions, then convert the parsed record into a typed command before applying business rules. The state table should distinguish approval, capture, cancellation, and retry, including whether a retry is idempotent or represents a new attempt. The important transfer is that every mutation needs a clear precondition, postcondition, and duplicate-command behavior, even when no balance is changed yet.

Common pitfalls

Analytical mistake: Treating a payment status as a single linear enum such as pending -> paid -> failed is tempting, but it cannot represent independent authorization, limit, and settlement dimensions. Use separate state or ledger concepts and document which transitions affect funds, limits, and reporting.

Pitfall: Using floating-point arithmetic or silently rounding fees can produce reconciliation differences of one or more minor units.

Communication mistake: Jumping directly into maps and loops without clarifying ordering, retries, currencies, or rejection semantics makes a correct implementation look accidental. State assumptions explicitly, write the invariants on a whiteboard, and call out what the prompt does not specify.

Depth mistake: Saying “wrap it in a database transaction” is not enough. Explain which records are locked or versioned, how duplicate commands are detected, what happens after a timeout, and how immutable entries or audit data let operators reconstruct the result.

Connections

An interviewer may pivot to double-entry bookkeeping, idempotency keys, optimistic concurrency control, or event sourcing and projections. They may also ask how to test invariants with property-based testing or how to diagnose a reconciliation break without mutating historical records.

Practice questions

Useful for Stripe-style debugging; review redirect semantics, stream replay, file pointers, and minimal regression tests.

What's being tested

These debugging questions test tracing HTTP 307 redirect semantics through Python requests, especially preserving the method and replaying a streamed request body. You must reason from bytes on the wire—stream position, Content-Length, socket reads, and timeout behavior—then propose a minimal, robust fix for seekable versus non-replayable bodies.

Patterns & templates

• 307 preserves method and body: the redirected request remains POST; unlike 303, it must resend the original payload to the new URL.

• Seekable stream replay: record the initial position with body.tell(), then call body.seek(position) before retrying or redirect replay.

• requests may rewind using its internal body-position metadata; verify PreparedRequest._body_position and inspect requests/urllib3 behavior rather than assuming automatic replay.

• Content-Length framing must match bytes actually available; a reused stream at EOF can advertise N bytes while sending zero, causing the server to wait.

• Prefer a bytes/string body for small payloads: it is naturally replayable; use a reopened file or seekable object for large uploads.

• Treat generators and pipes as non-replayable unless buffered; retrying them can duplicate, truncate, or silently alter the payload.

• Debug with a short timeout, request/response logging, tell() before and after sends, and a local redirect server; distinguish client hang from server processing.

Common pitfalls

Pitfall: Saying “307 changes the request to GET” confuses it with 303; 307 preserves both method and body.

Pitfall: Rewinding only after the timeout is insufficient if the first request already consumed the stream; restore the position before the redirected send.

Pitfall: Recommending blind retries ignores non-seekable bodies and duplicate side effects; use idempotency keys or explicit buffering where appropriate.

Practice these

The practice cards below cover the canonical variants — solve all of them and time yourself.

Practice questions

System Design

Focus area — System design self-rating is 3/5 and Stripe strongly rewards idempotency, retries, validation, and failure-boundary reasoning.

What's being tested

These problems test whether you can turn an unreliable, partially specified API workflow into a correct distributed system with explicit contracts, state transitions, and recovery behavior. The interviewer is probing idempotency, consistency, concurrency control, failure isolation, and the ability to distinguish your service’s guarantees from those of an external dependency. Stripe cares because payments, ledgers, feature controls, counters, and third-party integrations must remain correct when requests are retried, duplicated, delayed, reordered, or only partially completed.

Core knowledge

• Contract-first API design starts by defining request and response schemas, validation rules, coordinate or currency units, authentication, timeouts, pagination, and error semantics before choosing storage or infrastructure. State assumptions explicitly when the prompt leaves behavior unspecified.

• Idempotency keys let a client safely retry a mutation: persist (account_id, idempotency_key, request_hash, status, response) and return the original result for an identical request. Reject reuse with a different payload rather than silently applying a second operation.

• Retry policy must distinguish transient failures (429, connection resets, many 5xx) from permanent failures (400, authorization errors, malformed input). Use exponential backoff with jitter, bounded attempts, and a deadline; retries without an idempotency key can duplicate side effects.

• Timeouts and circuit breakers prevent a slow dependency from consuming every worker. Set connect, read, and overall deadlines; trip a circuit after measured failures, serve a safe fallback where possible, and use half-open probes to recover gradually.

• Exactly-once effects are usually implemented as at-least-once delivery plus deduplication, not promised by the network. A unique database constraint, request log, or inbox table converts duplicate deliveries into one durable state transition.

• Linearizability means each operation appears to occur atomically at one point between invocation and response. For a single-winner dispatch acceptance, use a conditional update such as UPDATE ... WHERE status = 'open', then verify affected-row count.

• Consistency choices should follow the invariant. A financial ledger and winner selection need strong consistency; a feature-flag read path may tolerate bounded staleness if rollout safety is preserved. State whether the system offers read-after-write, eventual, or monotonic-read guarantees.

• Transactional boundaries matter when combining local writes with external APIs. A local database transaction cannot atomically commit with a routing provider; use an outbox, durable workflow state, reconciliation, and compensating actions rather than claiming distributed atomicity.

• Outbox/inbox patterns persist an event alongside the business mutation, then publish asynchronously and deduplicate consumption. Include a stable event ID, versioned schema, retry state, dead-letter handling, and replay-safe handlers.

• Hot-key mitigation is essential for counters and popular feature flags. Shard a frequently updated key across $k$ buckets, write to one bucket per event, and read by summing buckets; this trades write contention for read amplification and requires a defined time-window strategy.

• Geospatial matching commonly uses an index such as geohash, S2, or H3 to query nearby cells before calculating exact distance with the Haversine formula. Expand neighboring cells near boundaries and define freshness, radius, and tie-breaking rules.

• Observability and security should expose request IDs, idempotency keys, dependency latency, retry counts, circuit state, and invariant violations without logging secrets or payment data. Track p50, p95, and p99 separately; averages hide tail failures that trigger cascading retries.

Worked example: Design ledger and bikemap integration

In the first 30 seconds, I would clarify the ledger’s currency and precision, whether debits must be strictly ordered, the routing provider’s latency and quota limits, acceptable stale route data, and whether a successful response means “ledger committed” or “route obtained.” I would declare that ledger mutations require strong consistency, while route lookup is an external, fallible read that must not corrupt balances. I would organize the answer around the ledger data model and invariants, the idempotent mutation API, the routing-adapter boundary, and asynchronous recovery and reconciliation. For the ledger, I would use integer minor units, immutable double-entry records, balance checks, and a unique idempotency key enforced transactionally in Postgres. For the bikemap call, I would apply a short timeout, bounded jittered retries for transient errors, caching keyed by normalized coordinates, and a circuit breaker. The central tradeoff is whether to block the user-visible operation until routing succeeds or commit the financial operation first and calculate the route asynchronously; I would choose based on whether the route is essential to the business invariant. I would explicitly explain that a local transaction cannot provide atomic commit with the provider, so an outbox and reconciliation job are safer than a two-phase commit assumption. I would close by saying that, with more time, I would specify provider failover, quota handling, audit retention, and property-based tests for duplicate and reordered requests.

A second angle

Design a Feature Flag Service with Percentage Rollouts and Allow/Block Lists uses the same reliability principles but shifts the primary constraint from transactional money movement to low-latency, highly available reads. Evaluation should be deterministic: hash a stable subject and flag key, map the result to a bucket, then apply precedence such as block list, allow list, explicit targeting, percentage rollout, and default. A stale cached configuration may be safer than failing closed or open, but the choice must be explicit for each flag’s risk level. Configuration writes need versioning, audit history, propagation monitoring, and idempotent update requests.

Common pitfalls

Pitfall: Saying “use retries for reliability” without specifying idempotency, retryable status codes, deadlines, backoff, or duplicate suppression leaves the most dangerous failure mode unanswered. Tie every retry policy to a particular side effect and invariant.

Pitfall: Jumping directly to Kafka, sharding, or microservices before clarifying correctness and scale makes the design feel like infrastructure shopping. Start with API semantics, state transitions, throughput, latency, and failure guarantees; then choose components that support them.

Pitfall: Claiming a distributed transaction makes a ledger update and third-party API call atomic is incorrect. Explain the unavoidable partial-failure window and provide an outbox, workflow state machine, reconciliation, and compensating behavior.

Connections

An interviewer may pivot to sagas, outbox/inbox delivery, leader election, multi-region consistency, or property-based testing of invariants. They may also ask how to design rate limits, webhook verification, dead-letter recovery, or safe schema evolution without breaking old clients.

Further reading

• Stripe: Idempotent requests — concrete treatment of safely retrying API mutations.

• Designing Data-Intensive Applications by Martin Kleppmann — strong coverage of replication, consistency, transactions, and distributed failure modes.

• Pat Helland, “Life Beyond Distributed Transactions” — explains practical alternatives to global atomic transactions.

Practice questions

Focus area — Stripe-specific addendum for platform scenarios: connected accounts, onboarding, transfers, payouts, refunds, permissions, and operational failure modes.

What's being tested

This topic tests whether you can decompose a multi-party payments system into clear services, state transitions, and failure-handling paths. The interviewer is probing your understanding of money movement, connected-account isolation, idempotency, asynchronous webhooks, and reconciliation—not merely whether you can draw boxes labeled “payments” and “payouts.” Stripe cares because marketplace integrations must remain correct under retries, duplicate events, partial failures, disputes, and regulatory constraints while serving many independent platforms and sellers.

Core knowledge

• Connect account models determine who is merchant of record, who bears disputes, and where funds settle. Compare direct charges, destination charges, and separate charges-and-transfers; state the operational and liability tradeoffs rather than treating them as interchangeable.

• Payment intent state machines should be explicit: requires_payment_method, requires_action, processing, succeeded, and canceled. Never infer success from a client response alone; persist the server-side state and accept asynchronous completion through signed Stripe webhooks.

• Idempotency is required at every externally retried money-moving operation. Generate a stable key from the business operation, such as order_id + operation_type, and store the resulting Stripe object or terminal error so a timeout cannot create duplicate charges or transfers.

• Double-entry ledgering separates financial truth from mutable marketplace records. Represent each posting as balanced debits and credits, use integer minor units, record currency explicitly, and make entries append-only; corrections should be compensating entries rather than updates.

• Funds-flow choices affect atomicity. A destination charge can associate the customer payment, platform fee, and connected-account transfer in one Stripe operation; separate charges and transfers provide flexibility for split orders but require careful handling of transfer timing and partial success.

• Webhook processing should be durable and replay-safe: verify the signature, persist the event ID, enqueue work, acknowledge quickly, and process asynchronously. Duplicate delivery is normal; ordering is not guaranteed, so handlers must be idempotent and derive state from the event plus authoritative API reads when necessary.

• Distributed consistency requires a state machine around orders, payment intents, transfers, and payouts. Use transactional local updates plus an outbox or durable event record; do not attempt a distributed transaction spanning your database and Stripe.

• Reconciliation compares your internal ledger and order state with Stripe objects and balance transactions. Schedule incremental checks using creation timestamps and cursors, then run periodic full-window reconciliation; distinguish missing data, duplicate data, amount mismatch, and legitimately delayed settlement.

• Failure handling must classify errors: validation failures are usually permanent, network timeouts are ambiguous and require idempotent retry, rate limits need bounded backoff, and authentication or capability errors require operational remediation. Never blindly retry every 4xx response.

• Security and tenant isolation require authorization on every platform and connected-account resource. Store platform/account identifiers server-side, avoid trusting client-supplied amounts or seller IDs, encrypt sensitive configuration, verify webhook signatures, and ensure logs do not expose payment credentials or unnecessary personal data.

• Payouts and refunds are separate lifecycle concerns from the initial payment. A refund may require reversing transfers or debiting a connected account depending on the flow; model these as explicit operations with their own idempotency keys, permissions, ledger entries, and asynchronous terminal states.

• Scalability boundaries should be explicit. Partition work by platform or account where practical, use queue backpressure and per-account rate limiting, and query by indexed IDs and time windows. Preserve ordering only where a specific account’s state machine requires it; global ordering is expensive and unnecessary.

Worked example

Representative prompt: Design a Stripe Connect marketplace architecture. In the first 30 seconds, clarify whether the platform is merchant of record, whether one checkout can contain multiple sellers, whether sellers receive immediate transfers or later payouts, and what correctness guarantees are required for refunds and disputes. I would organize the answer around four pillars: the checkout and Connect charge model, an internal order and double-entry ledger, asynchronous webhook-driven state transitions, and reconciliation plus operational recovery. I would store an order-level idempotency key, create the appropriate PaymentIntent server-side, persist the Stripe identifiers, and treat webhooks—not browser responses—as authoritative for completion. For a multi-seller order, I would explicitly compare separate charges and transfers with a destination-charge design, explaining how each affects atomicity, fee allocation, and partial fulfillment. I would add an outbox-backed worker so database commits and event publication are reliable without pretending the database and Stripe share a transaction. The key tradeoff is simplicity versus flexibility: destination charges reduce coordination, while separate transfers support more complex seller allocation but create more failure and reconciliation cases. I would close by saying that, with more time, I would specify refund/dispute behavior, account capability failures, webhook replay tooling, rate limits, and a reconciliation runbook.

A second angle

Design reliable marketplace payouts and reconciliation uses the same architecture but emphasizes delayed settlement rather than checkout latency. The central questions become how to represent available versus pending funds, how to handle payout failures, and how to detect divergence between internal postings and Stripe balance transactions. A strong answer would use append-only ledger entries, cursor-based reconciliation, idempotent payout commands, and explicit compensation for reversals. It should also distinguish a temporarily delayed payout from an actual accounting mismatch instead of treating every discrepancy as a retryable API error.

Common pitfalls

Pitfall: Saying “charge the card, then update the seller balance” without defining who owns the funds, how the platform fee is represented, or what happens when the second operation fails. Separate payment state, transfer state, and ledger state, then explain their allowed transitions.

Pitfall: Claiming that a successful API response or frontend callback proves payment completion. Payments can require customer action or complete asynchronously; use persisted server state and verified webhook events, with idempotent handlers and replay support.

Pitfall: Drawing a generic microservices diagram while skipping money correctness. Interviewers usually care more about duplicate charges, refunds, disputes, retries, and reconciliation than about whether you selected Kafka versus another queue.

Connections

The interviewer may pivot to distributed transactions, the outbox pattern, double-entry accounting, webhook security, or designing an idempotent API. Be prepared to discuss state-machine invariants, eventual consistency, and recovery workflows without claiming exactly-once execution across external systems.

Further reading

• Stripe Connect documentation — authoritative overview of connected accounts, charge types, transfers, and platform responsibilities.

• Stripe Idempotent requests — concrete guidance for safely retrying API operations.

• Martin Kleppmann, Designing Data-Intensive Applications — strong treatment of consistency, event delivery, transactions, and distributed-system failure modes.

Practice questions

Online Assessment — 17 min

Coding & Algorithms

Focus area — Appears across all rounds, coding self-rating is 3/5, and there are no solved-question signals yet.

What's being tested

These problems test CSV parsing, record validation, and join/aggregation algorithms over semi-structured text data. You must preserve input order where required, define duplicate-key and malformed-row behavior, and choose between straightforward scanning, sorting, or hash-based indexing. Strong solutions separate normalization, validation, and output formatting so edge cases are explicit and testable.

Patterns & templates

• Use Python's csv.reader or csv.DictReader; handle quoted commas, escaped quotes, headers, blank lines, and malformed records deliberately.

• Normalize comparison fields with strip(), casefold(), whitespace tokenization, and stop-word removal before forbidden-word or overlap checks.

• Build a hash index key -> list[record] for joins; preserve every left row and emit all matching right rows, giving O(n + m + output) time.

• For sorted joins, sort both inputs by key and advance two pointers; complexity is O(n log n + m log m) with lower auxiliary indexing overhead.

• Validate each row independently, collecting deterministic error codes; distinguish missing, empty, overlong, forbidden, and structurally malformed fields.

• Aggregate changed files through file -> owners and owner -> changed files maps; deduplicate reviewers while retaining a specified stable ordering.

Common pitfalls

Pitfall: Treating CSV as line.split(",") breaks quoted commas and embedded quotes; use a standards-aware parser.

Pitfall: Implementing a dictionary join as one-to-one silently drops duplicate matches; store lists and define the Cartesian expansion explicitly.

Pitfall: Calling lower() without trimming, tokenizing, or removing ignored words produces inconsistent overlap and forbidden-word results.

Practice these

The practice cards below cover the canonical variants — solve all of them and time yourself.

Practice questions

Focus area — Repeated across rounds and easy to miss under time pressure; emphasize interval arithmetic and deterministic date handling.

What's being tested

These problems test interval algorithms, event-driven simulation, and stateful time processing over ordered data. You must normalize time zones and boundary semantics, merge or subtract windows efficiently, process same-timestamp events deterministically, and preserve correctness across recurring schedules and account state changes.

Patterns & templates

• Sweep line for interval union/difference: sort endpoints, track active counts, and emit transitions in O(n log n) time.

• Convert recurring weekly times to integer minutes in [0, 10080), apply offsets modulo a week, and explicitly handle wraparound intervals.

• For allowed-minus-freeze windows, merge overlaps first, subtract freezes with two pointers, then filter by lead time, minimum duration, and result cap.

• Use a priority queue or k-way merge for notification streams; define deterministic ordering by timestamp, event type, and stable identifier.

• Model account changes as ordered events with explicit state transitions; renewal, cancellation, and plan-change precedence must be documented.

• Use a rolling window with a deque or per-key queues; evict timestamps < current - window, maintaining O(n) total work.

• Separate computation from rendering: calculate eligible notifications first, sort/filter efficiently, then apply templates; avoid repeated scans over large account lists.

Common pitfalls

Pitfall: Treating interval endpoints inconsistently; choose half-open [start, end) semantics so adjacent windows do not create false overlap.

Pitfall: Applying time-zone offsets after filtering; convert candidate intervals to UTC before lead-time comparisons, while preserving duration.

Pitfall: Assuming input order resolves ties; explicitly specify same-time event precedence and stable tie-breakers.

Practice these

The practice cards below cover the canonical variants — solve all of them and time yourself.

Practice questions

Light review — Narrow Online Assessment topic; no explicit shaky/new flag, so cover parity and edge cases without over-investing.

What's being tested

These problems test implementing the Luhn checksum, identifying card brands with ordered pattern matching, and handling wildcard strings without mixing validation rules. You must also reason about combinatorial completion counts and efficient single-digit correction, with clear complexity and edge-case choices.

Patterns & templates

• Luhn validation — scan digits right-to-left, double alternating digits, subtract 9 when needed; valid when total % 10 == 0.

• Normalize input deliberately: reject or strip separators according to the contract, then reject empty strings, nondigits, and unsupported lengths.

• Separate identifyBrand, isValid, countCompletions, and recover so brand-pattern logic does not contaminate checksum code.

• Use ordered brand predicates for overlapping prefixes; return UNKNOWN when no brand matches rather than guessing from Luhn validity.

• For wildcards, enumerate only when bounded; otherwise use dynamic programming over positions and checksum residue in O(n * 10 * 10) time.

• For one-error recovery, try each candidate digit or allowed edit, validate the result, and deduplicate; straightforward search is O(n * 10).

• Preserve the original string’s positions and parity: inserting or deleting digits changes which positions Luhn doubles, a common off-by-one bug.

Common pitfalls

Pitfall: Doubling from the left instead of the right, or treating the check digit as doubled, produces consistently incorrect validations.

Pitfall: Assuming every syntactically plausible number belongs to a known network; enforce exact lengths and prefixes before returning a brand.

Pitfall: Counting wildcard assignments without filtering brand constraints, fixed digits, length, and duplicate recovered candidates.

Practice these

The practice cards below cover the canonical variants — solve all of them and time yourself.

Practice questions