[eyelidlessness]

> I'm an experienced developer with 5 years of thorough product experience in the domain. I'd completely appreciate the importance if the role actually did involve trying to eek out efficiency in a distributed system with high throughput... but 9 times out of 10 it's boilerplate business logic.

This is what I don't understand about software engineer hiring. They are ignoring important criteria about fit for the actual job, and focusing on criteria that is either orthogonal or completely irrelevant.

It's worthwhile to ask in these situations if the exercise is representative of work you'd be doing. It almost never is, but they tend to excuse it as...

> it normalises the application process against prejudice

But does it? By ignoring the actual criteria relevant to the job, they're dumping qualified people who don't do well with the hazing, and delaying evaluation of everyone else until after they're hired. That evaluation tends to be a lot less objective, because "hiring is expensive"; it selects for people who do well with the hazing, and reproduces the problem for the next round.

[bunderbunder]

> This is what I don't understand about software engineer hiring. They are ignoring important criteria about fit for the actual job, and focusing on criteria that is either orthogonal or completely irrelevant.

Oftentimes, the people actually designing the hiring process have an imperfect understanding of what work software engineers actually do. They ask the software engineers for input, but optimizing the hiring process to be orthogonal a software engineer's core work responsibilities, so they aren't necessarily going to give ideal advice.