Please don't take this the wrong way, because I think a lot of very smart people disagree with my take on this, but: I hate pretty much every part of your hiring process, and could as a result use it as a springboard to talk about how we're trying to design ours.††

My problems:

1. Makes demands of the candidate before selling the role (in fact, explicitly!)

I recommend you don't do this. Instead, make a point of going out of your way to sell your company and your role to your candidates before you do anything to screen them.

This serves three purposes: (1) sure, it makes it marginally more likely that you'll keep high-value candidates engaged who'd otherwise fall out of your pipeline at/after "stage 1"; (2) more importantly, it helps disarm the interview process, both by establishing that you, the employer are going to put the effort and initiative into keeping the process running and establishing that tone for the whole process, and, even more importantly, by making the candidate actually want the job so they'll perform better during the process; and, (3) it's both the right thing to do and a noticeable difference from most firms' terrible hiring processes, which is good for marketing.

2. Is extremely subjective

Right out of the gate you're asking the candidate questions you can't possibly be benchmarking. "Code you're proud of"? What if the code the candidate is most proud of is something simple that been super useful on lots of projects? What if the candidate cherry-picked it from their code to demonstrate the most complicated stuff they've worked with? How will you compare it to every other code sample you get across the lifetime of your company? You're doing that, right? Keeping track of how well your hiring process predicts performance?

2a. Culture fit

Beware culture fit questions. You state it outright later in your process when you say (paraphrased) "you can train technology but personality mismatches are impossible". That's a recipe for hiring the same 10 dudes who like roughly the same X360 games. I know that sounds hyperbolic, but look around you at other companies and tell me that isn't a real concern.

Two other problems with culture fit questions: (a) they mask irrational responses from interviewers, which happen all the time. Some of your best performers do badly on interviews, because they just don't interview well. Some of those people (ironically, it seems to be those people in particular) will be hard on candidates who have the same problem. Why are you setting the expectation with your team that they should ding candidates for intangible, irrational, or subjective concerns?

In neither (2) or (2a) am I arguing that you should only be hiring based on measured defect density or ability to correctly estimate how much time feature X would take† or typing speed. If there are specific personality traits you need to select for, that's fine: just select for them deliberately, and train your team how to select for them, and track how you're doing.

3. The tryout project

This is going to make me sound like a jerk for at least 2 reasons I can immediately think of, but, to sacrifice (a lot of) tact for (a little) clarity:

I think less of teams that propose short contracting projects to candidates to try them out, because I would never agree to interview on those terms.

Here are the problems I have with this approach: (a) it invites/provokes an argument during your hiring process about what a good daily rate is, (b) it asks the candidate to negotiate an hourly rate in a situation where their leverage is egregiously compromised, which is unethical, (c) job searches are full-time jobs by themselves, and your best candidates are almost invariably already employed, so how could it be reasonable to demand they take a temp job with you as part of that search, (d) it requires you to demand the candidate produce billable work and assign the resulting IP before the candidate is sure they're going to accept the offer they might get from you, (e) the tryout project is deceptively low-information.

On that last point: I guess I've hired a person or two in my career that ended up not working out almost immediately. But usually, the dealbreaker problems I've had with coworkers or employees took months to surface. Lots of people can be productive for a short, high-stakes sprint. But virtually no dev team is hiring for that; they're hiring for the ability to be reliably productive, to exercise good judgement in design and estimation, and be compatible with the decision making process the team uses.

Yes, the tryout project proves the candidate can produce code you might deploy on your website. I hope I'm not the first to tell you that that is a very low bar; lots of high school students can do the same.

Please please please take this comment in the spirit I intended it. I expect lots of smart people will disagree with some or all of it, and would be happy to learn from them. I'm pretty convinced though that the conventional interview system that some of the smartest teams use is fatally flawed in a bunch of ways, and this hiring process is an opportunity for me to start talking about why.

%. One last point because I am on a tear about this lately

I would like to start establishing a meme: Job Interviews Are Hostile For Candidates.

Normal people don't enjoy interviewing for jobs. Normal people find the experience off-putting. They're nervous. They're dealing with a procession of people each of whose stated position is to judge them. Normal people don't like being judged by strangers. They sit there and read tea leaves from behavioral cues about whether they're coming across well. In my experience, this happens even in phone interviews, which (can we also establish this meme?) are the worst.

I am not saying don't interview people. I'm just saying when you do it, assume all the signals and readings you're getting from your candidate are janky as hell, because they are. Lots of strong performers can't do their best thinking and judging when they're conflicted and anxious. Compensate.

Whoah, long comment.

† BTW: my favorite dev interview question

†† There is a better way to write this paragraph but I'm pretty depleted right now so please excuse the clunky, combatitive tone.