You can't get team members to review your code if your team doesn't agree that code reviews are valuable. I'd say code review is one of the three things that most developers don't do enough of. So the first step is to simply talk about code review in a meeting with your whole team (including managers). Ask them what they think about it, whether it's valuable, and how often it should be done.
I'll bet good money that at least half of them think it's a waste of their time. If so, your first step is education. You need to pull up reviews where valuable comments were made, especially if someone caught an actual bug before merge (you shouldn't sell CR as a bug-finding tool, but it is a nice bonus when it happens). If your coworkers lack experience, this might be a hard sell. Even so, it's something you should gently raise as often as possible, so they eventually absorb the idea that CR -> better quality -> better code -> fewer bugs -> better Quality of Life for devs.
Once you get the team to at least pay lip service to the idea that CR is valuable, you then need to make a mechanism for enforcing it. Ideally, your version control system does this (trivial to configure on GitHub, for instance). If nobody can merge without getting a CR, then hopefully everyone is bottlenecked on it, and is thus incentivized to clear out the backlog. When this happens, you need to do something which may at first seem infinitely difficult for you: you need to do nothing. There is an average number of PRs produced per dev, and each dev therefore needs to perform that number of CRs to have an equal distribution of work. You need to estimate that number and do no more than that many CRs.
Soon, everyone on the team will complain that there is a huge backlog of PRs waiting to merge, and you need to make it clear that the whole team needs to carry the load of reviewing them. Gently remind them that they agreed on the value, and resist any calls to remove the CR lock on merges. Most likely, they will do CRs grudgingly and sporadically. To help assign accountability, I created a tool for my team which did a very basic round-robin assignment of PRs to devs. Everyone could see who was not doing reviews, and everyone knew who to talk to if their PR was blocked on review. Just having this visibility helps enforce the desired behavior.
Also, seniority really has little to do with this phenomenon. I see it across devs of all skill levels. Many times it is the junior devs who grew up in a more modern software culture who embrace code reviews, while senior devs who are used to merging without review resist it. So, really, it is just an individual preference which is unfortunately pervasive throughout the industry.
Finally, you need to get past the idea that CRs are for finding defects. Code review should be primarily about distributing knowledge. Just having someone else read your change makes another person on the team aware of the change, and more likely that the team notices potential design conflicts with concurrent or imminent changes. It's also for education. Junior devs should get just as much out of performing a CR as seniors, but of a different nature. You should teach the juniors that if they have no critiques of the code they are reviewing, then they should ask questions. Surely they are learning something new here and there, or they see something unexpected that was done differently than they would do it. Asking these questions and getting good answers helps them learn which practices are specific to your company vs. general software engineering best practices.
If anyone expresses reluctance or hesitation to perform reviews, especially of your code, then just offer to pair-review with them. Tell them the things you look for, and ask them to explain your code to you. If their explanation misses something interesting, ask leading questions to highlight your point. If they fail to understand some bit thoroughly, then ask them to put a question on the review to show that your code was not as self-documenting as it could have been. Then go through one of their PRs or someone else's, and demonstrate the same principles. Show by example that a CR doesn't need to be intimidating and that it can be a valuable learning experience for everyone.