I recently saw two job posts, one for Giving What We Can and one for Effektiv Spenden. Both of them seemed to be based on this template (the 2nd one was confirmed to be created with Yonatan's advice), and I have to say, they were some of the best job posts I've ever seen. This should be the new standard!
I'm particularly a fan of:
Precise description of the interview stages
In-depth explanation of what the company does
In-depth explanation of which new features are planned and the candidate would be expected to work on
Saying which technical skills will be used, and which technical skills are similar enough to be helpful, rather than imposing a hard line
Yonatan helped us at Effektiv Spenden with this job ad and the hiring process in total. I think it really helped: - We had 45 applications, which is up from 13 in our previous hiring round. This is probably down to a number of things, like us being able to explicitly mention that we're funded by OP now and being more open to remote workers, but I believe the improved job ad also played a part, because: - 3 applicants, without me prompting them, told me that they really liked the job ad. The comments were roughly - "One of the best [job ads] I have seen" - "I think it's good you didn't put a specific number of years of experience on" - "it was helpful, in comparison to your previous job ad, that you mentioned a specific thing (do a PR within 2 weeks) of how I could judge whether I'd be a good fit"
[Do you have a work trial? This will be a deal breaker for many]
Based on your conversations with developers, do you have a rough guess at what % this is a deal breaker for?
I'm curious if this is typically specific to an in-person work trial, vs how much deal-breaking would be avoided by a remote trial, e.g. 3 days Sat-Mon.
do you have a rough guess at what % this is a deal breaker for?
It's less of "%" and more of "who will this intimidate".
Many of your top candidates will (1) currently be working somewhere, and (2) will look at many EA aligned jobs, and if many of them require a work trial then that could be a problem.
(I just hired someone who was working full time, and I assume if we required a work trial then he just wouldn't be able to do it without quitting)
Easy ways to make this better:
If you have flexibility (for example, whether the work trial is local or remote, or when it is, or something else), then say that in the job post.
It was common for me to hear that candidates didn't even apply because of something like that which is written as a strict requirement, and then for me to hear from an employer that they didn't really care about it.
If your candidates will feel comfortable talking to you and telling you about things like this, and then you can find a solution together - I imagine that would be great.
Also, some candidates will WANT a work trial to see how the job actually is. I asked for a work trial in my current job.
Also, CEA does work trials. You could ask them how it goes. (But they won't hear about people who didn't even apply, I guess)
This is the third in a sequence of posts taken from my recent report: Why Did Environmentalism Become Partisan?
Summary
Rising partisanship did not make environmentalism more popular or politically effective. Instead, it saw flat or falling overall public opinion, fewer major legislative achievements, and fluctuating executive actions.
Public Opinion...
This post presents the executive summary from Giving What We Can’s impact evaluation for 2025. At the end of this post we share links to more information, including the full report and...
This is a Draft Amnesty Day draft. That means it’s not polished, it’s probably not up to my standards, the ideas are not thought out, and I haven’t checked everything. I was explicitly encouraged to post something unfinished!
Commenting and feedback guidelines: I’m going with the default — please be nice. But constructive feedback is appreciated; please let me know what you think is wrong. Feedback on the structure of the argument is also appreciated.
TL;DR:
A job post template with sections that you can fill in.
Some might be obvious, like "local/remote" or "salary".
Some are less obvious, like "mentorship", "will you waste our time by applying".
Some are often hard for hiring managers to fill in, like "your role" and "your expected impact", so I added guidance on how I'd fill them in.
The sections were picked based on lots (100?) of conversations with EA developers looking for jobs, taking into account a lot of reasons I hear that candidates don't apply (which can often be fixed by just including some section).
Each section is explained, just ignore sections that seem wrong or not relevant (I hope nobody will trust me blindly (!)).
I plan to update this post as I learn more on how to write job posts.
If you prefer reading a post in this style which is not a template, consider:
This isn’t polished/ready, but I do think it’s a good starting point.
I am not an expert at hiring, I just spoke to a ton of candidates.
I expect a few of my suggestions (when originally posted) will be pointed out as bad ideas in the comments, so probably wait a bit for those comments before using this.
This was written in the context of hiring developers (but maybe useful for other professions, I guess)
The template starts below, copy it and fill in each section. I elaborate/explain in [square brackets]:
Post title: [org name] is hiring [role title]
[Candidates use the first lines to decide if this post is vaguely relevant to them and whether they want to keep reading. So keep this initial section very short, like a TL;DR]
[I don’t recommend posting an update about your org and writing there (hidden somewhere) that you’re hiring, because many potential candidates won’t click into an org update, they will click into hiring posts. So ideally the word “hiring” and the specific role(s) will be in the title]
[The Zzapp Malaria post seemed to help hiring and (almost) the only thing it did focused on hiring was the title. Titles matter!]
Role title
[Fullstack Developer / ML engineer / Product manager]
[Common mistake: Writing “multiple roles”: It’s hard for candidates to understand quickly if this post is relevant for them or not]
[Probably a mistake: Writing “senior”, here's why]
Local or remote?
Local [country + town] / Remote / both
[Common mistake: Writing “Local (TOWN_NAME)” and then hiding the “remote” somewhere in a long paragraph. Candidates who can only work remotely will see the "Local" and just exit your post, assuming it is not relevant for them]
[Almost all candidates will have some preference about local/remote, so having a clear section they can jump to will be very convenient]
Part time or full time?
[Common mistake: Explaining WHY you want part time or fulltime. This is supposed to be a TL;DR with the bottom lines, helping candidates understand if this is relevant]
[Good: "Full time"]
[Good: "We are flexible about part-time/full-time, talk to us and tell us your preference"]
[Good: "We are flexible about part-time/full-time, here are our considerations: ..."]
[Bad: "As an organization that started 1 year ago, the culture is important for us and ,...." (better to start with the bottom line and only then explain the reasoning) ]
Part time logistics
[If you have flexibility here, it’s good to write it down. Freelancers might not apply if they see something rigid which they can’t conform to - and you might not even care about this rigid thing, you might just care about the job getting done somehow sometime. Candidates might have a preference for some kind of flexibility that can be found almost nowhere, but if it can work for you, you might be an amazing find for them]
The org and why we think it is impactful
[Don’t stay vague, like “we want to safeguard the future”. As a rule of thumb: Whatever description you put here should be, in the bottom line, only relevant for your org, not to big chunks the EA/LW communities]
[Common mistake: Sprinkling your pitch of why you matter into all parts of the job posting, making it hard for people to read the part they’re interested in, or for people who already believe in your org to skip that part]
[You don’t need a measurable/graphable/reproducible/RCT/math-proof that your org is definitely impactful (!!) not all orgs are AMF. This is totally ok, it just means you won’t hire the people who only want to work at AMF (which is ok because you aren’t AMF). A good prompt is “why do you think your org is impactful?”, for example “we think EA outreach is important, and that X is a way to do it with lots of leverage”]
[An important reason this section about impact exists is in order to let you NOT write about impact in other sections, which would hide important/relevant information that people might be looking for. For example, if your section on local/remote starts with a paragraph about your impact, then (I think) you will lose readers. So put all your pitch (whether short or long) here, and whoever cares about your impact pitch will read this, and whoever doesn’t care (for example, they already know your org) can skip it]
[Optionally split this section into:]
Why we think we were impactful so far
Why we think we will be impactful in the future
[Some candidates feel like an org is “ready” / “done” / there’s nothing else to do anymore. To address this, you might share your vision for new features in the next few months, or maybe explain your bottle neck and how hiring this role can help with it (assuming this is true)]
Our tech stack
[or whatever existing system/thing the candidate will have to work with, if any]
[Buzzwords of concrete products/technologies are good. If you want to have more than just buzzwords, make sure to also have a buzzwords title]
[Common mistake: Using a general term like “pub sub” or “cloud” or “decentralized” without the concrete product, like “rabbit MQ”, “GCP”, “etherium”. Lots of developers care about these specifics]
[Common mistake: Trying to “make up” buzzwords that you heard sound good even though you’re totally not sure about them and open to change. If you’re flexible, say it. It’s a bad experience for many developers to have (sometimes non technical) managers try to micromanage technical decisions. More broadly, if you’re trying to hire someone who can pick technologies, say this is the situation. If you want someone who can work with your existing tech, say that]
[Great: A link to your github]
Writing clean code
[TODO]
[TL;DR:
Saying you want clean/organized/.. code seems vague to me, consider being specific.
Saying it’s important for you to have tests for everything (while in practice you have tests for nothing) is misleading in a very negative way. I often talk to candidates about how to see through false advertisements like this, and I often hear heart broken candidates who took some job which was in some way misrepresented to them. Don’t be this job. Hire someone who’s happy to work with your system as it is. If you’re embarrassed about your code, you might hire someone who can help you tidy it (but who is happy and not depressed by working on such a thing). I can say a lot about this. [OMG this was not a TL;DR, sorry]
Clean/tested/”perfect” code isn’t actually always a good idea, there are tradeoffs, but I digress.
]
Your role
What you’ll do?
[Responsibility, such as “the entire tech” / “the backend”. Make sure you explain existing tech too. (that title can go here)]
[Great: Example tasks the candidate could do last week / next week]
[Common mistake: Giving an example task like writing some complicated algorithm that was already done and nobody will ever have to do again]
[Common mistake: Vague things like “whatever we need” without examples]
[Common mistake: Saying “interesting” or “you’ll learn a lot” or whatever, without concrete examples. Let the candidate judge if it’s interesting, obviously you as the employer think it is interesting]
Why is this role important?
[Bonus: Use the word “bottle neck”]
[Selling points for this position, like “you’ll have tons of ownership”]
[“bad” things in this position, to prevent the wrong people from applying and being disappointed]
[For example, if the candidate will work alone and have no mentorship, better they know this before signing]
[I know many orgs try to "look good" and hide their flaws, but I'm going to baldly say this seems like a mistake]
Mentorship
[Examples: “Every code is reviewed”, “we do paired programming every two days”, “you’ll have a one on one every week”]
Should you apply?
[Good example: “If you can write a significant pull request for tensorflow, then apply right now!”]
[Good example: “You don’t need to learn ML or to actually write that pull request before applying”]
[Good example: “If you can solve this [link] in 30 minutes then you’ll probably pass our interview”]
[Bad example: “We only hire the top 10%”]
[If you put a hard limit like “2 years react” or so - note this will actually get you less applicants. You might want to do this if you’re overwhelmed with applications, but if you’re not, and you prefer more people will apply, then consider having less of these]
[Probably avoid having the candidate evaluate their own skill subjectively, since so many EAs have impostor syndrome, including very talented ones (!)]
Will you waste our time by applying?
No.
[Lots of candidates have impostor syndrome and are afraid to waste the org’s time (!!!). If this is not true for you, write it down]
Salary
[Good: A concrete salary/range, and a list of benefits]
[Maybe bad: Saying you pay “market rates” and then listing some number way below market rates]
[Probably good: Asking your candidates to tell you [including anonymously] if your salaries are preventing them from applying. This is especially relevant if you think you’re paying market rates but are not sure]
[Note some of the best candidates might be making more than market rates, and so posting market rates would be taking a pay cut, for them. But not sure, since this is also related to “negotiation skill” / “career development skill”, which many good candidates (sadly!) won’t have. But some will]
[Good: “We pay FAANG salaries” (and explain that they can expect to earn with you what they’d earn there) - this is less subjective than “market rate”]
How hard is it to apply?
[Good: “Just send your CV or linkedin here”]
[Even better: Some even easier solution for people who get analysis-paralysis from writing their CV, like “write a paragraph instead”]
[Common mistake: Having a cover letter and not writing in big flaming letters that it is OPTIONAL. Cover letters are a costly ask, and discussing this in length is off topic, I think]
[Common mistake: Saying it is “easy” or some other subjective interpretation, and then actually having a ton of fields to fill in]
[Common mistake: Saying “don’t spend more than 2 hours on this” or so. This doesn’t actually work]
[Common mistake: Saying quality doesn’t matter when actually you would disqualify people because of this field. “quality” is too vague.]
[Good: Say “I don’t care about spelling mistakes or things like that”]
[Good: Saying explicitly what you’re looking for, such as “engagement with EA” or “you got paid to code” or “we’ll talk to your references”, so that people won’t spend mental energy on the wrong thing (they do!). Note this is better than just vaguely saying people “shouldn’t spend long” on the application because it is focusing them on what yes to spend time on]
[If you have room for something like a github or linkedin, SAY IF IT IS ACTUALLY OPTIONAL!, candidates will sometimes postpone applying if they think they don’t check all your checkboxes. Even saying “we prefer people who X” can get someone to delay by months. For example, if you’re happy to teach multiprocessing but you only mention that you prefer people who already know multiprocessing, then some people might delay their application, learn multiprocessing, and only then apply]
[Good: Say “we’ll teach you ML if you don’t know it, don’t worry” or so, to make people less likely to make the mistake above]
What does the interview process look like?
Stages
[The candidates want to know how much work this is going to be]
[Do you have a work trial? This will be a deal breaker for many]
[Don’t say “short” because this is a subjective interpretation, give objective information (like “you have 2.5 hours to solve this”) and let the candidate decide if that counts as “short”]
How to prepare for the interview process?
[This can help the candidates not prepare for the wrong thing]
[I recommend that if you ask something, like leetcode or “javascript trivia”, then say it in advance. You don’t want people to get accepted based on whether they guessed correctly what you’d ask or not, you prefer everyone to have equal opportunity to prepare, I think. Your call, I’m less confident in this one. This is what Google does (at least as of a few years ago), they send references to a book and some online material about how to prepare for their interview. This seems like a good call to me.]
How long between applying, getting an answer, and starting to work?
[Some candidates will worry this time is too short, and some will worry it is too long. Whatever flexibility you might have, write it all down]
[Good example: “The fastest we can do is about one week from you applying to an offer, and you can start once you say yes. We are flexible enough to to let you reply by [date 1.5 months in the future] and we definitely want someone to start working by [2 months in the future]. If those dates prevent you from applying, please let us know! [link], maybe we can do something about it”]
[Example: “You can reapply immediately / after 6 months”]
[Some candidates won’t apply until they’re totally totally ready, because they don’t want to ruin their chance with you]
[Do you prefer that a candidate prepares for long and only then applies, or that they apply first, and if they don’t pass - only then they prepare and apply again? This is a super interesting question for many candidates]
[Consider inviting the candidates to ask you questions in the comments, especially if you’re doing something complicated like a new AI Safety project and many people won’t easily understand the impact. This is more useful to do publicly because it will give candidates the knowledge that if there was something important to ask, someone else would ask it]
[Also inviting anonymous feedback - on your job post and in general - is useful. If something is missing/wrong about your job post, it’s great to have a low friction way for people to tell you about it. A classic example is “you think you pay market rate but you actually under pay”, but candidates reply with all sorts of interesting things if they can. Low friction matters: just have one text box, and make the form anonymous.]
I recently saw two job posts, one for Giving What We Can and one for Effektiv Spenden. Both of them seemed to be based on this template (the 2nd one was confirmed to be created with Yonatan's advice), and I have to say, they were some of the best job posts I've ever seen. This should be the new standard!
I'm particularly a fan of: