Normally, help is very welcome. But every project has its own culture. Sometimes it's spelled out explicitly as a “Contributing” guide, sometimes it's implicit and you'd have to learn by lurking.
It is best not too invest too much effort at once. One reasonably-sized pull request at a time. This helps you to become familiar with the conventions of the project, and helps the project members to start trusting you. Reasonably sized means that you don't swamp the project with many irrelevant small changes, but that your PRs are still small enough to be reviewed easily.
Not every pull request is helpful. For example, far reaching changes, introducing a new dependency, or implementing functionality that is out of scope for a project are not generally received well. Those have to be discussed first. In general, PRs are most useful not when they expand the project, but when they fix a small problem you've encountered while using the software.
Some issues are not an invitation for a pull request. It is unusual that you would only be “allowed” to tackle specially tagged issues, but it is common that an issue requires discussions and design work rather than a bunch of code.
It could also be the case that someone is already working on that issue.
The maintainers might want to work on some issues themselves if these issues are very important: it is often easier to do something yourself, than it is to manage others to do that thing in the manner you wanted. Wanting to mentor other people is not the main reason why many people maintain open source software.
When you present code, make sure that it fits in with the rest of the project: that it adheres to the same coding conventions as the surrounding code, and that all tests continue to pass.
If you are unsure about some decision in your code, explain that in the pull request so that this concern can be addressed.
All of these steps won't guarantee that your PRs get accepted, but they might help. And while open source contributions are nice, they're not the only way to grow as a programmer. For example, answering questions on Stack Overflow or posting a program you've written on Code Review are approaches I've used to “level up” as a developer.