Before you ask a question, try to answer it yourself for fifteen minutes. If you still don't know, then ask. This way, you'll know that it's not a dumb question. But if it really is a good question, you won't be struggling for hours before asking anybody about it. You'll also learn a lot trying to solve it, and remember the answer better than if someone just told you.
For example, if a junior asks themselves "How do I sort this list of things?", they'll probably come up with a solution inside of 15 minutes if they're good. That solution probably won't pass a code review though.
The issue is that as a new dev you don't have the depth of knowledge to understand whether you solution is actually a good one or not. Talking about your idea with the rest of the team is critical for learning about some of the nuances around solving problems.
(This also applies to more senior devs too. Everyone should be talking about what they're doing occasionally.)
It works wonders, and discussing actual code makes it easier for most people than discussing abstract concepts.
This kind of advice really goes overboard and harms people who would listen to it.
The suggestion that you should solve problems on your own is far more harmful. Software development is a team sport.
I might have a question, try to find the answer, find several answers and have to dig into them to understand the answer to determine which is likely the better one etc. But this in no way takes 15 minutes, could be 30 45 60 or more. It's like I get a step closer and each "phase" is a new 15 minutes and so a new question to ask.