After Interviewing 18 SPAR Mentee Applicants, I Stopped Looking for the “Strongest” Candidate

I am a first-time mentor for the Fall 2026 SPAR cohort, a remote AI-safety research fellowship that pairs mentees with mentors working on AI-safety related projects on reducing x-risk or other related risks.

During prep, one piece of advice I received was to interview far more people than I normally would and treat the process itself as a form of exploration. The stated goal was simply to get to know the actual person through real-time conversation and compare that with how they came across on paper.

So I interviewed 18 people across three or four mornings, expecting that speaking to more candidates would simply give me more info, make it easier to identify the “strongest” ones, and help me decide who to recruit as mentees.

But the more people I spoke to, the original mentee-selection problem started to fall apart. Like, I was no longer sure what the “strongest” candidate even meant.

Candidates who looked similar on application could be very different once I actually talked to them, while people I might have automatically rejected based on their application could turn out to be much more interesting than I had ever expected.

After enough interviews, I started to notice that the candidates could be roughly clustered into three fairly distinct types, which, for lack of better names, here I will call them: YOLOs, Moonlighters, and Wildcards.

These differences were less about raw ability and more about where they were, how much of their life they had already organised around tackling AI safety problems, and what kind of support they actually needed to keep making progress.

Thinking about these three groups quickly changed how I approached the mentee-selection problem, and I found myself increasingly asking: “For which candidate can my particular mentorship create the most additional value?”

YOLOs

These people are already deeply committed to AI safety. Many have spent at least the past 6 months working on AI safety full-time, often leaving a full-time job with no stable source of income.

Their goal is usually to contribute to tackling some of the most important AI safety problems they deeply care about, while finding a practical and sustainable path to keep doing so over the mid term (~ 6 months) and long term (~ 12 months).

Many are already BlueDot course alumni or are otherwise connected to communities where it is relatively easy to find AI safety opportunities, collaborators or funding.

I suspect that it is mainly due to a strong sense of commitment and urgency about the AI safety problems they care about. Plus or minus financial runways, they are be highly agentic and opportunistic.¹

They actively do things. They are relentlessly resourceful. They can execute things fairly independently and quickly without much hand-holding. They actively seek out projects, collaborators, fellowships, and other opportunities that help them grow and contribute more effectively to the difficult AI safety problems they care about.

I think their biggest advantage is the ability to devote their full time, attention, and focus to tackling the AI safety problems they care deeply about, independently and without needing external permission.

By being able to thinking and working on important AI safety problems full-time, they gain unusually deep exposure to the problems themselves, the people working on them, the institutions supporting that work, and the stakeholders affected by those problems.

Each project write-up, application, produced artefact, collaboration and conversation gives them another chance to explore, learn, and make progress toward tackling the AI safety problems they care about.

Often very quickly, they will be able to discover and develop their own flywheel of exploration and exploitation on tackling their target set of AI safety problems, at a pace that differs person to person.

I think this flywheel applies regardless of which talent category (i.e., iterator vs connector vs amplifier) you place yourself in.

My reasoning is as follows:

• Suppose you already deeply care about a particular problem in AI safety and have convinced yourself to bet your (entire) career to work on it. The remaining question is how to make (and measure) progress on it.

• One of the fastest ways to make any progress is to execute quickly, get your work out into the world, find allies and collaborators, and figure out how to get other relevant stakeholders to care about and engage with what you are doing.

• This is not easy, and I often jokingly refer to this process as simply “banging your head against the problem” where you just repeatedly trying things out, learning from what happened to you and others (akin to doing mental updates), and continue pushing things forward until it clicks.

The AI safety problems we face today are difficult and poorly understood, with so many unknown unknowns. Any detailed plans or prior analysis depend on assumptions can fall apart very easily once they confront reality, with relatively short expiry dates if left unchecked and unrevised, especially given the pace of AI progress and how quickly our understanding of AI systems’ capabilities and propensities is evolving.

There is genuine uncertainty about how we should respond to this, and it has sparked substantial debate within the community. For instance, I find Richard Ngo’s two recent pieces on the history and trajectory of AI alignment and the risks of pragmatic, empirical approaches particularly thought-provoking.

