Pair Programming is a relatively new agile-centric method for writing code with a partner. Traditionally, it encompasses a "driver" and a "monitor/navigator"; the person writing the code and the partner, coding solutions to problems that are generally trickier to solve single-handedly.
Many startups and companies have recently picked up the practice. Some of them going as far as to require an hour of pair programming a day. It is a developing practice; some companies may still offer resistance to this method.
Pair programming has been shown to decrease bugs by 15%, at the added cost of adding 15% to development time decrease bugs by 15%, at the added cost of adding 15% to development time. Whether or not an employer will justify the cost is based on their company culture and development timeline. On a tight timeline, there may be less time allocated to pair programming. Once again, it's all about being able to adapt to a situation.
The driver is the programmer in control. He's the one writing the code, taking the wheel, while listening to the navigator's advice. Vocalization is essential here. Even subtle acknowledgments are fine, as long as the navigator knows that you hear what he/she is saying, even if you need to wait until wrapping up your current thought before implementing or considering the advice given.
The navigator is the programmer working as the command center, taking in all of the code, the end goal, current progress, assisting (when needed), asking questions to improve code and clarity, and suggestions on where to go next.
As a navigator, the importance of communication is even greater; you need to elaborate when required and give the driver space if they are in the middle of implementing a solution. Take time to offer pauses, make sure the driver understands what you're saying, and not frantically playing a game of catch-up.