Anthropic culture round: build your point of view on AI safety

Anthropic's culture round is not a quiz on the company's blog and not a loyalty test. Candidates report it as one of the rounds that decides the loop, and it is usually run by an engineer or researcher from outside your future team. It tests three things:

1. Do you take the mission seriously as a working constraint? Not "do you agree that AI safety matters" (everyone says yes) but: when safety and shipping pull apart in your actual job, what do you do, and what have you done before?
2. Do you have a point of view you built yourself? One you can state in two minutes, that has a few specific claims in it, that names where you are unsure, and that survives a push.
3. Are you honest under pressure? The interviewer will disagree with you on purpose. They want to see you update when the argument is good and hold when it is not, and say which one you are doing.

The round rewards calibration over enthusiasm. "I'm not sure, here's how I'd find out" scores better than a confident answer you can't defend. A memorized paragraph about "beneficial AI" scores worst of all, because the first follow-up exposes it.

What it is not:

• Not a values match on politics. You do not need to share every view in the reading pack. You need to have read it and to disagree specifically if you disagree.
• Not a research interview. An infrastructure engineer is not expected to explain sparse autoencoders. They are expected to know why interpretability matters to the company and what it would change about their own work.

Read the primary sources, not summaries of them. Budget about four hours. After each one, write down the answer to the question next to it in your own words. Those notes become your point of view.

If you only have one hour: Core Views, the company page, and the first third of The Adolescence of Technology.

Two habits while reading:

• Keep a disagreement list. Two or three places where you think the argument is weak. Interviewers often ask "what do you disagree with?", and "nothing" is a bad answer.
• Translate every idea into your job. "Security is part of the RSP" becomes "weights are the asset; I'd expect two-person review on anything that touches weight storage, and I've run a change like that before."

A point of view is four short claims, each with a reason. Write them on one page and say them out loud until they take about two minutes.

1. What I believe about the trajectory. How fast capability is moving and what drives it. Be specific: "Scaling has kept working for longer than most people predicted, so I plan as if the next two model generations are meaningfully more capable, and I'd rather be wrong in that direction."
2. What I think the biggest risk is, and why that one. Pick one of misuse, autonomy/misalignment, or societal disruption and explain why it's first for you. Ranking shows judgment; listing all of them does not.
3. What I think should be done about it, including what it costs. A position that costs nothing isn't a position. "I think a lab should be willing to delay a launch when the evals for a dangerous capability are inconclusive, even if a competitor ships first. That has a real commercial cost, and I'd still make that call."
4. Where I'm uncertain. One honest open question. "I don't know whether a single lab's caution moves the industry or just cedes ground. The race-to-the-top argument depends on the first answer and I find it plausible but unproven."

Then add the bridge: what this means in the job you are interviewing for. That's what turns a philosophy answer into a hiring signal.

Pressure-test it before the interview

Ask someone (or the coach on your copy, with Grill me) to argue the opposite of each claim. For each push, write down whether you would:

• Hold: the argument doesn't change the core claim; say why in one sentence.
• Refine: the argument narrows the claim; say the new version.
• Update: the argument is better than yours; say so plainly and name what convinced you.

Doing all three in one conversation is the strongest possible signal. Doing only "hold" reads as rigid; only "update" reads as having no view.

A senior backend engineer interviewing for an API platform team. Roughly what a strong two-minute answer sounds like:

"I think capability is moving faster than our ability to verify what models will do, and the gap is the problem. For my own work, the risk I can actually touch is misuse through the API: one customer, or one compromised key, using the model at scale for something harmful.

At my current company I own the abuse pipeline for a messaging API. We send about 40 million messages a day. Last year we wanted a classifier that blocked phishing before delivery. The first version had a 0.4% false-positive rate, which sounds small, but that's 160,000 legitimate messages a day. Product wanted to ship it anyway because phishing complaints were hurting us. I pushed for a two-week shadow mode: we logged decisions without blocking, then sampled 2,000 flagged messages and labelled them. We found that most false positives came from three enterprise customers who sent password-reset emails. We added a per-customer allowlist with review, got false positives to 0.05% (20,000 a day, mostly sent to a review queue instead of dropped), and shipped. Phishing complaints dropped about 70% in a month.

What I took from it, and what I'd bring here: safety work is mostly measurement. I'd rather ship a filter two weeks late with a known error rate than on time with an unknown one. Where I'm unsure is the other direction: at some point, delay itself is the harm, because users go to a less careful provider. I don't have a rule for that; I'd want the cost of delay written down next to the risk so the trade-off is explicit."

Why it works: one risk chosen for a reason, a real story with numbers, a trade-off that cost something, and an honest open question tied back to the job.

A staff engineer interviewing for inference infrastructure. The bar moves from "I made a careful call" to "I changed how an organization makes these calls":

"My view is that the most important near-term safety work is not glamorous. It's making safety properties cheap enough that nobody is tempted to skip them. When a safeguard costs 30% of throughput, it gets switched off in an incident. When it costs 2%, it stays.