My hunch is that, as an individual, one of the most effective ways to make progress on problems this uncertain is to shorten the feedback loop.

So you should just try out different things, expose your ideas and work to real-world feedback, learn (and do mental updates) from what happens, all in quick succession cycles.

When there is so much uncertainty where the stakes and risks are only getting higher and higher, the default of doing nothing and waiting is itself very risky.

Fast (empirical) feedback, gathered through repeated short cycles of iteration, gives you information that you could not have obtained otherwise.²

Adopting this mindset while YOLO-ing can really help you avoid many common pitfalls in pursuing a high-impact career.

But feedback itself can be very noisy, so you need to be selective about which feedback to take seriously and whose judgment to trust³.

One failure mode I notice in myself and others is becoming very good at execution while still struggling with prioritisation⁴. Moving quickly does not automatically tell you what is worth moving quickly on.

Personally, I found it useful to treat my activities, or set of inputs, as a sequence of experiments for stress-testing my theory of change in tackling AI safety problems, since it can be very hard to predict, and therefore directly affect outcomes for ai safety problems this uncertain, though I know others who might disagree (heavily).

This can be as simple as writing things down and checking the logical coherence of your argument, running empirical experiments and interpreting or red-teaming the results to expose limitations, or talking to other people and debating your ideas. In each case, you are iterating by exposing your assumptions to feedback.

Whatever you are doing to shed light on a problem or address it, this mindset seems to transfer quite well. You keep documenting and updating your thought process, while designing each step so that you can meaningfully attribute the outcome and learn from it.

The goal is to treat the process itself as a sequence of experiments: expose your assumptions, observe what happens, and generate outcomes that have a moderate to high probability of meaningfully changing what you believe or what you do next, as to address the relevant AI safety problems that you ultimately care deeply about.

All these then can be boiled down to taste (or research taste) and thus why I think YOLOs can benefit disproportionately from close, high-touch mentorship and sustained collaboration with like-minded people in tight-knitted groups.

Once execution is no longer the bottleneck, the next challenge is figuring out what is actually worth executing on, or which instrumental goals to set, in pursuit of the north-star AI safety problems you care about.

This is where experienced mentors in your area of AI safety, along with close collaborators, can substantially improve the quality of your feedback loop.

They can help with prioritisation, challenge weak assumptions, provide context that would otherwise take a long time to acquire independently, and point out when you are optimizing for the wrong proxy or pursuing a direction that is unlikely to matter.

Just as importantly, working closely with other minds lets you observe how they reason about problems, make trade-offs, and decide what to ignore.

Over time, this kind of sustained interaction can help you develop better judgment about which problems are worth repeatedly “banging your head against,” which feedback to take seriously, and when to persist, pivot, or stop.

Moonlighters

These are people who to work on AI safety problems part-time alongside a full-time job or commitment that is not directly relevant to tackling those problems, sometimes sustaining this arrangement for years.

They often become interested in AI safety through their existing work or growing concern about developments in AI, but are not yet ready or able to transition full-time, often because of constraints, such as financial limitations, or limited awareness of or access to support in their geographical region.

Many moonlighters also come into AI safety with substantial experience from industry, government, business, or other established fields. They can bring institutional knowledge, operational judgment, and solutions that have already been developed and tested elsewhere over many years, which may be especially valuable in a field with relatively few people who have substantial experience outside academia or AI safety itself.

That said, I am skeptical that moonlighting is a particularly good long-term setup for doing highly impactful AI-safety work, especially for work that requires rapidly building deep context, iterating frequently, and staying closely connected to relevant stakeholders⁵.

Roughly, my reasoning is as follows:

• AI systems are just another beast, where many difficult, poorly understood, and very concerning new problems keep popping up. Assumptions from existing established fields simply do not map cleanly, and many of the assumptions and problem contexts are very bespoke to AI systems themselves, requiring people to build up substantial context while continuously red-teaming, testing, and iterating.

• Compared with YOLOs, moonlighters face an inherent disadvantage. Their jobs leave them with much less time to keep up with AI developments, build deep context of the AI safety problems, test their assumptions, and continually refine their theory of change.

