alt Hacker NewsI would argue it depends on the context. Of course, gaining enough experience on which contexts are worth persevering for which duration is it's own thing.
The rubric I give to juniors is a bit more simple: if you get stuck, consider alternatives that you haven't tried out. Alternatives are of a few types including: relevant evidence/facts you can gather that you haven't yet gathered, and attempts you haven't tried yet. As long as you have alternatives keep trying them (gather evidence, make attempts). Once you run out of alternatives then seek help (avoid spinning wheels).
This way when a junior comes to me I can ask them to list the alternatives they have already tried. If they haven't tried obvious alternatives (gathered facts and reasonable attempts) I send them back. If they've tried all the alternatives I can think of then I get involved.
I'll note that this tends to work when contact between team members is relatively frequent (e.g. once a day) so I can get a sense of how long the junior has been working on a task to avoid rabbit-holing.
I think with regards to new hires, go for the quick question up front every time. Onboarding people fast is an investment with high-ROI.
It's a really bad sign if someone keeps asking thirty second questions three or six months into the job and hasn't figured out how to answer those themselves yet.
It's a really bad sign if they keep asking you the same questions.
But when someone's new? It's your job to help them get up to speed. A thirty second question is probably something like "is there a reason we use Azure instead of AWS" or "do you want me to use library A or B, I see both in the codebase," not something that they'll benefit from diving into for three days.