Thinking Aloud While Coding | Pair Programming Exercises

1 / 5

While solving a problem in a pairing session, you're not sure of the best approach.

Which phrase best communicates this to your partner?

Thinking aloud while uncertain requires narrating your thought process rather than reporting a lack of knowledge:

Response	Effect on the session
"I don't know what to do"	Ends the conversation — gives the navigator nothing to build on
"This is too complex for me"	Signals helplessness — blocks collaborative problem-solving
"Can you take the keyboard?"	Disengages — misses the opportunity for shared reasoning
C ✓ — "not 100% sure" + "instinct is" + "think through trade-offs"	Confident uncertainty — keeps the conversation open and productive

Key vocabulary: "instinct", "initial approach", "think through the trade-offs", "before I commit".

2 / 5

You want to propose an alternative approach while your partner is currently implementing.

How do you raise this without derailing them?

A well-formed collaborative proposal has three components:

Component	Phrase example	Purpose
Timing signal	"Before you go further"	Signals the driver to pause before investing more effort
Permission request	"Can I suggest an alternative?"	Non-confrontational — invites rather than imposes
Tentative proposal	"I'm wondering if we could…"	Opens discussion rather than asserting correctness

Key vocabulary: "before you go further", "can I suggest", "I'm wondering if", "would it be worth considering".

3 / 5

You are live-coding in a technical interview and you get stuck.

Which thinking-aloud strategy works best?

In a technical interview, interviewers evaluate thought process, not just correct answers:

Strategy	What the interviewer sees
Silence	No signal — interviewer cannot assess thinking quality
Apologising	Loses time and projects low confidence
Skipping	Signals avoidance — most interviewers prefer a struggled attempt
D ✓ — Narrate problem understanding and options	Shows systematic thinking, edge case awareness, reasoning quality

Key vocabulary: "thinking aloud", "edge case identification", "option enumeration", "reasoning narration", "I'm leaning towards X because".

4 / 5

After writing a function, your pair partner asks: "Can you walk me through what you just wrote?"

Which response best demonstrates good knowledge transfer?

A good code walkthrough covers four elements:

Element	Example from option B
Purpose	"groups events by user ID"
Key implementation choice	"using reduce() instead of a for loop"
Reasoning	"makes the intent clearer"
Edge case handled	"empty list returns an empty object"

Key vocabulary: "walk through", "what it does", "why I chose this approach", "edge case I handled".

5 / 5

You've solved the problem but suspect there might be a better approach you haven't thought of.

How do you communicate this?

The "good enough vs. better" conversation requires separating current status from potential improvements:

Phrase component	What it communicates
"This works and passes all the tests"	Current status is solid — not a bug report
"I'm not fully satisfied"	Professional quality standard — awareness that improvement is possible
"I suspect there might be a cleaner way"	Tentative — not asserting, inviting exploration
"or is this good enough for now?"	Pragmatic — gives the pair permission to move on if appropriate

Key vocabulary: "good enough", "not fully satisfied", "suspect there's a cleaner way", "pragmatic vs. perfectionist trade-off".