This guide has two sections, one for employers and one for prospective employees. We'll start with employees.
Obtain a copy of "Algorithm Design" by Jon Kleinberg and Éva Tardos. Any edition is fine.
Follow structured coursework on that book or otherwise go through it in a way that you can manage. Slowly work your way through while living your life.
Here are some slides and here is an edX course from standford.
If this does not satisfy you, seek out a book of similar character.
Branch out. I understand why you are stressed about "Data Structures and Algorithms," but I guarantee that time spent elsewhere is going to be more valuable for you.
If you've done step 1 and 2 you have enough background info to begin to tackle whatever hard problems you run into in practice, focus instead on getting practical experience building things.
It doesn't matter if those things are trivial either: hastily writing a jank calorie tracker website or virtual shrine to Edward Cullen will provide more long term value to you than spending your evenings grinding Leetcode.
Only do "Competitive Programming" if it is truly an interest of yours. It's fine if it is, but you don't need to do that kind of stuff to be qualified to perform most software jobs. Even the "prestigious" ones.
Please, for the love of god, cut the shit.
If the position you are hiring someone for does not require implementing or understanding Gale-Shapley or reversing a linked list, do not make testing someone on that part of the interview process.
I do not care if you fancy yourself an "elite institution" and want to "uphold standards." It's the TSA of hiring practices. All theater, no usefulness. When people know that's what they'll be tested on they spend time practicing for the test and not their actual responsibilities. This helps no one.
Rework your hiring processes to be more holistic. This will cost time and energy, but it will cost orders of magnitude less time and energy than having employees who can balance a trie but store passwords in plaintext.
If you don't know where to start, give your technical interviewers this mind map and the explanation following it. PDF link here.
It's mostly a memory aid for making sure I cover topics in an interview but it's also an ordered guide. I start at the top right and work my way down that side. I drill into the branches if a) the candidate is enthusiastic about a topic or b) they are very reticent. Once I get down the right hand side (mostly "soft" skills stuff), I move to the top left and work my way down that side (more technical/process skills stuff). I skip any topic they've already covered. I print out a fresh map for each candidate and make brief notes around the edge of the page.
The "conflict resolution" branch tends to come up in the "worst project" area but it's there as a reminder to make sure it's covered if they haven't mentioned it elsewhere.
Overall, it was written as a general guide, not specific to any particular programming language, so you have to play it by ear somewhat if you're interviewing for a senior FP role and you're only interested in FP, for example, or if you're interviewing for, say, a scrum master, or an ops role -- anything really specialized.
Prior to the interview, I'll also use the map as a guide for highlighting things on their resume/CV that I want to dig into during the interview -- I may highlight parts of the resume or add "pre-notes" to their map, and use both side-by-side.
I try to couch all of it in "tell me about ..." open-ended questions and avoid quizzing them on specific technology as much as possible. If they don't mention some of the specific tech organically that I want to hear about, I will "guide" them back to that at appropriate points.
The diagram and explanation comes from Sean Corfield. He does not know I am writing this or quoting him.
Stop paying Leetcode and companies like them for candidates. It is in their best interests to feed slop into the slop trough. Do not gobble their slop.