At my last company we served a recommendation model to around 300 million users. We had a policy that any model change needed a holdout evaluation on harm metrics, but in practice teams skipped it under deadline because the eval took four days on shared GPUs. I didn't argue with the teams; I treated it as an infrastructure bug. I built a sampled, cached eval path that ran the harm suite on 5% of the holdout in about three hours, with a statistical check that escalated to the full run only when the sample showed a shift. Eval skips went from roughly one launch in three to zero over two quarters, and we caught two regressions that would have shipped. It cost one engineer-quarter and about $40,000 of GPU time a quarter.

I bring that up because I read the RSP the same way: the commitments are only as good as how cheaply the evals and security controls run on every release. On inference I'd expect to own things like making the safety classifiers' latency budget small enough to stay on, and making weight access auditable without slowing deploys.

Where I'd disagree a little with the reading: I'm less convinced than the essays that a lab demonstrating safe practices will pull competitors along. I think regulation and customer requirements do more of the pulling. But both mechanisms need the same thing from engineers: safeguards that are measured, cheap and boring."

Why it works at L6: a system-level insight (cost determines compliance), an organizational change with before/after numbers and cost, an explicit link to a primary source, and a specific, respectful disagreement.

Interviewers often switch from your stories to a hypothetical. There is no right answer; they grade how you reason. Use the same shape every time: who is affected, what you'd measure, what you'd do now, what would change your mind.

1. A new capability helps doctors but also helps someone synthesize something dangerous. Separate the populations: what fraction of requests are the beneficial use, and can you serve them through a narrower interface (verified accounts, a specialist product) rather than a blanket allow or block? Say what eval result would make you ship to everyone.
2. A competitor ships a feature you held back for safety reasons, and you're losing customers. Ask what new information the competitor's launch gives you (real-world misuse rate, if visible). Separate "they shipped" from "it turned out fine". A position worth holding: you'd revisit with data, not because of the pressure itself.
3. Your safety classifier blocks 1% of a large customer's legitimate traffic. Work the numbers: 1% of 5 million requests a day is 50,000 failures. Offer a path that keeps the safeguard and fixes the error: per-customer calibration, a review queue, an appeal route. Saying "turn it off for them" without a replacement is a red flag; so is "that's their problem".
4. You find that an internal eval was run on the wrong checkpoint before a launch. This is an honesty question. Report it right away, even if the re-run will probably pass. Explain why: the process only works if people trust that the eval matched the release.
5. A teammate thinks a safety concern you raised is overblown. Show how you'd disagree: write down the specific failure, the evidence, and what would settle it, then commit to that test rather than to winning.

• Recited mission language. "I'm passionate about building safe, beneficial AI" with nothing behind it. The interviewer will ask "what does that mean in your job?" and you need an answer.
• No disagreement anywhere. Agreeing with every sentence of every essay reads as not having thought, or as telling them what they want to hear.
• Contempt for the other side. Dismissing either the people who think AI risk is overstated or the people who think it is catastrophic. The company's own writing takes both seriously.
• Safety as someone else's job. "The safety team handles that." The round looks for people who treat it as part of their own work.
• Heroic stories with no cost. If doing the right thing cost nothing, it doesn't show judgment.
• Changing your view because the interviewer frowned. Update on arguments, not on pressure, and say which is happening.

Prepare one or two sentences for each:

• "What's one thing in our published views you disagree with?"
• "Why work here instead of a lab you think is less careful, where you might have more influence?"
• "Should frontier labs publish their safety research, including what didn't work?"
• "When would you stop a launch you'd been working on for six months?"
• "How would you know if this company was drifting from its mission? What would you do?"
• "What's a risk from AI you think is overrated?"
• "Tell me about a time you were wrong about something important. How did you find out?"

The last one comes up often. Use a real mistake with a real consequence and say what you changed afterwards.

Mid-level (L4)

• Has read the core sources and can state, in their own words, why the company exists and what the RSP is for.
• Brings at least one real story where they chose quality, honesty or user safety over speed, with what it cost.
• Responds to pushback by thinking out loud, and admits uncertainty instead of bluffing.

Senior (L5)

• States a two-minute point of view with a chosen top risk, a costly position and an honest open question.
• Connects it to the work of the team they are joining (evals, abuse, security, reliability) with specifics.
• Stories carry numbers (error rates, users affected, delay accepted) and show the trade-off was explicit.
• Holds, refines or updates under pressure, and says which one they are doing.

Staff (L6+)

• Talks about safety as a property of systems and incentives: makes safeguards cheap enough to stay on, changes processes so the right call is the default.
• Has a specific, well-argued disagreement with some part of the company's published thinking and engages with the strongest counter-argument.
• Shows how they have raised a hard concern across an organization: how they escalated, who they brought along, and what happened when they lost.
• Describes how they would notice the company, or their own team, drifting, and what they would do about it.