How do you know if you’ll like AI safety work? What’s the day-to-day work like? What are the best parts of the job? What are the worst?
To better answer these questions, we talked to ten AI safety researchers in a variety of organizations, roles, and subfields. If you’re interested in getting into AI safety research, we hope this helps you be better informed about what pursuing a career in the field might entail.
The first section is about what people do day-to-day and the second section describes each person’s favorite and least favorite aspects of the job.
Of note, the people we talked with are not a random sample of AI safety researchers, and it is also important to consider the effects of survivorship bias. However, we still think it's useful and informative to hear about their day-to-day lives and what they love and hate about their jobs.
Also, these interviews were done about a year ago, so may no longer represent what the researchers are currently doing.
Reminder that you can listen to LessWrong and EA Forum posts like this on your podcast player using the Nonlinear Library.
This post is part of a project I’ve been working on at Nonlinear. You can see the first part of the project here where I explain the different ways people got into the field.
John describes a few different categories of days.
Over the past month he’s started working with David Lorell. David’s a more active version of the programmer's "rubber duck". As John’s thinking through the math on a whiteboard, he’ll explain to David what's going on. David will ask for clarifications, examples, how things tie into the bigger picture, why did/didn't X work, etc.
John estimates that this has increased his productivity at theoretical work by a factor somewhere between 2 and 5.
Ondrej starts the day by cycling to the office. He has breakfast there and tries to spend as much time as possible at a whiteboard away from his computer. He tries to get into a deep-thinking mindset, where there aren’t all the answers easily available. Ideally, mornings are completely free of meetings and reserved for this deep-thinking work.
Deep thinking involves a lot of zooming in and out, working on sub-goals while periodically zooming out to check on the higher-level goal every half hour. He switches between trying to make progress and reflecting on how this is actually going. This is to avoid getting derailed on something unproductive but cognitively demanding.
Once an idea is mostly formed, he’ll try to implement things in code. Sometimes seeing things in action can make you see new things you wouldn’t get from just the theory. But he also says that it’s important to not get caught in the trap of writing code, which can feel fun and feel productive even when it isn’t that useful.
Scott talked about a few different categories of day-to-day work:
An example of a typical day might look like this: he’ll start work in the morning by reading papers because this is his best time for getting into deep work. This is followed by a research meeting with some collaborators and answering some emails. After that, he has the CHAI weekly lab meeting, where someone presents their research. After this he might spend a few hours coding on an existing project, followed by some admin work.
Alex has historically specialized in whiteboard-centric math and theory work but has pivoted to empirical and mentoring work (coding, experiment design, frontend, management).
He spends most days focused on specific questions. For example, by what processes might a diamond-motivated AI improve itself? What precautions might it take, given such-and-such resources?
He’ll occasionally zoom out to check that he's still focusing on questions he expects to most increase the probability of alignment success.
On empirical research days, he spends about six hours coding, one reading, and one to two in conversations. On theory days, it's rather evenly mixed between reading, writing, and thinking. He will periodically spend a few days to weeks communicating large bundles of ideas and results, whether in blog post or paper format.
OpenAI, where William works, has three days a week where there are meetings and two days a week where they try to avoid meetings. William’s day starts by getting into the office, checking Slack to see how various projects are going, and leaving comments if he has useful ideas for any of them. If it’s a meeting day, he will usually have 1 or 2 meetings with people working on a project and sometimes other people who are interested in talking about the higher-level ideas. There will be discussions about what experiments to run next, or whether any of the code needs to be refactored.
There are two types of experiments that he works on:
Ethan describes his projects as having three phases: brainstorming, implementation, and writing up. The brainstorming phase usually lasts about a month and is all about working out what to do next. This involves a lot of reading, taking notes, and talking with people. Each week he’ll have a meeting with his advisor about ideas for directions that seem promising to pursue and get feedback.
Once they’ve settled on a project, he’ll move on to the ‘implementation’ phase, which starts with figuring out how to get things to work in practice. Then it's a matter of putting the ideas into code and running experiments on a GPU cluster, getting feedback from these experiments, and deciding what to run next. During this process, he’ll have weekly meetings with his advisor to talk about which research directions he should continue to pursue. This implementation phase takes around one to six months, ending when he either gets something to work or decides to shift directions.
Once something works, he’ll take about a month to run the final experiments, write it up in a paper, put it on arXiv, and submit it to a conference.
Justin runs Convergence, an organization which does work in AI and x-risk strategy. A normal week usually involves:
Days are usually devoted to one activity rather than splitting them up too much, but sometimes this isn’t possible when working with other people, especially in different time zones. Usually he spends the start of the day doing deep work and then has calls later in the day.
Stephen usually has at least a couple of things to work on at once, so that when one task gets boring, he can switch to another. He usually works from the offices at MIT, MAIA, and HAIST, bouncing between various tasks including, for example:
As well as the standard work, Stephen has the habit of reading and taking notes on at least one paper a day. This is to explore the literature more widely, so he tries to choose papers that aren’t too related to what he would have read anyway. You can read more about his daily routine here.
At DeepMind the work can be quite varied and things can change a lot in 6 months. Ramana usually works between 10 am - 6 pm and tries not to think too much about work outside of this; although this isn’t always possible. With creative work, you can’t always say, “I’m going to be working now, and I’m not going to be working now”. Sometimes you just have to follow your mood.
About half of Ramana’swork time is spent on tasks that can be done alone or by closely collaborating with someone else. These include:
The other half of the time is spent with larger groups, for example:
N.B.: this interview was done in early 2022 before Dan had finished his PhD.
Dan has an exceptional academic and publication record, and as such (as a PhD student) now spends a lot of his time managing other people. He doesn’t spend very much time coding himself; instead, he manages other people, which he’s been doing since the third year of his undergraduate degree. This involves a lot of meetings with people and thinking about ideas for projects.
Part of his management work involves applying some pressure and motivating his colleagues to make sure that projects actually get done, especially applying “start-up torque” to get projects started in the first place.
We asked people what their favorite and least favorite parts of the day-to-day work were. If you think the best bits sound great and you could handle the not-so-good parts, then you might be a great fit for AI safety work.
If you liked this post, you might also like:
Thanks to Amber for editing this post. If you find writing/editing tedious or can never find the time to write, you can contract her to write or edit your EA posts here.
If anyone is looking for a way to start contributing to the field, it seems like one low-hanging fruit approach would be to:
(Great post btw!)
*If you're one of the researchers mentioned in the post and you'd prefer people didn't reach out to you with offers like this, that's totally cool - feel free to leave a quick reply saying so.
This is great! Thanks for doing this.Would you be able to add people's titles and affiliations for some context? Possibly also links to their websites, LinkedIn or similar.