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 a community, I think it would be better if we’d give applicants some kind of feedback.

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 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.

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.

My current-best recommendation (from a startup that is really good at hiring) is to ask the candidate what they prefer.

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.

1. ^{^}

   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. 

2. ^{^}

   (And because a lot of us are copying OpenPhil.)

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.

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?

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?)

Anonymous feedback from a developer (bold is mine, read only the bold if you want a TLDR):

Responding to your EA forum post about hiring developers

 I'm about to start my first dev job at a large non-EA company, and cared about a few things when choosing to which haven't come up.

 The main important thing for me was being able, in some sense, to assess the company while it was assessing me. They did this really well, so I now have a good sense of what working with them will be like. Most of this came from interning with them - in general, work trials seem really good for candidates and employers - but it came across in the interview process as well. There were lots of live-coding interviews, where the interviewers would critique my code as I was writing it (for code style, missing edge cases, etc) in much the same way as they would internally. This gave me a sense of what things they cared about, and what it would be like to be criticised in this way as a normal part of my job. Sure, this is daunting - but if parts of the job are in some way, it's better to find that out early. 

I was also given the opportunity to ask all of my interviewers questions, which they answered as openly as possible - even things like 'what's the worst part of your job', or 'if you left within 5 years, why would that have happened'. This seems like a relatively small thing that made me much more confident about what I was getting into. 

If I move to direct work in the medium-term future, I'll probably want to get a similar sense of what the culture is like - either during the application process, or just by e.g. knowing people wherever I'm applying. At that timescale I'd also care about less dev-specific things, like the flexibility to start a family, or to find a job without having to move. 

Hopefully this is helpful; I'm happy for you to use it or not however you see fit.

Thank you, whoever you are that filled out the form. :)