How Top AI Companies Actually Structure Interviews

Most candidates prepare for an "AI interview" as if it were one thing. It is not. OpenAI's "ML research engineer" loop is unrecognizable next to Anthropic's "research engineer" loop, which is unrecognizable next to Google DeepMind's "research scientist" loop, which is unrecognizable next to Meta AI's "applied ML" loop, which is unrecognizable next to Scale AI's "forward-deployed engineer" loop. The companies you might apply to evaluate orthogonal skills under similar-looking titles. If you walk into the wrong loop with the wrong preparation, you will fail elegantly. This lesson gives you the actual structure, by company, by role, with the patterns and red/green signals that decide hires.

#The Four Canonical Archetypes

Every AI engineering interview in 2025-2026 maps to one of four archetypes. The job titles vary wildly but the archetypes are stable.

The four archetypes:

#Company Deep-Dives

#OpenAI

1. Recruiter screen (30 min). Background, what you've shipped, why OpenAI.
2. ML coding screen (60 min, online). Live coding in Python. Implement something non-trivial in ML: tokenizer, attention forward pass, a tiny GPT training step. Not LeetCode. They want code that compiles and runs and has correct shapes.
3. ML conceptual interview (60 min). Verbal probing on transformers, optimization, distributed training, eval design. They will go deep on whatever you list on your resume — claim experience in RLHF and you will get drilled on PPO vs DPO, KL penalty, reward modeling failure modes.
4. System design — ML flavored (60 min). "Design a system to train a 1T-parameter model on 10k GPUs." They are testing whether you have actually thought about FSDP, pipeline parallelism, tensor parallelism, activation checkpointing, gradient accumulation, communication overhead.
5. Onsite (4-5 hours): repeats of the above with multiple interviewers, plus a 60-minute "research discussion" where you walk through a paper you co-authored or a project you led, and they probe for depth.
6. Cultural / bar raiser (60 min). What would you do with infinite compute? What do you think OpenAI is getting wrong?

What this is REALLY testing: not just whether you can code attention. Whether you actually understand the math (the shape reasoning trips up about 60% of candidates), whether you understand causal masking (a quarter of candidates get the mask geometry wrong), and whether your FLOP estimate is within a factor of 2 of correct (the FLOP question separates senior from junior).

#Anthropic

1. Recruiter screen.
2. Take-home or live coding screen (90 min). Often a multi-part problem that builds: implement a small transformer, train it on a tiny dataset, debug a known issue (e.g., learning rate too high), produce a learning curve. The take-home is intentionally open-ended; bias toward shipping a working solution with documentation over a half-finished elegant one.
3. Research engineering interview (60-90 min). "Walk me through a recent project. What was the most surprising thing you learned? Why?" They probe for the depth of your understanding of why things work, not just whether they work.
4. Mechanistic interpretability / model behavior round (varies by team). For some teams, expect questions like "what does it mean for a model to have a circuit?" or "if you wanted to know whether GPT-2 learned indirect-object identification, how would you find out?"
5. System design — ML flavored.
6. Cultural / values round. Anthropic takes its safety mission seriously and probes hard on whether you have actually thought about it. Bullshit detection is high.

#Google DeepMind

1. Phone screen with a recruiter.
2. Technical phone screen. A coding problem (sometimes LeetCode-flavored medium, sometimes ML-flavored).
3. Research presentation (45-60 min). You present a project (publication, thesis, or substantial side project). The panel asks probing questions for the entire time. The presentation itself is barely 15-20 minutes.
4. Multiple onsite interviews: ML coding, ML theory (information theory, statistics, optimization), system design, leadership/values.
5. Hiring committee review (Google-wide). Decisions are not made by the interviewers; they are made by a separate committee that reads the packet.

DeepMind values published research more heavily than OpenAI or Anthropic. A first-author NeurIPS/ICML/ICLR paper is roughly equivalent to a strong loop performance.

What this is REALLY testing: did you actually do the math, or did you read about RL on a blog post? The variance derivation is one page of algebra; if you cannot reproduce it, you do not understand the problem RL methods solve. The "when each fails" follow-up separates the people who memorized "baselines reduce variance" from the people who have actually used baselines in practice and watched them fail.

#Meta AI (FAIR + Applied)

For applied ML at Meta:

