Reflection AI is a lab of roughly sixty people that raised its latest round near a $25 billion valuation and has shipped one public product: Asimov, an agent that reads and explains large codebases instead of writing your features for you. If you get an interview there in 2026, start from that fact. This is not a company staffing a product org with fifty generalists. They want people who can help train frontier models on tens of trillions of tokens and keep a GPU cluster alive while that happens. The loop is built to find those people, and it screens out almost everyone else.
The founders set the bar. Misha Laskin worked on reward modeling and reinforcement learning for Gemini at Google DeepMind; Ioannis Antonoglou is a co-creator of AlphaGo, AlphaZero, and MuZero. Your interviewers are researchers who have shipped reinforcement learning at a scale almost nobody else has touched. They can tell within a few minutes whether you actually understand what your resume claims, so the fastest way to fail is to oversell a project where you only touched the edges.
Three tracks that barely overlap
Reflection hires along three lines, and the interviews differ enough that prepping for the wrong one is a real risk. There is the research track (pretraining, post-training, RL, agents), the research-infrastructure track (distributed training, cluster reliability, the systems that make large runs possible), and product engineering (Asimov itself, the agent harness, the code-comprehension pipeline). A distributed-systems engineer who preps like a competitive programmer will get taken apart in the infra loop. A researcher who can derive a policy-gradient update but has never watched a training run stall on a slow node will struggle when the same panel comes at them from the systems side.
The overall shape is familiar for a frontier lab. A recruiter call, then a technical phone screen with an engineer or researcher, then an onsite of four to six rounds, then a closing conversation with a founder or a team lead. What differs is the weight. There is very little algorithm trivia. Nobody is going to ask you to invert a binary tree on a whiteboard. The rounds are built around work you would actually do on the job, and the onsite leans on a real design or debugging problem pulled from training infrastructure or agent behavior.
| Stage | Format | What earns a pass |
|---|---|---|
| Recruiter screen | 25-30 min call | A specific reason you want an open-model lab, not just “an AI job” |
| Technical phone screen | 60 min with an engineer or researcher | Real depth on one project; correct fundamentals under follow-up pressure |
| Infrastructure / coding round | 60-90 min, live | Working code plus clear reasoning about failure modes at cluster scale |
| Systems or research round | 60 min, whiteboard or paper discussion | You defend your design choices and name what you don’t know |
| Practical design problem | 60-90 min | Sane tradeoffs on a messy, underspecified training or agent problem |
| Founder / mission conversation | 45-60 min | Judgment, ownership, and genuine interest in open frontier models |
What the research-infrastructure round really asks
Infrastructure is where Reflection is hungriest, because a lab burning through tens of trillions of tokens lives or dies on how well its hardware stays busy. The questions are concrete and they assume you have felt this pain firsthand. Expect to talk through how you would keep a multi-thousand-GPU run from stalling when one node’s NCCL all-reduce hangs, how you checkpoint a model too large to fit on a single host, and where the memory actually goes during training (optimizer states and activations, not just the weights).
They want to see you reason about profiling and cost together, because GPU hours are the budget line that dwarfs everything else. Knowing the difference between a compute-bound and a communication-bound run, and being able to say how you would tell which one you are looking at from a trace, matters more than any single framework detail. The questions tend to sound like these:
- “A run is getting 40% of theoretical FLOPs. Walk me through how you find the bottleneck.”
- “One rank in a data-parallel job is consistently slow. How do you detect the straggler, and what do you do about it?”
- “Explain what NCCL is doing during a gradient all-reduce, and where it tends to break at scale.”
- “Design checkpointing for a run that costs six figures a day. What recovery-time target do you pick, and why?”
Strong answers stay grounded. You say what you would measure first, you admit when a number would decide the design for you, and you talk about the operational reality of a cluster where nodes fail on their own schedule. The infra track also expects fluency with the orchestration layer, Kubernetes or Slurm, and with the plumbing around large runs: sharded checkpoints, elastic recovery, and keeping data loaders from becoming the thing that starves the GPUs.
The research loop is not a paper quiz
Reflection’s public bet is agentic reinforcement learning for coding, so the research rounds circle around rewards, credit assignment, and evaluation far more than around memorizing architectures. A common opening is to hand you a squishy problem and watch you shape it. How would you build a reward signal for an agent that edits code across many files and only “succeeds” once a test suite passes? Where does reward hacking creep in, and how would you catch an agent that games your metric instead of solving the task?
From there the panel pushes on the parts that break at scale: assigning credit over long trajectories where the useful action happened forty steps before the reward, deciding when off-policy data helps versus when it poisons a run, and designing evals that actually correlate with the behavior you care about rather than the behavior that is easy to score. If you have trained anything with RLHF or RLVR, be ready to talk about a real failure you hit and what you changed. Reading a paper is fine preparation; being able to say why the authors’ choice would or would not survive contact with a production training loop is what they are listening for.
Product engineering means building Asimov
The product loop is closer to a senior software engineering interview, but bent toward agent quality. Asimov’s job is to understand a giant, unfamiliar codebase and answer questions about it, which means retrieval over huge repositories, orchestration of an agent that plans and calls tools, and latency budgets that keep the thing usable. Expect design questions about how you would index a monorepo so an agent can find the right twelve files out of two hundred thousand, how you would evaluate whether the agent genuinely understood the code or just pattern-matched a plausible answer, and how you would keep cost per query sane when every step might call a large model.
The coding portion is practical. You will write real code, and the interviewer cares about how you structure an agent’s control flow, how you handle a tool call that returns garbage, and how you test something whose output is non-deterministic. Candidates who treat eval design as an afterthought tend to stand out in the wrong way, because at a lab like this the eval is often the actual product decision.
Reading the compensation, and the risk under it
Reflection does not publish bands, and public data on a company this young is thin, so treat any figure as a range to verify rather than a promise. Senior machine-learning and research roles at frontier labs generally land somewhere in the mid-six figures for total compensation, with strong candidates seeing offers that run from roughly $400K into the $700K range and higher for rare research talent. A large share of that number is equity, and there is a catch worth thinking through before you sign: a $25 billion private valuation is a paper number. The stock is illiquid, the company has shipped one product, and the whole thesis rests on an open-model strategy that has not yet proven it can beat closed labs or the Chinese open-weight models it was funded to answer. Weigh the offer against how much conviction you have in that bet, and check current figures on levels.fyi and in your own conversations rather than any single number you read.
How to walk in ready
Pick your track before you prep and go deep instead of wide. For infra, be able to talk about a real run you kept alive, with actual numbers: the model size, the GPU count, the utilization you got and how you clawed it up. For research, bring one reward or eval design you would defend under hard questioning. For product, have an opinion on what makes an agent trustworthy on a codebase it has never seen. Across all three, the panel is trying to answer one thing about you, which is whether you would make the next hard call well when the run is on fire at 3 a.m. and the answer is not in any paper. Show them the time you already did.
Practice the behavioral round:
