What still dumbfounds me is we went through this in the dot com days (late 90's early 00's), and I admit to being a contributor to the stupidity but we learned better ways 20 years ago. Back then we figured out we were excluding great candidates that had the experience we needed just because they could not answer some algorithm questions that they were likely never going to deal with anyway.

I even remember one of the places I was at had put me in a consulting development role initially because for their product development roles they were still using these insane interview algorithm questions. Yet, it was myself and another experienced engineer on the consulting side that were excluded from product development initially that found and fixed race conditions in their core product causing a major website and system to crash hourly. All the fancy algorithms those guys could repeat and implement from memory but none of that helped them fix a real world problem.

My own theory is that so many startups like this interview methodology because they themselves are so fresh out of school they feel an exam style interview is good because they lack the skills to evaluate anyone in another fashion. What they are missing is that the person who wants to write known algorithms from scratch is likely the worst person to help you get your product to market. That person will waste a ton of time on problems that can honestly be neat/fun to solve but have no bearing on getting to market and making money.

To be clear, I feel algorithms are a big part of our jobs, but for 90% of the startups and small business in general, their first job is get a product to market, not recreate the wheel. And for the vast majority of time our "algorithm" knowledge is spent selecting the proper algorithms not being able to write them from scratch out of memory. This is why I focus my interviews with candidates on solving problems WITH me, but I use real world problems and I don't care if they can write out the algorithm, I care they know what the issue is, where to look and how they'd go about solving it. The process they use it FAR more important than what they remember from school or studying to pass an interview. That doesn't mean I won't ask them coding questions or how to do something, but I care about process more then a perfect answer.

And sorry, but people with experience and families don't have the time to spend doing 10-20 take home problems for different employers when applying for a position. It is one of the most insane things to me, you are asking someone to spend hours of time on a problem with low relevance that in the end means that the candidate has to either take time away from their job (which if they do they aren't a great candidate IMO) or they have to sacrifice significant personal time which if they have a family is hard to do. So you are rewarding a specific group of candidates (typically young & single) and not necessarily finding the "best" candidate for the position.

My last bit of rant. Take home "tests" are one of the most lazy and disrespectful things you can do to a candidate. It is the equivalent of saying you aren't important enough for me to take time speaking with unless you can jump this high. And the bar is set as if all candidates are 24 year old males who have been running track their whole life. Experienced candidates have families, have experiences which are far more valuable than your "jump this high" test. Take the time, work through a problem or two with the person, this also tells you if the person works well with you and the team. If they don't, no matter how smart they are they are a bad hire.