My advice for people who wanted to prep for these interviews originally used to be to read through some books that prep you for algorithm competitions (e.g. ICPC, IOI, GCJ), but I find that to be a bit overkill and not as efficient a use of time (although some of these books do a much better job of explaining things than any of these interview prep books I've gone through). Today the advice I'd give is get a book like 'Elements of Programming Interviews' in the language you plan on using and a leetcode subscription and just get down to learning about a data structure/algorithm/problem solving paradigm and then solving a bunch of questions that fit that technique.
If you really want to go with the overkill approach, I'd recommend a book like Competitive Programming 3: https://cpbook.net/
As an engineer who implemented/architected SaaS applications, I cannot take these questions seriously at all and I genuinely refuse to work for companies that ask leetcode.
Do these questions help me to find good/above average Junior Engineers? No. Do these questions help me to find good/above average Senior Engineers? No. Do these questions help me to find good/above average Managers? No. Do these questions help me filter people who cannot memorize algorithms/interview questions or spend enough time on them? Yes.
So where is the logical connection between leetcode problems and finding good/above average employees? As far as I can see there is none.
There is literally almost no connection between a candidate being capable of solving leetcode and being a good software engineer that is capable of controlling/reducing complexity of the engineered applications and working well with other team members.
More rational approach would be asking people architectural questions, even at the Junior level. I expect a good junior engineer would have already implement a small scale system at least as an final year thesis project, so they should be capable of handling questions related to engineering/architectural design.