Sorry, but this isn't true. We take a lot of time going over a candidates test. The point of the take home is so that we can get a feel for the candidates level of coding competence, ability to commit to a deadline, ability to read and follow instructions and it also helps to generate questions for an on-site interview. Not bothering to read the test through properly would be a waste of our own time, as we'd not achieve any of those things.

So please, stop making assumptions about companies and take home tests. Unless you've worked for that company in a hiring capacity you have no idea what their process and motivations are.

What I'm curious about is what this industry thinks makes it unique with respect to practically every other industry with respect to interviewing. Almost every other field actually calls on references and relies on reputation to determine past work performance.

Also, I've conducted a number of interviews in my career and have been responsible for a number of hires and I've never needed to rely on a take home project to access a candidates worthiness of the position. Maybe it's because I was interviewing/hiring for positions which I was intimately familiar of the required tasks and I knew the right questions to ask.

I believe that you put a ton of time into your test, both creating it and reviewing it.

However, as a candidate I have to make assumptions on where to put my time, and if there is a take home test prior to an interview I’m likely to pass- while you are a super diligent company that carefully reviews all the responses to the screener, I’ve definitely seen those that aren’t, including companies kept taking screeners answers despite having no positions actually open.

There is an straight forward answer to this though- don’t send the take home work till after the candidate does the interview loop, or at least has a good conversation with the hiring manager. At that point hiring org has demonstrated a clear interest in the candidate and has put up “earnest money” to prove it. The candidate also knows if the position is something they are interested in. I’ve done enough hiring in the past to be confident that the interviews are more predictive of long term success anyways.

Having been on the hiring side of that, we spent way more time coming up with and testing the take home project than our applicants ever spent on it. Among other things, we'd beta test a proposed "challenge" on each other to see how well it worked out in real life before springing it on candidate.

It would have been a lot cheaper not to have the take home project, but we decided it was worthwhile anyway.

(Disclosure: our project looked a lot like a story you'd be asked to work on in your first week with us. There was none of that "hiring for a Python backend engineer; here's a Scala data engineering project" nonsense.)

You spent that much time over several dev sprints/cycles/months/whatever. Meticulously designing the expected output and quality expectations(yet not sharing any of that in the spec supplied to the candidate). All that automated testing, manual code review checklist was designed after spending that many man hours worth effort to arrive at. You have the benefit of hindsight, and insights from the process that refined over that much time. Plus you have inputs from several candidates you failed your test.

Yet now the candidate has no luxury of that, and has to guess the assumptions required to not just produce all the features, but also the quality metrics the project will be measured against. All in the deadline given by you. And he is at day 1, and that's all the day they have.

This is really like expecting some one to fix a problem in a day, what the other person spent months solving.

Agreed and what your describing actually happens in a lot of work environments. I've seen a trend in the last few years where middle management is attempting to separate "programmers" from "engineers/architects". In these environments the "programmers" don't really have the luxury of sitting with the business or product teams nor the luxury of taking part in the design process.

What ensues is actually comical. During "grooming" sessions the "programmers" are meant to give accurate estimates of how long (I know time is not meant to be the metric but it always is) a story will take to complete. A story which there are many, many person hours of context baked in that the "programmer" is seeing for the first time.

Context is worth 80 IQ points --- Alan Kay.

I don't expect you to believe that we took that all into consideration, but we really did. Several people said it was genuinely fun.