After talking to dozens of EA developers, here are some common things they want, and some suggestions of mine.
A clear understanding of when to apply
Many EAs are full of impostor syndrome which prevents them from applying. I recommend having a clear bar such as Anthropic’s “If you think you could write a substantial pull request for a [library], then major AI safety labs want to interview you today”.
Feedback if rejected
Many EAs, if rejected, will go and learn something that is unrelated to the reason they were rejected. As a community, I think it would be better if we’d give applicants some kind of feedback.
Specifically if you reject someone’s CV but you would accept it if they had a few extra side projects: I recommend telling them about that. It seems like many developers don’t put all their relevant non-professional background in their CV.
When can candidates re-apply, if at all?
I recommend writing this explicitly.
Mentorship
This is big, though probably biased, since it’s based on people who contacted me asking for mentorship.
Anyway, I expect something like this to go a long way:
“Our developer, [name], who has such-and-such experience, will sit with you for 2 hours per week which you can use to ask them questions about your work and improve. For example, they’ll review your code or help you investigate a complicated problem”
I often hear about EAs working in a “team” by themselves, with zero mentorship. 1 hour per week will go a long way, and 2 would be, I expect, amazing.
I am guessing that many orgs already offer something like this but just don’t advertise it.
EA developers care a lot about their personal growth, and I recommend showing off with anything you’re doing to support this.
No cover letter
EAs sometimes spend hours writing each cover letter, not only for your org, but for all of them.
I recommend asking for ONLY a CV, without even filling in a form. I think that would be attractive, and good for us as a community, since it will give the developers more time to do useful things, including applying to more EA orgs.
Impact
Signing Founder’s Pledge often matters too.
EA Culture
EAs sometimes tell me they had an unusually good bond/vibe/something with other EAs.
Here's my attempt at giving advice on this [filtered by “I don’t want to help orgs fake a good culture if it is not there”] :
- Don’t pretend like you don’t have flaws. Many people in our community prefer honesty and transparency. Don't you?
- If the candidate is better off (for themselves / for the world) working somewhere else, consider sharing that thought.
- Run your interview process well. For example, get back to candidates quickly.
Flexibility in interviews
Sometimes EAs tell me “I don’t know leet code, I can practice it, but is it worth delaying all my interviews for weeks/months?”
Other EAs get extremely stressed during live coding interviews.
Other EAs don’t like long take-home tasks and hardly have time for them.
It is pretty common for developers to have some kind of preference or aversion like that. (Did one of these options seem aversive to you?)
My current-best recommendation (from a startup that is really good at hiring) is to ask the candidate what they prefer.
I don’t have a cheap solution here, maybe someone in the comments will.
Say in advance what you ask about
Some candidates will want to prepare for your interview specifically.
I recommend writing something like “we ask leet code questions + some theory about React”, or whatever it is you ask. Unless it’s a surprise on purpose.
Bonus: Add links to study materials, especially if you're happy hiring unexperienced developers.
Remote work concerns
Some people are concerned about the social aspect of this. I recommend at least addressing this concern explicitly.
An example from Wave, which I recommend they write publicly if they didn't: "you might get a lot of what you're looking for in social connection from our retreats (every couple of months you see teammates for a fairly intense week)".
Or maybe write: “If remote work is the bottleneck, please apply anyway, tell us this is on your mind, and let’s talk”.
Or whatever is true for you.
I probably forgot something, so ask your candidates!
Is your bottle neck "people end up not signing"?
Consider something like “would you share why you didn’t sign with us? I am hoping you’ll tell me about something that is maybe-obvious for you but a blind spot for me, something that is maybe affecting our other candidates too”.
Is your bottle neck "people don't apply"?
This is the most common problem for EA orgs, as far as I know.
Consider making it very low friction to tell you why they didn’t apply, like an anonymous Google Form with only one field. My prediction is that most people will say “unclear if I’m qualified” or “unclear how much I’ll learn”, but maybe you’ll discover something else!
Check out the comments
I hope some developers will write what things they personally care about, or things they hope EA orgs would know.
I'll also take my own advice: Here's an anonymous form to send me anything, including a response you'd like me to post here anonymously for you. DMs also work.
I hope this helps!
As someone who's been reading & thinking about hiring a lot lately, I agree with quite a few things here. For example, I agree that providing a clear understanding of when to apply, emphasising mentorship & culture, tackling the remote-work issue head on, and being as straight with candidates as possible about the role, organisation, and application process, all seem good.
However, there are also things that feel like mistakes, some of them quite significant. (I'm open to being persuaded I'm wrong about most of these, especially since this could represent a significant improvement in my group's hiring practices.)
As I've written elsewhere recently, giving thorough feedback to candidates is very expensive, and frequently isn't the best use of current staff's time. I'm in favour of at least giving some feedback, but I'm currently weakly opposed to any strong cultural expectation of in-depth feedback.
I agree that it's often a good idea to skip the cover letter, which mainly tests rhetorical ability rather than ability to do the job. I also agree that application forms should be kept reasonably short. But only asking for a CV doesn't seem great to me, for two reasons. Firstly, CVs are typically very hard to blind well for unbiased application review. Secondly, there's a variety of other critical info I need about candidates, and a Google Form or similar is typically the most efficient way (for both us and the candidates) to get that information[1].
Insofar as a longer application form allows for less reliance on interviewing, I think adding more stuff to the application form will often be a good trade-off.
This currently seems like quite a bad idea to me, for two important reasons.
Firstly, some assessment methods are straight-up better at predicting job performance than others, and we have evidence of which ones those are – we shouldn't let candidates choose worse ones. EA orgs don't put a lot of emphasis on take-home tasks because we enjoy them, we do it because they are better than the alternative for the thing we are trying to do[2].
Secondly, comparability of assessment is critical to comparing candidates fairly. Letting different candidates choose different assessment methods seems like it would make that impossible.
I am a strong proponent of paying applicants for their time, and otherwise being respectful of their time and needs. But I think we should use the assessment methods we have evidence for, and take a lot of care to make sure we assess every candidate as identically as possible, not allow applicants to pick and choose.
I could potentially be persuaded that a two-step process, with an initial very short application form followed by a longer one for credible applicants, could be a decent workaround.
(And because a lot of us are copying OpenPhil.)
Giving thorough feedback is expensive:
How about giving feedback such as "the main reason is.."
Or a similar short sentence.
The main thing I am trying to avoid is feedback that will lead the candidate to work for 2 extra years before they reapply if they don't have to, specifically sentences like "you need more experience". Anything more specific than that would be good, I think
Perhaps to make it even cheaper for you:
Only give this one sentence feedback to candidates who ask for it (may I ask how many ask?)
What do you think?
[happy to get your pushback]
Yeah, if we're talking a shortish paragraph given to candidates who ask for it, I think that's fine. I think I'd be fine with that as a norm.
I am a software engineer who is considering applying for EA-aligned roles as a career move in the not-too-distant future (Still deciding between going for AI safety or just trying to do a similar type of SWE job I already do, but in an effective org) and the thing I found most surprising in this article was:
Is your bottle neck "people don't apply"?
This is the most common problem for EA orgs, as far as I know.
From the developer side, I read articles like this one (https://forum.effectivealtruism.org/posts/jmbP9rwXncfa32seH/after-one-year-of-applying-for-ea-jobs-it-is-really-really) and my conclusion was "Despite being well above average as an engineer according to objective career metrics like titles over time and compensation, as someone not at a FAANG level, I probably won't meet the bar to get hired at an EA organisation." This may be one reason why EA orgs say "If in doubt, apply", but it's still a bit daunting.
I'd be interested to know if that info (from 2019) still applies, since I also saw this (https://forum.effectivealtruism.org/posts/CdYniXZ53dyPupRiY/is-it-no-longer-hard-to-get-a-direct-work-job) but the comments muddy this a lot and make it uncertain as to how accurate this is.
I think this is the most useful part to try to get rid of.
If someone (the EA orgs / the devs / someone) could make it way less daunting for devs to apply (even if they'd be rejected), I think that would be hugely valuable.
Do you agree?
Any idea how to approach that problem (even if no immediate solutions come to mind, how could they be found?)
I think the daunting part is the "being rejected" part, more than any actual difficulty in applications. I don't think making the process 30 seconds instead of five minutes would have made me any more likely to pull the trigger. I've sent in a few applications anyway because I wanted to check my current ability against the needs of the organisations, and the process itself was pretty fast.
This may not be generalisable across other people (and I'm not the kind of person who really needs it, since I did send in the applications anyway), but I see two parts to rejection.
1) The social aspect of "Oh no, rejection by a human being" which is unreasonably strong for most people. (There's a reason why asking someone out is terrifying for a lot of people) This can also manifest as "I don't want to waste someone's time if I'm way below the standard".
2) The psychological aspect of failing at something.
Of this, I suspect 1 is stronger than 2 for most individuals. A potential solution to this might be some sort of automated screen as a first round, such that individuals who fail it never actually get rejected by a human, and individuals who succeed now have enough buy-in and signal of their suitability to be more likely to progress to the next step. At the very least, I can imagine some people would say "Well, I'm sure I'm not <org> material, but it would be nice to take the test and see where I stand!" but they wouldn't want to waste an actual human's time by sending in an application in similar circumstances. And some of those people might be closer to <org> material than they think.
For this to work, you would need:
* A very clear idea of what the standard is
* Encouragement that if someone meets this standard, you want them to apply
* A way for candidates to disqualify themselves without ever talking to a human.
Anthropic's call to action had at least two and a half of these. The standard wasn't 100% objective in the sense that I can unambiguously pass/fail it right now, but it's pretty damn close.
(I wonder if this could work with grants too, with questions with clear acceptance criteria and encouragement that if someone meets these acceptance criteria, they have met the threshold that they should apply for a grant)
Of course, this comes with its own difficulties - an official public automated test is easier to game, whereas an objective standard like "If you can complete 3 of 4 problems in a LeetCode competition within the time limit, talk to us" is less authoritative and thus less effective. So I'm not sure what the best way to go about doing this is, or if it would be effective across a bunch of not-me people.
Thank you for writing this! I appreciate the specific details and clarity. Although I'm not a Developer nor an employer of Developers, I do interact with a lot of Developers. Based on my experience, I think good Developers have a low tolerance for ambiguity -- the code can't "sort of" work and "maybe meet some" requirements. The code needs to work for specific use cases.
Likewise, honesty, transparency and clarity on behalf of potential employers is probably really helpful to Developers in understanding fit (or lack thereof).
Perhaps I'm completely wrong. I'm curious what Developers themselves think. Are there wildly chaotic, high tolerance for ambiguity Developers? Do they thrive in opaque surroundings?
It is VERY COMMON for developers to hear ambiguous sentences from employers, such as:
And for the developers to believe this, sign with that employer, and then to be (I don't have the word.. shaken? terrified?) of discovering the reality of the company.
So to your question, I am sad to say that these ambiguous "sales" sentences seem to work, commonly once per developer.
To the employers, I will say: The next step is for the developer to be sad, to pretend that everything is ok, and then you have whatever problems you get when you hire someone who has serious second thoughts about being there. It is better to be transparent from the beginning! (I think!)
To the employees: I am happy to help you find questions that will give you unambiguous information about whether this work place fits what you are looking for or not (assuming the employer is not willing to very blatantly lie, which most won't, I think)
Here's how I would reply if I wasn't the author:
Here are some things I personally care about and ask about:
What tasks will I do?
Saying I'm a "senior full stack engineer" (or whatever) doesn't capture my responsibilities well.
I'd like to hear example tasks that I could do tomorrow if I was already an employee. And also example tasks that I surely would not do. (Are those examples going to be "DBA" or "finance"?)
The format of the answer I'm looking for is not "here is a cool project that lets users inject their own code", but rather, "we have a bug that allows XSS, this needs to be solved". This is because employers often present a too shiny reality that employees discover only after signing. This has just happened to a close friend of mine, and is not rare.
Autonomy vs micromanagement
Everybody claims they hate micromanagement, including people who micromanage, or at least this is my (painful) experience.
I am not sure if I want to talk about how I check this, but I have some idea
Culture test: Argue about something
I really care about being able to disagree and have it still a "fun" conversation. People who interview me will often hear me say that, followed by "so I want to try arguing with you about something and check how it goes. Do you have a guess about something we might disagree about?"
I know, this is very Yonatan of me, but this is part of trying to understand if there's a culture fit.
Influence on Product decisions?
I really like having some non-zero influence on the Product, rather than accepting everything "as is". This is great for some companies and bad for others.
The biggest mistake I see companies doing is, for example, pretending like their Product situation is great and has no significant uncertainty, while in reality, they are somewhat struggling to get product market fit. The latter would extra attract me! So why pretend to be the former?
This is a more general point:
Tell the employees the real situation. Don't hire people who imagine they are joining a different company, and will only discover that 3 months in. (I think employers are unaware of how common this is. If you're an employer, are you sure this isn't happening in your company?)
Would you consider writing more about this, as you feel comfortable?
I think "micromanagement" could be really unevenly distributed among managers, and the reasons counterintuitive, so talking about it seems useful.
May I ask - are you asking because you hope that I'll answer with something that will make managers micromanage less?
If so, I don't think I'm skilled enough at writing to change someone's management style via a post
I'm open to talk one-on-one though
I just wanted to hear your perspective, I don't think it has to change managers minds. It might inform people here.
Anonymous feedback from a developer (bold is mine, read only the bold if you want a TLDR):
Thank you, whoever you are that filled out the form. :)