Safety and Mission Rounds at the Labs

TL;DR: The round tests honest engagement, not a position. Expect questions of four kinds: why this company and this work (an answer with specifics about the company's stated approach and your own history), how you think about the risks of the technology (an answer that holds a real concern and a real counterargument without collapsing into either), what you would do if asked to build something you thought was harmful (an answer with a mechanism: who you would raise it with, what evidence you would bring, where your line is), and how you have handled a values conflict before (a true story with a cost). For an infrastructure engineer the concrete ground is reliability, access control and evaluation infrastructure, because those are where an infra engineer's work touches safety in practice. The answers that fail: reciting the company's blog back to it, claiming no concerns, claiming only concerns, and a hypothetical refusal with no mechanism behind it.

What the round is measuring

The loop notes for the labs that run these rounds describe them as conversations about motivation, judgment and culture rather than tests of doctrine. The interviewer is usually a senior engineer or a researcher, and they are listening for a few things: whether you have thought about the technology's effects at all, whether you can disagree with the company and say so, whether your reasons for wanting the job are your own, and whether you would raise a concern through a mechanism rather than either swallowing it or grandstanding. The failure they are screening out is not a wrong opinion; it is a candidate who cannot hold a view under a follow-up, or who has none.

The four question shapes and what lands

Why here, why this work. Specific beats sincere. "I read your published approach to responsible scaling and the part I found most credible was the commitment to evaluation infrastructure; my last two years were spent building evaluation pipelines, and I think the infrastructure side of that commitment is under-built everywhere" lands. "I want to work on the most important technology of our time" does not, because everyone says it. Tie the answer to something the company has actually published, something you have actually built, and a gap between them you could fill.

How you think about the risks. Hold two things at once. A concern you find real (misuse at scale, the concentration of capability, the reliability of systems that make consequential decisions, the pace outrunning the ability to evaluate), stated plainly and with a reason, and the counterargument you also find real (the benefits are concrete and large, the alternative to careful labs building it is careless ones, the risks are more tractable with better tooling), stated with equal plainness. The follow-up will push on whichever side you leaned toward; a candidate who has both sides ready is not pushed over. Specifics from your own layer help: an infrastructure engineer has seen what an unmonitored fleet does and what a well-instrumented one prevents, and that experience is a legitimate way into the question.

What you would do if asked to build something you thought was unsafe. The answer is a mechanism, not a stance. "First I would make sure I understood what was being asked and why, because half the time the concern dissolves on the details. Then I would write down the concern with the evidence I had and raise it with my lead, and if it was a real safety question, with whoever the company has designated for that; your published process names one. I would build the parts that were clearly fine while that was being resolved. If the answer came back and I still thought it crossed a line I could name, I would not build it, and I would say so in writing." Then the interviewer's follow-up, "where is the line?", wants a real answer: a capability you would not want to be responsible for enabling, described concretely rather than by category.

A values conflict you have handled. A true story with a cost, told in the same five beats as any other behavioral story (The Reliability Pushback Story): the situation, the signal that made you uncomfortable, what you did and who you told, what it cost you, what changed. Infrastructure engineers have these stories: the deploy you refused to sign off, the data access you questioned, the eval that was skipped and you said so, the incident report you would not soften. The story does not need to be dramatic; it needs to be true and to have had a price.

The infrastructure engineer's concrete ground

Candidates in this role sometimes think the safety conversation belongs to researchers. It does not, and saying why is a strong answer. Three places where infrastructure is the safety mechanism:

• Evaluation infrastructure. A lab's commitments to test models before release are only as real as the harness that runs the tests reproducibly on every checkpoint (Evaluation and Data Pipeline Infrastructure). An infra engineer who says "the eval pipeline is where the policy becomes a fact" has understood the round.
• Access control and weights security. Who can read model weights, who can launch what on which cluster, whether an exfiltration would be noticed: these are infrastructure properties, and a lab's stated security commitments are implemented by the platform team.
• Reliability and monitoring. Systems that serve consequential decisions need the SLOs, the audit logs, and the incident discipline that infrastructure engineers own; a fleet that cannot say what it ran cannot say what it did.

Bringing one of these up unprompted, with a specific thing you have built, turns the round from a philosophy discussion into a conversation about your work.

The answers that sound safe and fail

• Reciting the blog. The interviewer wrote or read it; they want your view, including where it differs.
• No concerns. "I think the risks are overstated" as a complete answer reads as not having thought about it, or as telling the interviewer what you assume they want.
• Only concerns. "I think this technology is dangerous and I want to be inside to slow it down" raises the question of whether you will do the job.
• The hypothetical refusal. "I would refuse" with no mechanism, no evidence and no line reads as a pose; the mechanism is the answer.
• The rehearsed position paper. A five-minute monologue on alignment theory answers a question nobody asked and leaves no room for the conversation the round is.
• Agreeing with every follow-up. If the interviewer pushes and you fold each time, the view was not yours.

Preparing without over-preparing

Read what the company has published on its approach (the policy documents, the safety framework, the founders' stated reasons), and find the two or three points you find most and least convincing; that is the material for "why here" and for the risk question. Write down one values conflict from your own work in five beats. Decide, honestly, where your own line is, in concrete terms. Then stop; the round is a conversation and a script will show.

Working it in the room

"How do you think about the risks of what we build?" wants a concern and a counterargument, both with reasons, and a bridge to your layer (evaluation, access, reliability). "What if you were asked to build something you thought was unsafe?" wants the mechanism and then the line. The follow-up held back is "what in our published approach do you disagree with?", and a candidate with nothing has not read it or will not say. The answer that sounds right and fails is the fluent recitation of the company's own framing.

What to remember

• The round measures honest engagement and judgment, not a position.
• Why here: something they published, something you built, the gap between.
• Risks: one real concern and one real counterargument, both with reasons; hold both under the follow-up.
• Unsafe request: understand, write it down, raise it through the named mechanism, build what is fine meanwhile, name your line concretely.
• Infrastructure is the safety mechanism in evaluation, access control and reliability; bring one you have built.