"Take home" questions are heavily biased in favor of the employer because they're not required to put anything on the line.
An asynchronous test is definitely more flexible for all parties, but it also means the employer can more forward with far more interviews than they would be able to do in person. Leading to more candidates wasting their time doing nonsense work when they have proportionally less of a chance of getting the job.
Possibly I'm just bitter because of the time I spent 4 hours on a take-home only for the company to ghost me (name-and-shame: Instacart). But at least for in-person interviews they have to buy you lunch before the ghosting can occur.
Speaking of Instacart, I scheduled an interview with them via interviewing.io, which I was told was a "technical chat," designed to get to know a little about me, and to answer any questions I might have. I had qualified for the interview by scoring well enough on phone screens on interviewing.io, so, this technical chat was supposed to be followed by a real, actual coding interview.
Guess what? It wasn't. They rejected me as soon as I de-anonymized to allow them to see my resume.
They should really be paid at the comp rate of the position you are hiring for (which is... a lot more than $50/hour for the Bay Area employers who have given me take-home interview problems).
Worst for me was for Rakuten when they asked to basically implement a complete ETL pipeline to populate a mini-datawarehouse. It was easily more than a week's worth of 2 hours per day work that was supposed to be done within a week and worse, they didn't even bother to provide feedback.
The worst experience I've had with a take home problem was when the interviewer did not even run the program I submitted. As I explained the solution it became clear that the interviewer had not even looked at or run the program. It would have been easy, it was in Python.
To top it off the interviewer then sprung a surprise leetcode problem on me that had to work and was required to be written in a language ill-suited to the task. I bombed it and the interview ended. No one ever even ran my submitted program.
If you think that's bad. I did my code submission tested the crap out of it. Then found out that the person "couldn't run it". We had a back and forth conversation about it. I even created a docker test bed with the right environment.
>"Take home" questions are heavily biased in favor of the employer because they're not required to put anything on the line.
Not to mention it doesn't test the collaboration aspects of real work. Imagine doing your job but you're not allowed to talk to your teammates in case of a blocker. How are we doing our jobs here?
But when it comes down to actually starting them, I will always pass if they come before any interviewing round. You don't yet have a stake in the process.
That has the down side of some potentially sticky legal issues. For instance, people on visas can't do paid work for any company other than the one sponsoring them. It introduces a small annoyance at tax time, as well.
An asynchronous test is definitely more flexible for all parties, but it also means the employer can more forward with far more interviews than they would be able to do in person. Leading to more candidates wasting their time doing nonsense work when they have proportionally less of a chance of getting the job.
Possibly I'm just bitter because of the time I spent 4 hours on a take-home only for the company to ghost me (name-and-shame: Instacart). But at least for in-person interviews they have to buy you lunch before the ghosting can occur.