Pair programming is an instance of something that us humans do all the time: work together to solve a problem. As such it can be as chaotic or neatly organized as the humans involved want.

Pair programming is a practice (pretty much like coding as a whole) which means it needs to be practiced, honed, refined. If you jump right in without much practice it may feel awkward. So, let's review the aspects to be practiced:

Being The Driver: This person controls the keyboard and mouse, writing the code and focusing on the specific syntax and implementation. In this role you are actively trying to get the computer to do the thing you and your partner want. You are responsible for writing readable, elegant code.

Being The Navigator: This person watches the code being written, thinks about the bigger picture (design, architecture, edge cases), asks questions, and guides the driver. By definition you (generally) should not be worrying about code syntax, APIs, etc. but rather thing about the problem and the design of the solution, trying to identify "gotchas", testing assumptions, etc.

Both roles carry their own responsibilities, require focus and dedication. If you ever driving and feel like you are doing too many things (coding, thinking about edge cases, the problem, etc.) talk to your partner and make sure they are navigating for you; and vice versa, when you are navigating, make sure you're taking a step back, but remain focused on the problem and the solution.

Then, switch roles often. In a real scenario you may not switch roles for the entire session, but in this case you are practicing, so while you may be a tad less efficient by switching many times, you will be learning and getting more comfortable in each role.

Another aspect to have in mind is how learning works. With two senior engineers working together and bringing their own perspectives we can expect that:

A system with two programmers possesses greater potential for the generation of more diverse solutions to problems for three reasons:

1. the programmers bring different prior experiences to the task;
2. they may assess information relevant to the task in different ways;
3. they stand in different relationships to the problem by their functional roles.

In an attempt to share goals and plans, the programmers must overtly negotiate a shared course of action when a conflict arises between them. In doing so, they consider a larger number of ways of solving the problem than a single programmer alone might do. This significantly improves the design quality of the program as it reduces the chances of selecting a poor method. — Source

Note that we are not talking about one programmer learning from the other one, or letting them solve the problem entirely. If you ever find yourself driving the whole solution, or your partner doing so, it's a good time to stop and reassess your roles.

It is entirely normal, in a learning setting, that one person may have a deeper knowledge that the other in an area or programming language; that is fine, it takes discipline to practice pair programming and make sure both you and your partner are getting the benefits of designing a better solution and learning together.

So, if the fray of the moment as you are tackling that difficult problem together, take a moment to be mindful about the practice of pair programming, discuss roles, adjust as necessary, and switch often.