When PRs are getting outright rejected it is because you are making incorrect assumptions or decisions in your code that don’t match with what the rest of the team knows or wants.
Before you make a decision, get another perspective.
One common pattern I see in not-quite-yet-senior devs is that they don’t necessarily recognize the moments when there is more than one option, and they are making a choice. This happens all the time in programming. You are constantly making decisions and committing to particular solutions. If you are not aware of the choices you are making - you are picking the first idea that comes to mind (or the first stackoverflow answer) - there’s a really good chance you are picking wrong.
Also try to develop your instinct for the assumptions you are bringing to the table. Did you assume this code was just one-off stuff for a simple offline process? Do others on the team expect it to be reused as a library later in an online service call path? That difference of perspective will lead to vastly different expectations for how that code should be written.
So: Take more time before you start coding to talk through the approach you were thinking of taking with someone. Then, as you start coding, watch out for moments when you can make a choice and again, get some input.
Doesn’t need to be a long design session. Just a five minute pull-aside to get a consult on an approach.
This is why pairing is so effective, by the way - you get constant access to a second perspective.