Anthropic AI Research Engineer Full Loop Interview Experience (2025) - Offer

Round 1: Research Coding - Response Safety Filter

Problem: Implement a response safety filter that scores model outputs along multiple safety axes (bias, harmful content, privacy leakage, hallucination), returns a 0-1 safety score, exposes a strictness control, and produces an explanation for each flagged response.

I went with a Strategy pattern. Each axis is its own rule class with a score method, a name , and an explain method that returns the evidence for the decision. The aggregator is weighted, with a strictness parameter that acts as a scaling factor on the threshold rather than on the scores themselves (this matters: scaling scores would corrupt the downstream interpretability). I added an LRU cache keyed on hash(prompt) + hash(response) + model version so production traffic with repeat prompts stays cheap. The explainability piece returned a structured object per rule, not a concatenated string, because the interviewer pushed on auditability during the follow-up.

The follow-up questions were all about composition. How do you add a new rule without touching the aggregator. How do you handle a rule that depends on another rule's output. How do you version rules when the team retrains them. Most of the conversation was about design boundaries, not code correctness.

[[problem/595?company=7|Stack Traces Parser with Denoising]] is the closest pattern in terms of the "parse, score, explain" shape.

Round 2: Research Coding - Constitutional AI Pipeline Sketch

Problem: Design and partially implement a simplified Constitutional AI pipeline: principle definition, data generation with critique and revision, training, and evaluation.

This round was less about writing runnable code and more about sketching the data flow and making correct tradeoffs. I walked through storing principles as a prioritized config rather than hardcoding them, doing critique-and-revision with a separate critic model and sampled principles, and running the downstream training as a two-stage process: supervised fine-tuning on revised responses first, then RLAIF with a reward model trained on the critic's preferences. PPO for the RL stage with a KL penalty against the SFT model to prevent drift.

The interviewer pushed hardest on evaluation. Harmlessness and helpfulness scores are easy to state but hard to measure without reward hacking. I talked through paired preference eval with held-out human labels, constitution compliance rate as a leading indicator, and the risk that the critic model itself has the same blind spots as the base model. We ended on "how do you break out of the circular eval problem" and I said you do not, you acknowledge it and invest in external red-teaming.

[[problem/593?company=7|Recipe Manager]] is the closest pattern for the pipeline composition shape, even though the domain is different.

Round 3: ML Systems Design - Training Infrastructure for a Safety-Tuned Model

Problem: Design the end-to-end infrastructure for training a safety-tuned LLM. Requirements include multi-model parallel training, terabytes of mixed synthetic and human feedback data, real-time safety monitoring on inference, A/B testing of model versions, and full auditability.

I started with the data layer: a versioned data lake on S3 with Iceberg tables, DVC or LakeFS for dataset lineage, a feature store for the small tabular safety-signal features. Training layer: Ray on Kubernetes for orchestration, DeepSpeed or Megatron for the actual distributed training, ZeRO-3 for memory. Checkpoints go to object storage with retention and signed provenance.

Inference layer: the safety filter from Round 1 lives as a sidecar in front of the model server, and it runs every response through the scored rules before the response is returned to the user. Prometheus for metrics, Grafana for dashboards, PagerDuty on threshold breaches. For A/B testing I used a traffic router that supports sticky bucketing by user ID with safety-indexed holdouts, which means the ten percent traffic going to a new model gets oversampled for safety metrics.

Auditability was the part the interviewer cared about most. Every response gets logged with the constitution principles used, the critique trace if any, the safety scores, and the model version. These go to an append-only store with a query layer. We talked for fifteen minutes about how to keep the audit store from becoming the bottleneck.

Tradeoffs I called out: cost vs latency on the safety filter (caching helps but has its own staleness risk), accuracy vs coverage on the rules (a more conservative rule catches more but annoys users), batch vs online for the RLAIF loop (online is more responsive but harder to debug).

[[problem/331?company=7|Task Manager System]] is the closest shape for the pipeline orchestration layer.

Round 4: Culture and Leadership

This round is the one that eliminates more people than any of the technical rounds. The interviewer was a senior research engineer who had been at Anthropic for three years. The explicit framing was: we are checking whether you care about the mission for real, whether you can work on a team where people disagree about important things without getting defensive, and whether you think on a five-plus year horizon.

Questions I got: describe a time you disagreed with a technical decision and what you did, describe a moment where you realized your own work had a safety risk and how you responded, tell me about a collaboration that almost failed and what saved it, what would make you leave Anthropic in three years.

I used STAR for everything and I leaned into tradeoffs constantly. The interviewer explicitly said at the end that the red flags they watch for are "just here for the money," "does not actually believe in safety work," "lone wolf energy," and "downplays the risks." I have seen friends wash out here despite clean coding rounds.

[[problem/330?company=7|Banking System]] is not really relevant here but was on my prep list for the coding rounds.

Result

Offer came about three weeks after the onsite, slightly delayed by team matching. I ended up on a team working on model evaluation infrastructure, which was my top pick during the matching conversation. The comp was competitive with top frontier labs, equity was meaningful, and the location flexibility worked for my situation.

Tips

1. Read the Anthropic core papers before the loop. Constitutional AI, the original RLHF paper, the Sleeper Agents paper, and the Responsible Scaling Policy. The interviewers will assume you have and will build on that context without explaining it.
2. The mission-fit round is not a formality. It carries as much weight as any technical round. Prepare honest answers about why you care, what you have done that shows it, and where you think the field is going. Canned answers get caught immediately.
3. Research Engineer is not SWE with ML garnish. The coding rounds reward systems thinking, pipeline design, and tradeoff articulation more than optimal algorithmic solutions. Know your RLHF, SFT, RLAIF, PPO, DPO vocabulary cold.
4. Bring a concrete alignment project to every round. Every interviewer dug into one of my side projects for at least ten minutes. If the deepest thing you can point to is a course project, that is a tell.
5. Systems design rounds include auditability as a first-class requirement. Traditional system design prep undercooks this. Practice explaining how you would log, version, replay, and externally verify a model training pipeline.
6. Tradeoffs out loud, always. The Anthropic interviewers explicitly value candidates who reason about tradeoffs rather than asserting single answers. When you hit uncertainty, name the axes and walk through the choice.

If you are aiming at Anthropic, OpenAI, or DeepMind research engineer loops, start the mission-fit work now, not the week before the screen. Good luck.