Excuse me, but if not getting in touch with your colleagues blocks you for the whole day then you probably have the bigger problems than just not getting your questions answered on time:
1. Maybe documentation is scarce, be it code comments or business requirements specs, user stories, epics, etc.
2. Maybe your tasks are ill defined, and you accepted your assignments without asking enough questions upfront...
3. Maybe you don't get enough workload (if you had many tasks to choose from it would be harder to get blocked on all of them)
4. maybe you lack some technical knowledge or other competencies needed to make the decisions yourself instead of asking others.
That is rubbish. Many reasonably complex projects require a reasonable amount of communication. This list sounds like you have only worked on 1 man toy projects.
Any reasonably complex codebase I have worked in has at least parts that only a few people understood. Even if n=3, you could still very easily be blocked when trying to find someone in the know...
You're right that these are problems, but how long does it take to solve them?
1) Do you know of a way to document a significantly-sized application in such a way that it is not massively more efficient to ask a colleague for help than to go source-diving? Say we are talking about a rails app that has been maintained for 5 years and with a reasonably complete test suite.
2) Does a fresh-from-uni or perhaps 2-years-out-of-uni junior developer teach themselves how to ask just enough questions up-front that they don't need to ask more to unblock themselves?
4) How does one gain this technical knowledge if you are on a project and need to apply it but don't yet have it yourself?
Re 2: Often tasks are even meant to be exploratory, where those questions can't be asked upon receiving the task, but only once enough investigation has been done and implementation questions are run into. Rather than a quick back and forth that keeps me progressing, I have to context-switch to something else, and spend time re-familiarizing myself with what I had done the day(s) before again.
Do you know of a way to document a significantly-sized application in such a
way that it is not massively more efficient to ask a colleague for help than
to go source-diving? Say we are talking about a rails app that has been
maintained for 5 years and with a reasonably complete test suite.
Yes. You can draw architectural diagrams. You can create a wiki where people document problems and solutions. You can have broader design reviews where people talk about the ways in which they solved various problems and what considerations they took into account when coming up with those solutions. I agree with the other posters in this thread: if you're truly blocked (i.e. literally unable to work) because someone can't respond to your question, there is something deeply wrong with your codebase, or in the way in which your team communicates. Personally, I would expect anyone who's been on the team for more than few months to be largely self-sufficient when it comes to actually coding. Of course, there will be questions when there are multiple possible approaches to solve a given problem, and I would expect someone to raise a flag and ask about the relevant considerations. But in the absence of a reply, you should be able to pick an approach and push forward with it.
Does a fresh-from-uni or perhaps 2-years-out-of-uni junior developer teach
themselves how to ask just enough questions up-front that they don't need to
ask more to unblock themselves?
Honestly, at some point, you have to learn your team's codebase. You say that it's massively more efficient for you to ask questions of colleagues than it is to go source diving. That, to me, indicates that you don't actually know your codebase very well. Again, this is a sign of a problem on the team. Either the source is so tangled that no one can hope to understand all of it, or people are becoming siloed - specializing in particular areas of the codebase in ways that leaves them unable to fix problems in other areas. It's all right to be better at one part of the code than another. For example, I'm better at some of the middle-tier/business-logic code than I am at UI work. But, in a pinch, I can jump in and help with UI if it's necessary.
How does one gain this technical knowledge if you are on a project and need
to apply it but don't yet have it yourself?
I'll be honest. It's rough. You have to learn, and you have to realize that outside of university there aren't going to be TAs and professors to point you in the right direction. You will make mistakes. But that's the only way forward. Keep trying. Keep writing code. If you do something and it doesn't work, have a meeting in which you go over what you did, why it didn't work, and what you could have done better.
1, 4. Yes, documentation is absolutely scarce - given that culture, such back and forth is often required. Some configurations or details of a complex (and often legacy) system are opaque, and used infrequently enough that teamwide training on it isn't appropriate.
2. Yes, often my tasks are exploratory rather than implementation of a particular feature. Often the goal is to explore and then discuss my findings. When I can't just go up to someone's desk in person and ask them when they are free to discuss, Slack is a good resource to set up a meeting.
3. I definitely am not blocked on all, but the context switching hurts my productivity as well - to me, a quick response would have large benefits for me and a minimal distraction for my colleague.
Their equivalent. Neither gives a detailed enough signal to be useful for anything other than posturing. My experience with competitive coders has been just as mixed as with the rest of the candidate pool.
I've observed a strategy of preferentially hiring competition coders have no discernible positive impact.
1. Maybe documentation is scarce, be it code comments or business requirements specs, user stories, epics, etc.
2. Maybe your tasks are ill defined, and you accepted your assignments without asking enough questions upfront...
3. Maybe you don't get enough workload (if you had many tasks to choose from it would be harder to get blocked on all of them)
4. maybe you lack some technical knowledge or other competencies needed to make the decisions yourself instead of asking others.