Lab 06 — Communication

Goal

Train explicit, structured communication during a coding interview: narrate intent, signpost transitions, ask before assuming, summarize at decision points.

Background Concepts

  • The 6-phase communication structure (see COMMUNICATION.md)
  • “Signposting” — short phrases that tell the listener which phase you’re in
  • “Thinking out loud” without rambling
  • Pause-points and decision-points

Interview Context

In a real interview, silence is your enemy. After ~30 seconds of silence, the interviewer becomes uncertain about your progress. After 90 seconds, they may interrupt — disrupting your thinking. Skilled candidates fill the time with structured narration that costs them little extra cognitive load.

Problem Statement

Record yourself solving 3 problems out loud, applying explicit communication scaffolding. Then transcribe and grade.

Recommended problems (Easy to keep cognitive load low):

  1. Two Sum
  2. Valid Parentheses
  3. Linked List Cycle

For each, follow this script structure:

Phase 1 — Restatement (60–90 sec)

  • “Let me restate to make sure I have it: …”
  • Ask 2–3 clarifying questions explicitly

Phase 2 — Examples (60 sec)

  • “Let me work through an example by hand: …”
  • Construct one trivial and one adversarial example

Phase 3 — Brute Force (60–90 sec)

  • “The simplest approach would be …”
  • “That’s O(…) — clearly not optimal because …”

Phase 4 — Optimization Discussion (90 sec)

  • “I notice ; that suggests …”
  • Explicitly mention the checklist item you matched

Phase 5 — Coding (5–10 min)

  • Narrate intent at each block: “Now I’ll initialize the hashmap, then iterate…”
  • Pause and verify after each block

Phase 6 — Testing & Closing (2–3 min)

  • “Let me trace through the given example…”
  • “Edge cases I should check: …”
  • “Final complexity: …”

Constraints

Time-box yourself: 12 minutes total per problem. If you’re going over, cut narration first, not coding.

Clarifying Questions

For Two Sum:

  • “Can the input be empty?”
  • “Can there be duplicates?”
  • “Is exactly one valid pair guaranteed?”
  • “Can I assume integers, or could they be floats?”

For Valid Parentheses:

  • “Are only () [] {} allowed, or other characters?”
  • “Does an empty string count as valid?”

For Linked List Cycle:

  • “Should I detect the cycle’s start, or just whether it exists?”
  • “Can I modify the list?”

Examples

For each problem, narrate one example by hand before coding.

Initial Brute Force

State and narrate.

Brute Force Complexity

State out loud.

Optimization Path

Narrate the transition: “The brute is O(N^2) because we compare every pair. If I use a hashmap, I can check in O(1) whether target - a[i] is already seen, giving O(N).”

Final Expected Approach

State the final approach as a single sentence before coding.

Data Structures Used

State the data structure explicitly: “I’ll use a hashmap from value → index.”

Correctness Argument

State the loop invariant: “After processing index i, the map contains every (value, index) pair from a[0..i].”

Complexity

State at end: time + space + amortized vs worst case.

Implementation Requirements

You must produce:

  1. Three audio recordings (or written transcripts) of yourself solving the 3 problems with the script structure
  2. Working code for all three (the bar is correct + clean, not optimal at first try)

Tests

For each problem, state aloud:

  • “Smoke test: given example”
  • “Edge: empty input”
  • “Edge: single element / smallest non-trivial”
  • “Adversarial: all duplicates / all negatives / max constraint”

Then trace through at least one example.

Follow-up Questions

After your solution, narrate:

  • “If we wanted all pairs instead of one, we’d …”
  • “If the input were a stream, we’d …”
  • “If memory were tight, we could …”

Product Extension

These same communication patterns scale to design interviews, on-call discussions, and code reviews. The skill is permanent.

Language/Runtime Follow-ups

When narrating, mention language-specific notes:

  • “In Python I’m using dict which is O(1) average; with adversarial input collisions it degrades to O(N).”
  • “I’m using enumerate for index + value to keep the code clean.”

Common Bugs (in communication)

  • Going silent for >60 seconds. Even saying “I’m trying to figure out the right invariant for the inner loop” is enough.
  • Narrating typing instead of intent. “Now I’m typing for i in range(n)…” — bad. “Now I’ll iterate forward to maintain the prefix…” — good.
  • Asking too many questions at once. Drip them; ask after motivation appears.
  • Restating the prompt verbatim. Paraphrase, demonstrate comprehension.
  • Refusing hints when stuck. Frozen silence is far worse than asking for a nudge.
  • Forgetting to summarize at the end. “So the final approach is X with O(N) time and O(N) space; tested on the given example and edge cases.”

Debugging Strategy

After recording, listen back and grade yourself on:

  • Did I signpost each phase?
  • Did I ever go silent for >60 seconds?
  • Did I narrate intent or just typing?
  • Did I summarize at decision points?
  • Did I sound confident or apologetic?
  • Was my code-talk congruent with my code? (i.e., did I narrate one thing while coding another?)

Deliverable

  1. 3 recordings or transcripts (12 minutes each)
  2. Self-grading rubric per recording (the 6 questions above + score 0–10 per phase)
  3. A list of 3 phrases / patterns you’ll reuse next time, and 3 you’ll avoid

Mastery Criteria

  • Recorded all 3 problems
  • Self-graded honestly (most candidates score 4–6/10 on first attempt — that’s expected)
  • Identified at least 3 specific things to improve
  • On a re-recording of one problem, scored at least 2 points higher
  • No silent gaps > 30 seconds in your final recording
  • Narration tracked code 90%+ of the time (no divergence)