Stripe Coding & DSA interview questions

The retry loop's grown-up sibling. Retries protect one call; a breaker protects the whole dependency from a retry storm. The grade is in the half-open state, where letting through one probe instead of all of them is the difference between recovery and re-killing the server.

A 10% rollout where the same user flips on and off between requests is worse than no rollout. The whole problem is determinism: hash the user into a stable bucket so ramping 10% to 25% only ever adds users, never reshuffles them.

Sliding-window limiters count requests; an API that bills by tokens needs to reserve a variable cost up front and refund it if the call fails. The trick is lazy refill: never run a timer, compute the current balance from elapsed time on each check.

The naive fix is to nag the model in every prompt. The staff move is to treat your constraints as a versioned policy library injected as system context, so compliance is structural, then verify it with a linter because prompts are advisory, not enforced.

AI code fails differently from human code: it's confidently plausible. The dangerous defects are the ones that pass a quick read and a happy-path test, missing authorization, hallucinated APIs, hardcoded secrets, unsafe deserialization. Here's the checklist and the automated catch for each.

The most common screen opener, and interviewers use it to check whether hashmap thinking is reflexive. Here's the one-pass answer, the narration that earns points, and the duplicate-handling edge case most candidates fumble.

A 5-minute warm-up that quietly tests the most useful idea in practical coding: choosing a canonical key. The sorted-string vs character-count tradeoff is exactly what interviewers want to hear you reason about.

Top-K is the most reused primitive in FDE interviews: it reappears inside log parsers, analytics questions, and retrieval ranking. Three solutions exist; knowing which one to lead with is the real test.

The single most-asked design-a-data-structure question in FDE loops. There's an interview-legal Python shortcut and a from-scratch version, and knowing when to offer which is half the grade.

The interval pattern shows up everywhere in FDE loops: calendars, flight segments, log windows. Master the sort-then-sweep idiom here and three other interview questions fall out for free.

Looks like a sliding-window problem; isn't one. The prefix-sum + hashmap trick that solves it is the same idea behind sessionization and cumulative-metrics questions later in the loop: learn it once, reuse it three times.

The gentlest 'design a class' question in FDE screens, and the warm-up interviewers use before rate limiters and sessionization. The deque trick is easy; the API and time-window follow-ups are where the signal is.

The quintessential FDE practical: messy real-world input, grouping, ranking, and a hidden rubric line for how you treat malformed data. Most candidates parse happily and lose the round on the lines that don't parse.

Everyone knows the sort + two-pointer outline. The interview is actually about duplicate handling: three separate skip conditions that candidates routinely botch live. Here's the clean version and the narration that goes with it.

The canonical grid question, and the template for every flood-fill, shortest-path, and region-labeling variant FDE loops throw at you. BFS vs DFS vs union-find: here's which to write and which to merely mention.

The follow-up interviewers reach for when merge-intervals goes too smoothly. The three-phase scan is elegant, but only if you've internalized the overlap condition most candidates have to re-derive under pressure.

Anthropic-style screens open with deceptively simple builds like this, then extend them three times. The grade isn't the counting; it's whether your first version survives the extensions without a rewrite.

The reported ElevenLabs live round, written in a shared Google Doc, no execution, no autocomplete. Inherited folder permissions plus permission-change timestamps, and the two-axis resolution rule that keeps the code to thirty lines.

A verbatim-reported multi-part at OpenAI and Anthropic. Each level breaks the previous design on purpose: the burst-at-the-boundary flaw is planted, and naming it before the interviewer does is how you win the round.

The assign-then-update loop is ten lines; the signal is whether you handle the three things that bite in production: initialization, an empty cluster, and a real convergence test instead of a fixed iteration count.