• They also has less time to identify their comparative advantage: the distinctive skills, perspectives, or approaches that could make their contribution to AI-safety problems especially valuable, and to work out where those strengths can be most useful.

• Moonlighters are also more likely to operate in relative isolation from the most active parts of the AI-safety ecosystem, where information, feedback, collaborators, and opportunities circulate quickly. This can make it harder to develop good judgment about which problems are genuinely important, neglected, or decision-relevant.

• As a result, their projects may skew more toward replications, extensions, or clearly scoped pieces of existing work, where the problem and methodology are already relatively well defined. These can still be directly valuable, while also helping them build skills, credibility, context, and connections.

• The deeper problem is that limited time also makes it harder to connect a project to a clear pathway to impact: identifying who might actually use the work, understanding what they need, testing whether the underlying assumptions are right, and iterating around their feedback.

• Moonlighters may therefore spend more of their time building their portfolio, fixing problems in existing work, or gradually positioning themselves in the field, rather than being ready to go “off to the races” from day-1 with a clearer, more well-defined, and well-red-teamed theory of change that can meaningfully address the north-star AI safety problems that (different) communities care about.

The size of this disadvantage depends heavily on the type of work and the relevant AI safety problems that they are aiming at.

Many important and difficult AI-safety problems are especially sensitive to rapidly changing and emerging model capabilities, often with short policy windows, while others, often the more neglected ones, are more decoupled from AI progress and move much more slowly⁶.

For the former, working only part-time can make it substantially harder to stay close enough to the frontier to identify important problems as they emerge and act on them while they are still relevant.

My take for moonlighters is to quickly consult people in the AI-safety ecosystem and aggressively look for ways to pivot into working full-time on AI-safety problems, unless they fall into the mentioned exceptions⁵ and are already making an impact on AI safety problems, or are well positioned to do so.

This could mean applying for paid fellowships, seeking career-transition grants, taking a sabbatical or career break where feasible, or joining short intensive programmes that provide concentrated time, context, and access to people already working in the field.

Such info can be easily accessed through aisafety.com

Wildcards

These are usually people who are still in college or university, and I think they are the highest-variance group.

At one end, you have students who have only recently heard about AI safety and are applying because the opportunity sounds “interesting and potentially useful.” At the other, you have students already running AI-safety initiatives at their universities, organising reading groups, working through the ARENA curriculum, replicating papers, or doing their own AI-safety projects.

Although they have academic commitments, they are young and have relatively few to none fixed, long-term obligations. This gives them substantial freedom and flexibility over how they spend their time and where they direct their focus.

Their interests, priorities, and career trajectories can shift dramatically, often within a very short period. Exploration is often the priority where they try many things, quickly discover what does or does not fit their interests, goals, and values, and can disengage just as quickly when something no longer seems worthwhile. This flexibility can easily be a double-edged sword. Someone in this group can become substantially more interested in AI safety within months, but they can also move away from it just as quickly.

I personally find interviews with this group particularly valuable because you get to hear their intellectual journey, what they have actually done and read, why they applied, how they think about AI safety, and whether they have seriously considered how they might contribute.

This helped me to assess how much they could benefit from mentorship⁷ and provides some weak indication on how capable they already are, what useful work they can produce now, and whether there is good reason to expect them to keep working on the relevant AI safety problems afterwards the programme.

My take for Wildcards is to explore aggressively, but make that exploration produce real evidence that you have actually spent time “banging your head against” concrete AI-safety problems.

This includes reading broadly, talking to people working on different problems, leveraging your student status to ask for help, and trying small projects that force you to build, investigate, replicate, write, or otherwise contribute something useful to problems that other members of the AI-safety community also find valuable.

The goal is to quickly reduce uncertainty about three things⁸:

1. Which AI-safety problems you actually deeply care about
2. Where your comparative advantage (niche) might lie
3. Whether you can produce work that other people find useful

As with YOLOs, mentors and close collaborators are especially valuable here because they can compress a lot of context-building and help you spend more time “banging your head against” problems that actually matter. So you don’t have to spend time on ones that are already answered, poorly framed, or disconnected from what relevant stakeholders need to tackle AI-safety problems.

