GDM’s AGI Safety and Alignment Team is hiring for multiple roles. This is the team at GDM, led by Rohin Shah, that aims to reduce existential risks from AI systems. You can listen to many of Rohin’s takes in his podcast on 80,000 hours.
There is no one ‘type’ that we are looking for—we want excellent people. We think of the role as ‘member of technical staff’ though different people will have more of a research engineer or scientist flavour. We are flexible on location though most people will be most productive in either San Francisco or London. You should apply here (for the US) or here (for the UK) after reading the guidance here.
Many of the basic facts about why ASAT is a good place to work and how we think about research are mostly unchanged since this post in 2025.
We are focused on risks of more severe harms from more advanced AI than the rest of GDM. You can read our high level AGI Safety and Security Approach. Our work includes aligning AGI, defending against misaligned deployments, and supporting coordinated safety.
We’ve recently shared a recap of some of our recent work, which gives a better sense of what we do in practice. Deep alignment and stress testing are relatively new areas for us, created in response to increased capabilities, so in those areas there will likely be more flux in exactly what we do.
We cover parts of our overall alignment approach and research directions in 5 minute talks in our AGI safety course.
If you’re reading this post, you probably already have a decent sense of the ways that technical safety teams at AI companies are different from other kinds of AGI safety work, so we won’t go into that. However, we think that ASAT also has a fairly different orientation towards AGI safety, relative to (our perception of) safety teams at Anthropic and OpenAI. Technical enablers for governance. Governance often has different technical requirements: for example, depending on the application, it may need to be more standardized, legible, applicable across AI companies, robust to gaming, etc. We try to anticipate governance and build the technical backing that it would need. [1] Examples include the
Prefer knowledge over advocacy. Everyone wants AI systems to be safe. Often, the challenges are factual disagreements (e.g. are software-only intelligence explosions plausible?) and execution (e.g. how do you align superhuman AI systems?). We view our role mainly as producing evidence to help resolve factual disagreements, and developing techniques to improve execution. As an example of how this attitude plays out, we studied the conditions under which training on CoT is risky or not, rather than producing demos where training against CoT is bad, or focusing on failures of CoT faithfulness.
**Focus on much more capable future systems ** Our work tends to be driven more by conceptual arguments about future AI capabilities and risks, because we expect that much of the work on current AI systems won’t generalize to the systems that pose significant risks. Examples include
Coherent overall approach. ASAT aims for its work to feed into one overarching approach (which consists of many different bets). This is a major reason why we produce big technical roadmaps like An Approach to Technical AGI Safety and Security and the GDM AI Control Roadmap.
To be clear, we’re not claiming that these are unalloyed goods. Advocacy is obviously important in some circumstances; it would be bad if everyone focused purely on knowledge. Our focus on future systems has likely led us to be late on impactful opportunities with present AI systems, such as work inspired by the persona selection model. Our main reason for writing this down is to select for candidates who are broadly enthusiastic about this approach, who will likely fit better in ASAT.
First and foremost, you will be doing very impactful work as part of ASAT. We’re proud of the work we’ve done recently, and we believe we can accelerate similar work with more people. The unique aspects above also make our work somewhat more neglected in the research community; for much of the work discussed above, it seems plausible that no one would have done the work if we hadn’t done it.
We have significant leadership support for our work. GDM and Google are pretty interested in being responsible and then setting norms and policy around safety. Our work both informs that process and also helps set the bar higher than it would otherwise be. Because Google has a reputation for seriousness and responsibility, actions Google takes generally have a greater policy impact than those actions at other labs might.
Since we have access to frontier models, information about how they were produced, and substantial amounts of compute, we can do safety research that would be hard to do anywhere other than a frontier lab.
The team is very strong—you’ll be working with and learning from some fantastic colleagues.
Team members who value doing external research are encouraged to do external advising. We often have research project ideas that are not particularly advantaged by being inside a frontier lab, so it can just be better to do them externally. We also see this as a substantial investment in the AGI Safety field’s capabilities, and are happy to see that many of our alumni are working full-time in safety. Some at GDM, but also many at Anthropic, OpenAI, UK AISI, and more.
Last, while everyone says this, the team culture is actually great. Team members know the point of the project they’re working on; any team member can raise an objection and they will be listened to. People are incredibly helpful and generous with their time. Because we genuinely share a mission, we can coordinate in ways that other teams struggle to.
We previously wrote an FAQ on common reservations people had about joining GDM here that mostly still holds. If you have any other questions, please leave a comment on this post. Please don’t email us individually; we get too many of these and don’t have the capacity to reply to each one.
Ultimately, we want to hire excellent people and then adapt the team to enable them to have the most impact.
[3] Having said that, we think we especially want:
You don’t necessarily need to be an experienced researcher, we have some roles that depend more on engineering skill. As a researcher, you do have to be a fairly skilled engineer. Note, however, we mostly care about how productive you will be with strong coding agents. All of our engineering interviews allow coding agents (and we expect that most people who choose not to use coding agents will fail them).
People send applications here (for the US) or here (for the UK).
We strongly encourage you to include a note explaining with 1 paragraph why you would be a good fit and 1 paragraph why you want to work with us. Use simple blunt language. Bullet points are fine/good. Real reasons get much better results for this than corporate waffle. This will be read by a real person, and it will be a person who is made sad by jargon and empty phrases. You can use the ‘cover letter’ field of the form to upload this.
We then screen CVs and people’s notes. It really helps us if you highlight things in your CV that directly speak to the things we are looking for. It can be especially hard to assess mission alignment from CVs alone, so if you haven’t got job experience that legibly addresses ASI/AGI extreme risks it is really important to explain why you want to pivot to this.
After the CV screen, there is a screening interview where we quiz you on a few things that matter to us. This interview is short and deliberately not something that rewards loads of practice. There is no leetcode.
Then a fairly small number of candidates does a ‘remote onsite’ with ~4 interviews on a range of topics. All engineering interviews allow unlimited agentic assistance.
Finally, a very small number of candidates is invited to a set of team-matching interviews.
We’re working hard to cut the total wall-clock time of this process, but it usually does take at least a couple months from start-to-finish.
You can read our overall AGI Safety and Security Approach. We wrote it over a year ago, but it hasn’t changed very much in outline.
We expect an increasing fraction of our effort to go into implementing our research in practice, primarily via deep alignment and control. We expect our control measures in particular to become load-bearing for safety in the near future.
So far, most of our control research has been focused on CoT monitorability and preserving CoT transparency. We think we’ve picked a lot of the low hanging fruit in this area. Going forward, we plan to increase our focus on the setting where chain-of-thought is no longer monitorable. This could include alternative techniques for model forensics, extending interpretability approaches to latent architectures, improved blue team mitigations, and more realistic red teaming / stress testing.
We plan to continue our investment in research to align very powerful AI systems, such as in amplified oversight. Ultimately, alignment is the only potentially scalable approach that we know of, and we want to make sure we don’t lose sight of that goal.
To be clear, this is not the only thing we do, or even the majority. A lot of our work is about designing safe AI systems. The interesting claim here is that we do this kind of work at all, whereas our perception is that most other technical safety researchers don’t do this kind of work, especially those on AI company safety teams. ↩︎
Note that this doesn’t mean a focus on superintelligence. A more typical target would be AI systems at a roughly human level of “raw intelligence”, that dramatically accelerate progress via the other advantages of AI systems (e.g. speed). Honeypot evaluations is a good example of work targeting these kinds of systems: we don’t expect honeypot evaluations to matter much for superintelligence, nor for current systems, but it is plausible they will matter in between. ↩︎
We don’t have quite as much flexibility on this as we used to, since we’ve taken on more ongoing responsibilities as part of the midgame. Nonetheless it is still our main organizing principle for hiring. ↩︎