1. Recruiter screen.
2. Coding screen (45 min). LeetCode-medium. Yes, even for ML roles. Meta uses Coderpad. They follow the standard FAANG signal-extraction: optimal solution, clean code, edge cases, communication.
3. ML breadth (60 min). A range of topics: classical ML (logistic regression, decision trees), deep learning (CNN, transformer basics), evaluation (AUC, precision/recall, A/B testing).
4. ML system design (60 min). "Design the ranking system for Reels." or "Design a system to detect hate speech in 50 languages." Capacity reasoning. Latency budgets. Trade-offs.
5. Behavioral / leadership (60 min). Meta's "behaviors" framework. Be ready with STAR-format stories.

The Meta applied ML loop is the closest in spirit to a generic Big Tech software engineer loop — LeetCode is genuinely a gating signal.

What this is REALLY testing: experimentation discipline. Senior answers cover novelty bias, segment heterogeneity (was it just one country?), guardrail metrics (did session time, sharing, comments, or downstream retention drop?), interaction with other concurrent experiments, statistical significance vs practical significance, and the inevitable "what's the long-term effect" question that A/B tests cannot directly answer. Junior answers stop at "is p < 0.05?"

#Scale AI

1. Recruiter screen.
2. Take-home: build something. Often a small RAG system, an evaluation pipeline, or a fine-tuning experiment with a specific dataset. 8-16 hours of work. You ship a repo with a README.
3. Code review of the take-home (60 min). They walk through your code, probe for trade-offs you made. "Why this chunking strategy?" "What would you do differently with 10x the data?"
4. System design — applied AI flavored. "Design the labeling QA pipeline for a $50M annotation contract." Real Scale problems.
5. Customer / product round. Roleplay: you are deployed at a Fortune 100. The CTO is in the room. They are skeptical of LLMs. Convince them to ship your solution.
6. Final round with a senior leader.

What this is REALLY testing: do you know that retrieval quality is usually the bottleneck, not generation? Do you ask the customer to provide failing examples before you touch anything? Do you have an evaluation harness or are you eyeballing? Senior answers always start with "first, can I see 20 specific failures?" Juniors start with "I would try a bigger model."

#NVIDIA (Applied DL / ML Systems / CUDA)

NVIDIA in 2026 is hiring aggressively across ML engineering, applied research, and the systems track that touches CUDA / Triton / TensorRT-LLM. The loop varies sharply by sub-team.

1. Recruiter screen. Background, motivation, US/India location.
2. Coding screen (60 min). Often C++ if you're targeting kernels/inference infra, Python for applied ML. Mid-to-hard LeetCode with a systems lean. Pointer arithmetic, memory layout, cache locality questions appear in CUDA-track loops.
3. ML / GPU systems round (60 min). "Walk me through a forward pass of attention. Which operations are memory-bound vs compute-bound on an H100? What does FlashAttention do differently and why does it help?" If you cannot answer those three, the CUDA track is closed to you.
4. System design (60 min). "Design TensorRT-LLM's continuous batching for a 70B model." or "How would you serve LLaMA-3-405B on 8x H100s with sub-200ms TTFT?"
5. Behavioral + manager round.

REALLY testing: do you actually know how an H100 is laid out? 80GB HBM, ~1.5TB/s bandwidth between GPUs over NVLink, ~600GB/s over PCIe. A 70B model in FP16 is 140GB — does not fit on one GPU. Tensor parallelism across 8 GPUs gives ~17.5GB/GPU for weights, leaving ~60GB for activations + KV cache. KV cache for a 70B model is ~250KB per token per batch element — so 60GB / 250KB = ~240k tokens of KV cache budget per GPU, more than enough for serving but tight for very long contexts. Senior candidates draw this math out unprompted.

#Stripe (Applied ML / Fraud / Payments AI)

Stripe's ML interview is closer to a traditional senior-SWE interview than most candidates expect. The bar on coding and systems is high; the bar on cutting-edge ML research is moderate.

1. Recruiter screen.
2. Coding (60 min). Two LeetCode-medium problems. Clean, idiomatic Python or Go. They care about code style as much as correctness.
3. System design (60 min). Often not ML-specific — "design Stripe Radar's real-time fraud system" or "design a system to handle disputes at 1M/day." The ML appears as one component, not the whole system.
4. ML breadth (60 min). Classical ML emphasized — logistic regression, gradient boosting, calibration, class imbalance, AUC vs PR curves. Stripe Radar is largely XGBoost in production, not LLMs.
5. Behavioral + ownership (60 min). Stripe's famous "Stripe Press"-flavored values round. "Tell me about a time you owned an outage from detection to postmortem."

REALLY testing: production discipline. Look for: training/serving skew, distribution drift between offline eval window and current traffic, calibration check, segmented metric review (does the 8% lift hold across geographies, card types, merchant categories?), guardrails on chargeback rate, downstream impact on auth rate. The juniors say "p < 0.05, ship." The seniors say "I want to see the segmented lift table and the calibration plot before I sign off."