Also as a general point that applies broadly, avoid over-optimising for credentials.

Courses, reading groups, and fellowship programmes are only as useful as the extent to which they help resolve core uncertainties or thinking blocks, or, often more importantly, provide access to resources and networks of people that help you move forward and make progress on addressing difficult AI-safety problems.

I think people value it much more when you can clearly articulate why you are doing what you are doing, what you chose not to do and why, which AI-safety problems you are focusing on, what progress you have made independently, and how you are actively seeking and using feedback as well as community support to advance the state of your work to address the difficult AI safety problems that is troubling you.

So, what was I actually optimising for?

When I first started shortlisting candidates, I was heavily optimising for what I thought of as counterfactual impact: how much difference could my mentorship make to where this person ends up when it comes to contributing to AI safety problems⁹?

Under that, I put somewhat heavier weights on Wildcards than the other two categories.

Well, my intuition was that many YOLOs already faced relatively little friction in finding collaborators, funding, projects, or other opportunities, and would probably find ways to make themselves useful with or without my support. Moonlighters seemed variable.

Wildcards, meanwhile, often had much less settled trajectories, so the counterfactual upside could be substantial.

Someone who starts with little more than intellectual curiosity about a particular AI-safety problem might, with the right exposure, mentorship, and career guidance, quickly become a Moonlighter or even a YOLO if they come to care enough about the problem to re-orient their career around it.

I would admit that this may itself be an instance of biased reasoning, a relatively new model-behaviour phenotype that the AI safety community has only recently started investigating. I may be somewhat anchored by my own experience as well.

Like, I only graduated around two years ago, from a non-CS and non-theoretical physics/math background, and my own transition into AI safety happened surprisingly quickly. I think this was largely because I put a lot of time into thinking deeply about AI safety problems and, increasingly, relentlessly executing and writing up technical AI safety projects.

I started BlueDot’s AGI Strategy course in mid-January 2026 and only barely got into ML4G from the waiting list, which is quite funny looking back now.

Looking back, both ended up being pivotal. BlueDot gave me access to a Slack community where people shared everything from AI safety news and opportunities to events and feedback on work and drafts. ML4G introduced me to people in the field whom I could talk to, learn from, get feedback from, become friends with, and who helped me understand where I stood then and how far I have come since.

I sometimes wonder how much faster that transition could have happened if, right at the beginning, I had been paired with an experienced AI-safety mentor who could provide close, high-touch mentorship and help me find work that immediately made good use of my existing strengths and interests.

So it is probably unsurprising that, when I first thought about counterfactual impact as a mentor, I was especially drawn toward candidates for whom I could imagine creating a similarly large shift in trajectory.

That pushed me to weight Wildcards more heavily than I suspect most other mentors would. But as a first-time mentor, I also had very little confidence in that decision rule. I tend to write down problems I am struggling with, so I drafted an early version of this post, asked around, and received useful feedback that substantially changed how I thought about the selection problem.

One thing I am pushed back on was that I was implicitly treating “YOLOs already likely to succeed” as evidence that mentorship had relatively little additional value.

Small improvements to someone who is already unusually capable can still compound into large downstream effects, especially if they continue doing important work in AI safety for years.

I was also underweighting how informative demonstrated capability and commitment already are. If someone has repeatedly shown that they can independently find problems, execute projects, seek feedback, and keep going under uncertainty, that is useful evidence about what they are likely to be able to do during the programme.

They also pointed out that selecting too strongly against people who have already demonstrated those traits could create some fairly strange incentives. You do not really want future applicants to feel that being too capable, too productive, or too visibly committed somehow makes them less attractive because mentors assume they will succeed anyway.

This also made me reconsider YOLOs and Moonlighters. I had initially viewed their relative independence as reducing the counterfactual value of mentoring them, but that was a pretty naive thought.

Someone who already appears strong and capable of independent execution may need less help with basic execution, while still benefiting substantially from something much scarcer: taste, prioritisation, judgment, technical context, network access, or repeated detailed, high-quality feedback from someone who has already spent much more time reading, thinking, and working on the same AI safety problems.

