Clarify & Communicate

The Communication Framework

Interviewers evaluate three axes: correctness, efficiency, and communication. Communication is often the tiebreaker between 'hire' and 'no hire'. A candidate who solves a problem silently is less valued than one who solves a simpler problem while clearly explaining their reasoning.

The framework has four phases, and you should explicitly signal which phase you're in:

• 1. Clarify (2-3 min) — Restate the problem. Ask about edge cases, input constraints, output format. Confirm understanding before writing any code.
• 2. Think Aloud (3-5 min) — Discuss brute force first, then refine. Say 'brute force would be O(n²), but I think we can do better with...'. Write nothing yet.
• 3. Code (10-15 min) — Write clean code while narrating. Say what each block does before you type it.
• 4. Verify (3-5 min) — Walk through your code with the example input. Say 'let's trace through this'. Then discuss edge cases and complexity.

Clarification Checklist

Before writing a single character of code, run through this checklist out loud:

• Input format: Array? String? LinkedList? Can it be null? Empty?
• Size constraints: What's the range of n? This determines whether O(n²) is acceptable.
• Character set: ASCII? Unicode? Lowercase only? Digits only?
• Duplicates: Can input contain duplicates? How should they be handled?
• Output format: Return the value? Index? Modified in-place? Print?
• Modification: Can I modify the input array? Or is it read-only?
• Negative/Invalid: Can numbers be negative? Can input be malformed?
• Time/space priority: Should I optimize for time or space? Typical answer: optimize time first.

Example: for 'Given an array of integers, return indices of two numbers that add up to a target', you should ask: 'Is the array sorted? Can I reuse the same element? What should I return if no solution exists? Are there negative numbers?'

Talking Through Your Approach

Once the problem is clarified, narrate your thought process. A strong structure:

• State the brute force: 'The naive approach would be to check every pair — O(n²). That works but let's see if we can improve.'
• Identify the bottleneck: 'The inner loop is searching for a complement. If we use a hash map we can drop that to O(1).'
• Propose the optimized approach: 'We can trade O(n) space for O(n) time by storing seen values in a hash map.'
• Check for edge cases: 'What if there are duplicate values in the array? The map stores the latest index, which is fine since we just need any pair.'
• Ask before coding: 'Does that approach sound good? I'll start coding it now.'

Problems to Practice On

These problems have ambiguous requirements designed to test clarification skills. Practice describing them out loud with a timer.

Key Points

• Always restate the problem in your own words before coding. This catches misunderstandings early.
• Ask about constraints (input size, duplicates, negatives, nulls) — it shows you think like an engineer.
• Narrate the brute force first, then optimize. Never jump straight to the optimal solution without explaining why.
• Use phrases like 'I'm thinking...', 'One approach is...', 'Let's trace through...' to signal your process.
• If you get stuck, talk about what you're stuck on. Interviewers can't help a silent candidate.