I'm a senior engineer. Last time I interviewed, I received multiple offers from brand-name employers. None of them required any work samples, just hard technical interviews.
A few times I saw a small unknown company that piqued my interest. I talked to them. Occasionally one would require me to do some sort of a task.
Why would I do it?
I don't need to do any of that for the top employers in the market. Why would I spend hours of my time, and precious coding time, especially on some small company I never heard of before?
I haven't done that in years, and doubt I'll ever do it again. The only way you could get me to do it is if I was desperate for a job.
By requiring this sort of time and effort from candidates, you are screening out the best ones, those who can get multiple offers from great employers without jumping hoops for you.
Almost any work on compilers will involve good working familiarity with graphs
Work with concurrency will tend to involve linked data structures, like treiber stacks, or modeling computations as directed acyclic graphs of data dependencies
Working in a memory constrained environment tends to involve data structures and algorithms tailored to that domain, etc.
Now it's totally true that many algorithms questions just reduce to brain teasers, or are so esoteric and interview-specialized (Find out if this linked list has a cycle in O(1) space!) that they only serve to stoke the egos of the interviewer. But I wouldn't say that using algorithms or implementing a data structure is a skill that only exists to facilitate interviewing - and being able to explain your thought process as you work is really important when making contributions to other teams' code. I try to focus my interview questions on miniature versions of problems I've actually had to solve in the course of my job. For example, the futex state machine I wrote here:
If you subtract the interrupt and timeout handling, you have a real problem with a simple, approachable (for someone with some concurrency knowledge) solution, and you only need to know about two futex calls which have simple behavior and are easy to explain in limited time. I wouldn't ask this question of someone looking for a web development position; but then again, I don't interview those candidates because I know nothing about web development. But it's a nice question for someone who listed concurrency on their resume.
Also, "an hour of my time programming a solution to a problem" is likely not an actual work-sample/take-home - it's likely a replacement for a phone-screen that doesn't require an engineer to conduct, thus can be given to many more people to keep the top of the funnel large. The only time I've done a real take-home in less than 10 hours, it was rejected for not being polished enough.
Because you were competing with folks who were unemployed and probably invested 30+ hours in it.
I'm fine going through tough technical interviews.
I'm not fine spending 3-5+ hours on some trivial coding task that can be gamed and was issued to me by folks who may not have even thoroughly checked my resume.
Given the current supply/demand curve, and the fact that top employers like FAANGs do not require this sort of time and effort (and for a good reason), I don't have to jump through that hoop.