I'll play devil's advocate and defend whiteboard interviews as compared to take home or online assessments. Take homes are not very respectful of the candidate's time and, especially if they are not time bound, often leads to a candidate wasting a significant amount of time on these assignments. Plus, there's always the possibility that desperate candidates would cheat and have the assignment done by someone else.
I would only use take homes and HackerRank style quiz for applicants that are from institutions I don't fully trust with quality or applications that are very spammy in nature, i.e from a college/bootcamp that has an abysmal application-to-hire ratio [1].
For candidates from serious institutions I favor a two-step approach: a screening interview with a light coding question and a full whiteboard interview. The screening's purpose is really only to answer questions about the hiring process and check that the candidate can write very simple code by himself when given a trivial problem [2]. Something not more complicated than FizzBuzz really.
A lot of folks do whiteboard interviews wrong. They often expect to get the exact implementation of an algorithm they found in a textbook and for code on the board to compile. This isn't the point of whiteboarding. Doing this only promotes rote memorization. A good whiteboard interview should be a toy problem that can be solved in several different ways by using different strategies or data-structures. The idea is to see how the candidate will break down the problem. Is the candidate able to formulate test cases, write a simple implementation, verify his code and correct the implementation should it fail a test? On the more meta side of things is the candidate able to take feedback and explain why a certain strategy was chosen? Of course, it's not representative of real world engineering but it's a good way to peek at someone's ability to debug and reason about programs; these abilities translate well into debugging and design. Especially at the college level, I really can't make any assumptions on what the candidates know.
People, especially non-technical, over-emphasis on knowledge of specific languages and framework and disregard computer science fundamentals, and I've been doing the exact opposite. I'm not judging their knowledge of the standard library of X programming language or the framework-du-jour but their ability to learn it fast.
Now, large tech companies optimize hiring at the college level because that's when everyone is on the market at the same time [3]. It's also why they have internship programs, to make sure that the best talent is already in the hiring pipelines a few years before even getting their diplomas. After that initial post-graduation job search phase, you'll see great engineers often spending several years at the same company and not even looking for a job. They are often the strongest candidates and totally invisible to recruiters.
Lastly, you can either really hope hard to find a diamond in the rough at whichever market rate you set or decide to compete with the companies that are actually attracting top talent. There's really no secret formula it's: compensation, interesting projects, technical career path and technical management. You can try to play games with CoL or market rate, but just keep in mind that if you do some of the top applicants won't even bother sending a resume in the first place.
[0] https://news.ycombinator.com/item?id=23989466
[1] https://economictimes.indiatimes.com/tech/ites/95-engineers-...
[2] https://blog.codinghorror.com/why-cant-programmers-program/