Neel Nanda’s MATS stream is one example of this kind of mental model. His mentees may already be very capable of executing experiments independently. The additional value of the mentorship can come from helping them identify better problems, distinguish promising directions from dead ends, and gradually develop stronger research-taste of their own, within the realms of MechInterp. In that case, the mentee is already strong, yet Neel’s mentorship can still meaningfully steepen their trajectory.

I was also underweighting Moonlighters, although for a somewhat different reason. I was paying a lot of attention to the AI-safety context they had not yet accumulated, while giving too little weight to the context they may already have built elsewhere.

Someone who has spent years in industry, government, business, operations, or another established field can bring judgment and institutional knowledge that are relatively scarce in a young field. They may have already seen organisational problems, incentive failures, implementation constraints, or solutions play out repeatedly in settings that many younger AI-safety researchers simply have not encountered yet.

In those cases, the value of mentorship may be much less about training someone up from scratch and much more about helping them connect an already valuable body of experience to the right AI-safety problems and mindset that helps them prepare and ready for upcoming opportunities to transition into working full-time in AI safety.

So, after going back and forth on this, I found it useful to separate three things that I had initially bundled together:

1. Current capability: How capable is this person already of producing useful work?
2. Mentorship leverage: Is there something I can specifically offer that is likely to make them substantially better positioned?
3. Fit and likely trajectory: Is there a strong match between the problems they care about, the project, what I can offer, and where they are likely to take what they learn afterwards?

The distinction between the first two was especially useful for me. Someone can already be very strong while still having high mentorship leverage. Likewise, someone can be relatively underdeveloped while having either very high or very low mentorship leverage depending on whether the mentor actually has something useful to offer them.

That gives something roughly like this:

My original selection approach leaned disproportionately toward high-upside exploration. I was looking for people whose trajectories seemed especially changeable and therefore where the counterfactual effect of mentorship looked largest.

After talking with other people, I started taking selective acceleration much more seriously. The fact that someone is already strong does not mean the marginal value of helping them is small, and relatively small improvements to someone with unusually high future potential can still matter a lot.

I also became less dismissive of immediate contribution. Different mentors are trying to accomplish different things, and some genuinely care a lot about the question, “Who can contribute the most to my research right now?”

That seems perfectly reasonable when the project is technically difficult, the programme is short, or several candidates already look highly motivated, well matched, and likely to benefit. In those cases, demonstrated capability can naturally become the tie-breaker.

So for this particular round, where I roughly landed was to first look for mentorship leverage and fit. I wanted good reason to believe that I could actually offer something useful to the person, and that there was enough overlap between their interests, the project, and what I could provide for the mentorship to make sense.

Once several candidates cleared those bars, I became much more willing to use demonstrated capability as a tie-breaker.

I do not think this yields a clean decision rule, and I would expect the relative weighting to change substantially depending on the mentor, project, applicant pool, programme length, and what the mentor is actually able to offer.

Even for myself, I suspect I would learn more and weight these things differently, or perhaps discard this framework entirely, if I faced the same decision again.

That said, this kind of deliberation helped shed some light on how I should think about the question I found myself asking after those 18 interviews, even if I was probably still subject to biased reasoning, which is honestly very hard to fight against:

“For which candidate can my particular mentorship create the most additional value in tackling the relevant AI safety problem?”

At time of writing, I am still a first-time mentor, so I would be surprised if this ends up being the final version of how I think about the problem.

I suspect my next post on this topic will come only after I have mentored more of the people I selected, tested these assumptions against what actually happens, and gathered enough evidence, inevitably from small samples because mentorship is hard to scale (or maybe no-one has succeed yet ?), before making claims and writing about them that others might find them useful.

Special thanks to Sean Herrington and James Chua for extensive and valuable feedback on drafts of this article, and to Amirkhan Aidarkhan for repeatedly asking questions that exposed gaps in my thinking and ultimately shaped substantial parts of the article. Thanks also to Hilary Torn and Nikita Kezin for helpful comments and suggestions.