#Top-Tier AI Startups (Cohere, Mistral, Hugging Face, Together, Modal, Replicate, Inflection-era successors)

The loops here are smaller (3-4 rounds), faster (1-2 weeks total), and more dependent on what you have built. A strong GitHub or a published model release on Hugging Face Hub can almost single-handedly carry the loop.

Typical loop:

1. Founder or technical recruiter chat.
2. Live coding + ML discussion combined (90 min).
3. Project presentation: what have you built? Be ready to deep-dive.
4. Founder/CEO round. Cultural + vision alignment.

#What FAANG Asks vs What Startups Ask

The contrast is real and important:

FAANG asks

• LeetCode (yes, still, even for ML)
• Fundamentals you would expect from a master's thesis defense
• "Design Netflix-recommendations / YouTube-search / Reels-ranking" system design
• Leadership and "behavioral" stories
• Crisp answers under time pressure

Top AI labs (OpenAI/Anthropic/DeepMind) ask

• ML coding (not LeetCode — attention from scratch, training-loop debugging, autodiff trace)
• Deep mechanistic understanding (why does X work, not just what is X)
• Distributed training at the FSDP/TP/PP level
• Eval design and the meta-question of "how do you know your model is good"
• Long take-home projects

Top AI startups ask

• What have you built recently?
• Code review of YOUR repo
• Design something we actually build (RAG, eval pipeline, agent)
• Trade-off reasoning under product constraints
• Cultural alignment with a small team

• Mix of FAANG-style coding + practical ML
• More emphasis on RAG/LLM productization than research depth
• Strong SQL expected, often a SQL round
• Less weight on take-homes (they assume copy-paste risk)
• Behavioral round is heavier than at frontier labs

#10 Real Interview Questions and What They Are REALLY Testing

#1. (OpenAI, ML coding)

REALLY testing: do you understand the difference between top-k and top-p? Can you handle the edge case where the most likely token has probability > p? (Answer: always include it, then truncate.) Can you handle the edge case where all probabilities are equal (uniform)?

#2. (Anthropic, ML conceptual)

REALLY testing: catastrophic forgetting awareness. Senior answer: "first I would check whether evals are measuring something the base model used to do but my fine-tuning destroyed. Almost certainly the fine-tuning data is narrow and the model forgot capabilities outside that narrow distribution. Fix: mix in 5-10% of the pretraining distribution, lower LR, fewer steps, or use LoRA instead of full fine-tune."

#3. (DeepMind, ML theory)

REALLY testing: have you read past the surface tutorials? The phenomenon (Adam reaches lower training loss but worse generalization in many settings) is well-documented; the explanation involves the implicit regularization of SGD's noise, the adaptive normalization in Adam that can produce sharper minima, and recent results on flat-vs-sharp minima and generalization.

#4. (Meta AI, ML system design)

REALLY testing: capacity math. 1B/day = ~12k QPS average, probably 50k peak. 200ms p99 with a 7B-parameter LLM on a GPU is impossible economically — you need a tiered system: cheap classifier first, escalate to LLM only on uncertain cases. Senior candidates draw the tier diagram in the first 5 minutes; juniors start with "I would use BERT."

#5. (Scale AI, applied AI)

REALLY testing: do you know that retrieval-correct does not imply generation-correct? The 30% gap is usually the LLM hallucinating around the retrieved context, or the chunk being too small to contain the answer, or the prompt template fighting the retrieved evidence. The diagnostic is: feed the model the retrieved chunks plus the question, manually inspect 50 wrong answers, classify the error mode.

#6. (Google applied ML)

REALLY testing: production-realistic chunking. Most candidates implement char-level or word-level splitting and miss that token != word != char. Senior candidates use the tokenizer to measure token length, use a sentence splitter (spaCy or nltk), greedily pack sentences into chunks under the limit, and handle the edge case where a single sentence exceeds max_tokens.

#7. (Mistral / Cohere)

REALLY testing: depth. Five minutes in they will hit "why did you choose batch size 32?" and "what would you do differently at 10x the dataset?" and "what was the most surprising thing you learned?" If your project has been told as a 60-second pitch a hundred times, but you cannot answer hour-2 depth questions, the rejection is automatic.

#8. (Anthropic, code review style)

#9. (Multiple companies, system design)

