This is true. And the other issue is giving out tests that are low signal for skills that are actually needed day to day. I went through an FE test that's 2 alg

This is true. And the other issue is giving out tests that are low signal for skills that are actually needed day to day. I went through an FE test that's 2 algorithm tests (that requires a recursive solution) and a CSS test. I studied CS in university so I know algorithm and complexity is important, but as an FE developer, I really think deep about algo in <5% of my work. 50% of my work is coding, in which 30% knowing CSS layouts and styling (usually abstracted), 50% state and logic management (UI views/components + API, thinking about the suitable abstractions, form logic), 10% interfacing with the browser. The rest of coding (10%) is the algorithmic work + debugging. The other 50% is collaborating with the Product/Design team to explore the solution space and refine requirements (divergent and convergent), working with the BE team to shape the API, and working with QA to replicate and identify issues. A lot of the algorithmic issues are already handled (browser implementation, framework, libraries), and I think knowing/setting up how to identify the algorithmic bottlenecks is far more important that thinking about algorithms all the time. I do identify more as a product-first dev rather than a code-first dev though. I do agree it's hard to evaluate a developer holistically, and a company needs to weed out developers that isn't up to their standard, but I still feel the most ideal test is a test project with 2-5 times working time from internal estimate (2-3 hours? give them a week), with a showcase/interview session to demonstrate understanding how the project works. The signal to noise ratio is much better in that sense.