Stripe Forward Deployed Engineer interview questions

The staff-level reliability question for agent platforms. Refunds went out, emails sent, tickets closed, and now you have to triage at fleet scale without double-refunding. The recovery model interviewers actually score.

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.

Almost no labels means you cannot train a classifier and you cannot honestly report recall. The senior answer is to score by typicality, threshold by the customer's review budget, and build the labeling flywheel that turns this into a supervised problem within two quarters.

Per-account scoring catches the lone fraudster and misses the ring whose accounts each look clean. The strong answer reframes the problem as a graph, makes entity resolution the step everything else depends on, and treats a flagged ring as a case for an investigator, not an automatic block.

It reproduces once in a thousand runs, never on your laptop, and the customer's data is wrong. This question separates engineers who name the race and reach for the right lock from those who sprinkle mutexes and pray.

The customer's team has to live with this API for years, on a schedule you don't control. The interview is about how you ship changes without a 2 a.m. page on their side.

Every ML person has chased a proxy that diverged from the thing that mattered. The screen is whether you noticed it yourself, why the proxy fooled you, and how you realigned without just swapping one number for another.

Every engineer can name a time they 'invested in quality.' The graded version names what you gave up, who you had to talk out of the quick win, and the specific payoff that arrived later, with a number.

The agent has real money authority and a write path into the system of record, which is the exact shape attackers want. The strong answer is layered enforcement outside the model, with the spend cap and the chain rule in code, not in the prompt.

Fraud is well under 1% of transactions, the labels arrive weeks late as chargebacks, and the fraudsters adapt to your model on purpose. Optimizing accuracy gives you a model that approves everything. The interview is dollars-at-risk thresholding, label delay, and a review queue with a fixed headcount.

Every queue, webhook, and retry loop you'll ever deploy at a customer hides this distinction. Interviewers use it to separate people who've shipped from people who've read about shipping.

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.

The single most common FDE behavioral question, and the 'week one' follow-up is where most candidates collapse. Here's the structure that signals you can be dropped into chaos and produce order.

This is a flight-risk filter, not small talk, FDE teams lose hires back to pure SWE roles constantly. The answer that passes is built on evidence, not enthusiasm. Here's what it sounds like.

A staple at OpenAI and Anthropic in both coding and design rounds. Most candidates can name the algorithms; few can say which one lets 2x your limit through, and that's the part that gets scored.

Averages lie, and interviewers know most candidates quote them anyway. The fastest way to sound production-grade in any latency discussion is to reason about percentiles correctly, including the one trap almost everyone falls into.

The signature FDE debugging genre: a moving fault, an opaque client, and a customer who's sure it's your fault. The winning method splits the problem at the boundary, and knows the four classic culprits hiding on their side.

Every deployment has a skeptic, and 'I showed them data and they came around' is the answer everyone gives. The scored version starts with why they were right to be skeptical.