Unless you are the top company in your bracket, your completion rate will also not be so great for a take-home (people have limited time: they'll sort by how good your company is). Sure they'll do Google's take-home but local business that does local comp/prevailing wages? It's at the bottom of the pile. By the time they get to it, the best candidates will already have an offer from a better company.

That's why I prefer to bring people on-site as soon as possible, and do a little whiteboard (the point being that the candidate must... know how to code!). It's an artificial challenge that's really a pretext to have a technical discussion.

Only time I advise to use take-homes is when you are dealing with a massive number of applicants from institutions that have a poor signal to noise ratio. Bootcamps come to mind. But then you end up with candidates that have the homework done by someone else and it ends up not being a good filter either.

I don't know, perhaps it's because I've progressed every interview I've had the opportunity to do a take-home on (and I struggle with most leet-code style whiteboarding interviews) but I've always seen take-homes as an audition for your software development style -- what you deliver in a take-home assessment is what they will use to judge how you'll deliver on the job, plain and simple.

I've only done take homes for companies that I've already passed initial interviews for and generally like the people I've talked to and have favorable impressions of the culture/workplace thus far. I wouldn't do a take-home before that, but I'd do a take-home any day before a leet code grinding thing.

Few months later I got a call asking to interview again as they realized their standards were too high. Not a chance.