Safety and Mission Rounds at the Labs
A mission or values discussion is an opportunity to explain your reasons for joining and how you handle concerns about the work. Use your own views and experience, and connect them to concrete responsibilities such as evaluation and access control.
TL;DR: Explain why the work interests you, which risks concern you, and what evidence informs your view. If asked about unsafe work, describe how you would clarify the request, document the concern and use the appropriate review process. Do not invent agreement or experience to match the company.
What the round is measuring
The purpose and format of a values discussion vary by employer. Ask the recruiter what to expect and read the company’s current public materials. Prepare to discuss your motivation, the responsibilities of the role and how you would handle a concern.
You do not need to guess the interviewer’s preferred opinion. A useful answer states your view, the reasons behind it and what remains uncertain. If you disagree with a published approach, explain the specific point and the evidence that would change your assessment.
The four question shapes and what lands
| Question shape | What it measures | The answer that lands |
|---|---|---|
| why here, why this work | whether your reasons are your own | something they published, something you built, the gap between |
| how you think about the risks | whether you can hold a view and its counterargument | one real concern and one real counterargument, both with reasons |
| what if asked to build something unsafe | judgment and mechanism | understand, write it down, raise it through the named process, name your line |
| a values conflict you handled | honesty | a true story in five beats with a cost |
Why here, why this work. Make your motivation concrete. "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 the details may change my assessment. 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 eval harness
- Runs reproducibly on every checkpoint
- Otherwise 'test before release' is a sentence in a document
Weights access control
- Who can read weights and launch what
- Whether an exfiltration would be noticed
Reliability and audit
- SLOs, logs, incident discipline
- A fleet that cannot say what it ran said nothing
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
Answer the question asked before expanding into the broader topic. For a risk question, explain a concern and engage with the strongest counterargument you find persuasive. For a question about unsafe work, describe the review and escalation process you would use and the boundary you would not cross.
If you have no disagreement with a particular policy, do not manufacture one. Explain which parts you assessed and what questions remain. The aim is an accurate account of your reasoning, not a rehearsed position for every possible follow-up.
What to remember
- Prepare to explain your own reasoning; the employer’s format and criteria may differ.
- 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.
