Why this round confuses everyone
Read the reports back to back and the same complaint appears in nearly all of them: nobody knows what is being measured. One candidate let the assistant do most of the work and was asked why they were so confident in code they had not written. Another wrote a skeleton by hand and was asked why they were not using the assistant. A third verified every step and got the feedback that they were too slow and should delegate more. A fourth was told, at the start, that speed did not matter, and then failed on speed.
Our read is that these are not contradictions. They are the same rubric seen from different failure modes. Stripe wants to watch an engineer run a loop: understand the task, split it, hand bounded pieces to the assistant, read what comes back, catch what it got wrong, prove it with tests, move on. Every piece of negative feedback above is a missing step in that loop. Trusting the output skips the review step. Hand writing skips the delegation step. Verifying everything by hand skips the pace step. The task is easy on purpose so that the loop is the only thing left to grade.
There is one more thing the reports agree on, and it is unusual: naming and test cases get nitpicked. One candidate complained that the interviewer docked them for variable names in code the assistant produced. That tells you whose code it is once you accept it.
What the task actually is
Every detailed report describes the same problem. You get a README, a list of transactions, and a list of rules. Each rule names an action, accept or block, followed by an if clause. Part 1 is flag rules matched by plain string equality, no fuzzy matching:
BLOCK if fraud_flag
ACCEPT if trusted_partnerPart 2 extends the if clause to comparisons and boolean composition:
ACCEPT if trusted_partner AND amount > 10000A staff candidate in August spelled out the semantics: rules from both parts live in one processor and run in the order they were added, and once a rule accepts or blocks, the rest are not evaluated. They also noted the trap: they expected part 2 to be more if clauses and started down the wrong road before realising the grammar itself had changed.
Several candidates mention a third part, and a few say the AND and OR logic only arrives then. One September report describes string rules such as a card name or merchant name that must not equal a given value, applied to transaction strings. That is the extent of what is known about part 3. Nobody reports parentheses, NOT, or nested conditions.
One candidate put the difficulty bluntly: easier than the phone screen and OA problems. With the assistant, every part is reachable in the time. What runs out is not ideas but the minutes you spend reading generated code and explaining it.
The workflow that got a solid good
One June candidate asked the recruiter for feedback and shared it. Their AI round was rated solid good. What they did: had the assistant read the README and propose a plan, reviewed the plan themselves, had it implement, had it write tests, ran the tests. They added two warnings from the session: the assistant will over-engineer, and it may drop a condition without saying so. Catching that is where the signal is. A July intern who got the offer describes the same shape, with one addition worth keeping: make sure the interviewer sees that you are using the assistant, not handing it the judgment.
Compare the candidate who was told to use the assistant more aggressively. They had their own solution first, asked the assistant for one, verified step by step, added unit tests, and fixed small things by hand when that was faster. Good engineering, graded as slow. The difference is not care. It is that the first workflow delegates the whole first draft and spends the human minutes on review, while the second spends human minutes on a draft the assistant would have produced in seconds.
Two practical notes from September. Model choice matters: one candidate found some models took over a minute per answer and recommends Gemini Flash for pace. And keep talking while the model works. Several interviewers graded silence as a gap in reasoning.
The rest of the loop
The AI round is one of four or five. The others are better documented and worth a line each, because the failure stories mostly come from them. The integration round is the Bikemap task: read JSON, call a map API, annotate images, in parts. The debug round is a bug squash in an open-source repo (Mako, requests, Moshi or SnakeYAML depending on language) in your own IDE, and the recurring disaster is a local environment that is not set up before the call. System design is payments flavoured, usually a ledger with idempotency and consistency as the drill. The hiring manager round now includes a block on how you use AI day to day. Senior and above may get a reference check before the decision.
What is confirmed, and what is not
- Confirmed: the HackerRank environment with an embedded assistant; the rule parser task with flag rules in part 1 and comparisons with AND and OR in part 2; insertion order and first match wins; about thirty minutes of coding; the assistant over-engineering and dropping conditions; naming and tests being scrutinised; the round appearing in both the onsite and the phone screen. Each is in several independent reports.
- Reported once or twice: part 3 as string rules on card and merchant names; AND and OR arriving only in part 3; Codex as the agent; a 90-minute React and API variant for forward deployed engineers.
- Not known: the rubric, the pass bar, and whether there is a default action when no rule matches. Stripe has published nothing about the round.
How we would prepare
- Rehearse the loop, not the parser. Take any small spec, have an assistant propose a plan, cut the plan into three bounded tasks, delegate each, read every diff before accepting it, and ask for tests. Time it. You want the whole cycle under twenty minutes with narration.
- Practise saying why. For every change you accept or reject, one sentence out loud. Interviewers interrupt to probe exactly this, and candidates who had the right code but no words for it were graded down.
- Expect the dropped condition. When the grammar grows, the assistant tends to keep the old path and lose a branch of the new one. Write the test for the new branch before you ask for the implementation, then run it.
- Read the README first, and say so. Candidates who pasted the task and accepted the first answer were asked why they trusted it. Reading the contract first gives you the answer.
- Pick a fast model and a language you read quickly.Most of your minutes go to reading, not writing.
Nyrion's Stripe section starts with Transaction Rule Parser, built from these reports: a README contract, flag rules, then comparisons with AND and OR in one ordered processor with first match wins. Parts 1 and 2 follow the reports closely. Our parts 3 and 4, string literals and rejecting malformed rules up front, are our extrapolation of the unspecified third part. After each part the interviewer asks the questions Stripe's interviewers ask: why that precedence, why you trust that tokenizer, why fail at construction. Practise answering them out loud.
How this round compares with other companies' versions, and what every version grades: the AI coding interview guide.
Frequently asked, briefly answered
Is the AI round in the phone screen or the onsite?
Both now. It started in late April 2026 as an onsite round replacing one classic coding round. By August, staff and senior candidates reported it as the technical phone screen too, and interns got it as one of two onsite rounds. Recruiters sometimes announce the switch only days before the interview, so assume you will get it.
Which AI model do I get?
The assistant is built into HackerRank and you choose the model at the start. Candidates report Claude (including Opus), Gemini Flash and a Codex agent. Speed differs a lot: one candidate waited over a minute per answer on a slow model and recommends Gemini Flash for pace. Check what is available before the clock starts.
Can I just write the code myself?
You can, and some candidates did when the assistant was slow. The pressure cuts both ways: one candidate was told afterwards to use the assistant more. Another was challenged in the round from both sides: why they were so confident in the AI's code when it wrote more, and why they were not using AI when they wrote a skeleton themselves. The safe position is to let the assistant write routine code while you own the plan, the review and the tests, and say out loud why you accept or reject each change.
How hard is the problem?
Easier than Stripe's own phone screen and OA questions. Every report says so. Part 1 is matching flags, part 2 is comparisons with AND and OR. The difficulty is the format: about thirty minutes of actual coding, a rubric nobody fully understands, and an interviewer who interrupts to probe code you did not type.
What gets graded?
Stripe has published nothing. From feedback candidates received: how you plan before prompting, whether you review what comes back and catch what it dropped, whether you write tests, naming, and pace. One candidate who verified step by step was told to use the assistant more aggressively. One who had it read the README, propose a plan, implement, write tests and run them got a solid good.
Which language?
Candidates report Python and Java. The task is language-agnostic. Pick what you can read fastest, because reading generated code under time pressure is most of the round.
Practice problems tagged for Stripe
Browse the catalog and open the Stripe section. No login required to look; sign in when you want to solve one.