5 exercises on pair programming phrases. Choose the most natural and professional option.
0 / 5 completed
1 / 5
You are the navigator and want to take over as driver for a moment. How do you ask politely?
Option C is the most professional request. 'Would you mind if I drive for a bit?' softens the ask with a question form, 'for a bit' frames it as temporary rather than a takeover, and 'I want to try something' signals a concrete purpose without being vague. 'Give me the keyboard' (A) is abrupt and sounds like a command. 'Can I have a go?' (B) is too casual and slightly childlike. 'Let me do it instead' (D) sounds dismissive of what your partner is doing. In pair programming, transitions between driver and navigator work best when they're framed as invitations with a stated reason.
2 / 5
As navigator, you can see a cleaner approach but you don't want to take over. Which phrase best suggests your idea?
Option B uses the classic navigator move: a 'what if' question that offers a concrete suggestion (extract to helper function) and gives a reason tied to a shared goal (cleaner test). It invites rather than instructs. 'That's not right' (A) is a criticism without a direction, which stalls the session. 'I would do it differently' (C) expresses preference without explaining what or why. 'You should try another way' (D) is prescriptive without being helpful. The best navigator phrases are questions with a reason: 'What if we X? It would Y.' The driver can then choose to take the suggestion or explain why they prefer the current path.
3 / 5
You spot a potential null pointer exception in the code your pair is writing. How do you raise it diplomatically?
Option D is specific and precise. It flags the concern ('potential issue'), names the exact condition that triggers it ('if the list is empty'), and identifies the exact failure ('null pointer exception') — all without implying your pair made a careless mistake. 'That's a bug' (A) is blunt and slightly accusatory. 'This won't work' (B) is a strong assertion that invites defensiveness. 'I'm not sure about that' (C) raises doubt without giving any information. In pair programming, specific bug observations create useful conversations; vague criticism creates friction. Always name the condition and the consequence.
4 / 5
Your pair is writing code in a way you don't fully follow. How do you ask them to walk you through it?
Option A is the most collaborative phrasing. It opens with a request ('can you talk me through'), explains why ('I want to make sure I follow the approach'), and frames the question as seeking understanding, not challenging the decision. 'Why are you doing it that way?' (B) is grammatically fine but can sound like a challenge depending on tone — in text or at the keyboard, it often lands as skeptical. 'I don't understand what you're doing' (C) is honest but passive; it doesn't request any specific action. 'Explain this to me' (D) is blunt and slightly commanding. The best learning requests in pairing combine the ask with a stated purpose.
5 / 5
You want to suggest writing the failing test before implementing the feature. Which phrase introduces this most effectively?
Option C is specific and persuasive. It proposes a concrete action ('write the failing test first'), times it precisely ('before we implement this'), and gives a clear benefit ('it'll make the expected behaviour concrete'). 'We should do TDD' (A) is an abstract principle, not an actionable suggestion for this moment. 'Let's write tests before code' (B) is closer but still abstract — which test, for what? 'I think testing is important' (D) is a general value statement with no action attached. Effective pair programming proposals are concrete: they name the next action, when to do it, and why it helps this specific piece of work.