Best way to pass on the problem solving experience In my workplace, my team (working both on a ASP.Net MVC ecommerce and a C++ client) had a recent addition of two young members. One is a fresh graduate and the other worked as PHP programmer for some time. They're both kind of new to the ASP.Net world, along with all advanced concepts of ORM mapping, IIS configuration, performance issues and tricky-to-spot bugs. I'm the owner of the C++ side, and the other team member owns the ASP.Net side (on which I can work a little bit).

We, as senior team members, are expected to carry out our duties efficiently, and at the same time support the young ones in their gradual growth. They're doing their best, and our company allowed me a bit of dedicated time to spend for their education.

I collected my colleague's impression that the basis are already kind-of covered and what they really need to grow is to start thinking in a "professional" way (e.g. understanding the life cycle of a web application or HTTP request, or face a problem without relying entirely on the "senior" side).
I think these skills come naturally by spending time on the particular project / language / framework and only if one accepts (or is forced) to take responsibilities.

Are there ways to efficiently pass one's "experience" and "problem solving attitude"? Does sitting beside the young ones and working together on the same problem (almost always splitting the work like 70/30) help or hinder their growth?

Thank you for your time.
In places that use the ideas of agile software development, the usual way is to just let the newcomers pair with the more experienced members in all tasks. In your case it would consist of a lot of pair programming. But you would need to do it correctly. It isn't one person programming and the other person watching. Both participate, but in different ways. See Pair Programming Illuminated for a specific description or Extreme Programming Explained for a more complete description of the whole process. 

The experience of agile shops is that pairs produce about as much as people working individually (there is research to that effect) but with higher quality. (Specifically, the hypothesis that individuals produce more in total is not supported). 

But more so, the newcomer is immediately introduced to the local process in an active way and can start to be productive much sooner. However, the experienced member of the pair will need to turn the keyboard over to the novice frequently (roles switch every several minutes, not hours), and both will need to learn to adopt to the individual roles of "driver" and "navigator". 

Pairing combined with faithful use of test first development is especially productive of high quality software, but you need to actually practice the skills, not just talk about them.