This is a great article, and I've become increasingly frustrated with technical challenges over the years, but I only partially agree with your takeaway. There *should* be technical challenges, but *how* they're performed makes all the difference: if it's being used to evaluate how someone works through a problem collaboratively (with the interviewer) on a whiteboard, with the focus on talking through / thinking through and not on nitpicking code, then it can be a very powerful tool and a fun experience for both participants. If it's not a positive experience for either party, that should be a red flag for both of them.

Having said that, after one too many "take-home" exercises a few years back I now refuse to do them, unless those exercises provide some real value to me. I will happily do a paid-for small project for my employer as part of an application process (to be fair, I've been contracting for years so I guess not everyone would be so comfortable with that), or at the very least solve a real-world open-source problem where

a) I'm not wasting my time

b) I can show off my problem-solving abilities as well as my communication skills

c) I can be paid for my time (eg. via Gitcoin)

d) I can add those efforts to my portfolio