One frequent quality practice in software development is that of code reviews. It means that one or more developers review the work of another developer before it's used in the final product, and it is a form of peer review, which is also a common practice in other disciplines, like scientific research or health care.
I tend to ask lots of questions when performing a code review, and it is a common joke around the team that I already know the answers to the questions I'm asking. But, even though that is not usually the case, I find that asking questions is often a great mentoring tool, even when I already suspect the answer. Asking questions can help achieve different objectives.
For example, if I am not sure about the reasons behind a particular design decision, I would always ask about it. It will help me gent "into the mind" of the developer making the changes, and it can give context to other parts of the code being modified. Even whenI suspect what was the train of thought that led to the result I'm looking at, I try to avoid using only those assumptions to evaluate the final result, and look for more details.
Also, when finding a possible bug, I'll ask a question related to the nature of the bug first. For instance, if there's an edge case not being considered in the tests I would ask about the expected behavior around that edge case. My goal here is to is to help the developer spot these kinds of issues by asking the same question themselves. That way, they would be better equipped to deal with similar scenarios in the future than if I just straight pointed out the solution.
This is a form of the Socratic method, a technique for debate and teaching developed by Socrates also known as maieuthics. It's very powerful, and has been used in practice to teach complex and abstract subjects, such as binary numbers and arithmetic. There are limits to its use, as with any other mentoring technique, and not everyone is comfortable using it or being exposed to it, but I find it suits me and my current development team very well.
If you have a chance to try this on your own teams and projects, give it a try. You might be surprised by the results.