REALLY testing: capacity reasoning + cost modeling + serving infra knowledge. 100M weekly users, ~5 queries per active session, avg 1k tokens in/out. That's 500M queries/week ≈ 800 QPS sustained, probably 5000 QPS peak. Tokens-per-second of an H100 on a 70B-class model with vLLM continuous batching is ~30-50 tok/sec/user at FP8. Multiply through. Add safety filtering. Add caching. Add a CDN for the frontend. Add KV cache pooling. The answer should fill a whiteboard.

#10. (FAIR / DeepMind research)

REALLY testing: research taste + reading speed + critical thinking. Can you identify the actual contribution (not just the abstract claim)? Can you spot the missing baseline? Can you propose two extensions that would change your view of the result? This is the most predictive single round for research roles — bullshit is impossible.

#Red Flags vs Green Signals

#Red flags (instant rejection or near-instant):

• You cannot explain the math behind a method you listed on your resume. "I used RLHF" but you cannot derive PPO. "I used LoRA" but you cannot explain why the rank matters. The mismatch between resume and demonstrated depth is the most common rejection signal.
• You answer in buzzwords. "I would use transformers and embeddings to do semantic search." The interviewer is waiting for you to say something specific.
• You do not ask clarifying questions in design rounds. Jumping to a solution before knowing scale, latency, cost constraints is a junior signal.
• You cannot name a single recent paper you have read or model you have tried. Inexcusable for any ML role in 2025-2026.
• You complain about previous interviewers / previous jobs. Cultural red flag, instant downgrade.
• You are dishonest about something small. Lying about a single technical detail (claiming a Kaggle medal you did not get, claiming you wrote code that you copy-pasted) gets you blocked, sometimes industry-wide.
• In a take-home: code that does not run, no README, no documentation, no tests. It signals you ship broken work.
• In a system design: no cost reasoning. Senior engineers always think about money.

#Green signals (can compensate for shaky moments):

• You say "I don't know, but here is how I would find out." Interviewers love this. It is the single highest-EV phrase in any technical interview.
• You point out an assumption in the question. "You said 1B users per day — are these all unique, or is this query volume?" Demonstrates the discrimination senior engineers have.
• You give the obvious answer first, then immediately list its trade-offs. "I would start with logistic regression because it is the cheapest baseline and I cannot beat it without evidence. The trade-off is X, Y, Z."
• You explicitly acknowledge what the interviewer is testing. "I think the interesting case here is the imbalanced data scenario. Let me address that." Saves time, signals seniority.
• You ship working code on the take-home with a clear README. Most candidates do not. Even mediocre code that runs cleanly beats elegant code that does not compile.
• You connect the question to a real-world example. "This is similar to what Anthropic does for constitutional AI — the difference is..." Demonstrates that you actually read the field.
• You disagree with the interviewer respectfully, with reasoning. This is the single biggest senior-vs-junior tell. If the interviewer says something you think is wrong and you nod and agree, you have lost senior-level signal.

#30-Minute Pre-Interview Prep Checklist

For any AI role, once you know the company and archetype:

1. (5 min) Read the company's most recent blog/research post.
   - Pull 2-3 specific keywords (architectures, frameworks, products).
   - Memorize one specific finding so you can name-drop in round 1.

2. (10 min) Find Glassdoor + Blind threads for this exact role.
   - Note: the round structure, the named question types,
     anything specific to YOUR archetype.
   - Note: any "easy" rejection patterns.

3. (5 min) Find 2 employees on LinkedIn who joined in the last 6 months.
   - Read their summary, recent posts.
   - Look at what they say they work on.

4. (5 min) Open the JD again. Highlight every technology or skill listed.
   - For each, decide: "I can speak to this" or "I cannot."
   - For the "cannot" list: do you need to fake it (no) or
     plan a graceful "I haven't used X but I would..."

5. (5 min) Pick ONE story you will tell from your background that maps
   to this role. Practice the 2-minute version out loud.

This 30 minutes beats 8 hours of generic prep almost every time.

#Quick Check

#Key Takeaways

• There are four AI-engineering archetypes — ML research, research engineer, applied ML, ML platform — and they test orthogonal skills under similar titles. Always identify the archetype first.
• FAANG applied ML still uses LeetCode; frontier labs (OpenAI, Anthropic, DeepMind) do not. Direct your prep accordingly.
• The "what is this round really testing" question is the highest-leverage prep question you can ask. Surface questions hide deeper signals.
• Red flags are almost always about depth-of-claim mismatch, buzzword answers, or zero recency awareness. Mitigate by being honest about what you don't know and demonstrating recent learning.
• Green signals are admitting "I don't know but here's how I'd find out," explicit assumption-checking, and respectful disagreement with the interviewer. They compensate for shaky moments.
• 30 minutes of company-specific research beats 8 hours of generic prep. Always research before you grind.