Technical Interview Practice

Technical Interview Practice

Being a strong engineer and performing as one under a 45-minute clock with a stranger watching are two different skills. Technical interview practice is the deliberate training of the second skill. This lesson treats it as a discipline with its own methods, not as "grind more LeetCode."

1. Intuition — the problem it solves

In an interview you operate under three simultaneous constraints that never appear in your day job: a hard time limit, a live audience, and the requirement to narrate your thinking out loud. Your real-world competence leaks through only if you can think while talking, recover from a wrong turn without panicking, and finish something runnable. Practice exists to convert competence into observable competence under those constraints.

The failure mode it prevents is the "silent expert": an engineer who solves the problem in their head, writes correct code, but gives the interviewer no signal about how they got there — so a hire signal never forms. Practice trains the externalization, not just the answer.

2. Precise definition / how it works

Effective practice is spaced, simulated, and feedback-driven. Three components:

• Simulation: a full mock under real conditions — a 45-min timer, a shared editor with no autocomplete/no test-runner, speaking aloud the entire time (record yourself or use a peer). Solving on paper in silence does not transfer.
• Structured retrieval: practice by pattern, not by problem count. For coding: sliding window, two pointers, BFS/DFS, binary search on the answer, heaps, union-find, DP on subsequences/intervals, topological sort. Learn to recognize which pattern a prompt maps to — that recognition is the interviewed skill.
• Deliberate feedback: after each mock, log what broke — did you clarify requirements, state complexity, handle edge cases, test before declaring done? Practice the weakest link next, not your favourite pattern.

A repeatable in-room protocol makes the narration automatic under stress:

1. Clarify   - restate problem, ask about input size, ranges,
             duplicates, empty/null, sorted?
2. Examples  - 1 normal + 1 edge case, walk them by hand
3. Approach  - brute force first, state its O(); then optimize,
             state the target O() BEFORE coding
4. Code      - narrate as you type, small helper fns
5. Test      - dry-run the edge case line by line
6. Analyze   - final time/space, mention trade-offs

3. Concrete example — narration you can actually say

Prompt: "Return the length of the longest substring without repeating characters." Here is a verbatim script that hits every protocol step:

"Quick clarification — is this ASCII or full Unicode, and can
 the string be empty?" [empty -> return 0]

"Example 'abcabcbb' -> 3 ('abc'); 'abba' -> 2, which exposes the >= start guard."

"Brute force is check every substring, O(n^3). I can do better
 with a sliding window and a last-seen map: O(n) time, O(k)
 space where k is charset size. I'll code the window."

def length_of_longest(s):
    last_seen = {}          # char -> most recent index
    start = 0               # left edge of window
    best = 0
    for i, ch in enumerate(s):
        if ch in last_seen and last_seen[ch] >= start:
            start = last_seen[ch] + 1   # jump left edge
        last_seen[ch] = i
        best = max(best, i - start + 1)
    return best

"Dry run on 'abba': at second b, start moves to 2; at the last a, last_seen[a]=0 but 0 < start, so I don't move back — that >= start guard is the subtle bug most people miss. Final answer 2. Time O(n), space O(min(n, charset))." Calling out the guard is exactly the kind of insight that separates a senior signal from a rote one.

4. When to use / when NOT — vs the alternatives

Simulated practice is the right tool when the format is unfamiliar or high-stakes (senior loops, unfamiliar company style). Weigh it against the alternatives:

• vs. raw problem grinding (volume of LeetCode): grinding builds pattern breadth but not narration, time management, or recovery. Do a base of grinding for coverage, then switch to mocks once you can solve mediums — mocks have far higher marginal value near the interview.
• vs. reading solutions: reading feels productive but is recognition, not recall. Use it only to learn a new pattern; never as your last-mile prep, because the interview tests generation under pressure.
• vs. real interviews as practice: "just interview a lot" burns limited, high-value opportunities and gives thin feedback. Use throwaway companies sparingly for realism; do the volume in mocks where you can pause and dissect.
• When NOT to over-invest: if you're already interviewing weekly and passing, more drilling has diminishing returns — shift effort to system design and behavioral, which gate senior offers more often than a missed DP problem.

5. Pitfalls / what interviewers probe

• Coding before clarifying. Jumping straight to code reads as junior. Interviewers deliberately leave ambiguity (unsorted? duplicates? negatives?) to see if you surface it.
• Silence. Long quiet stretches give zero signal. They probe by asking "what are you thinking?" — pre-empt it by narrating.
• Declaring done without testing. Not dry-running your own code is a top red flag. Always walk the edge case line by line before saying "done."
• Wrong or hand-waved complexity. They will ask "what's the time complexity?" and then "can you do better?" Know the target O() before coding.
• Rigidity under a hint. A hint is a test of coachability. Integrate it visibly; arguing or ignoring it tanks the signal.
• Memorized-solution smell. Reciting an optimal answer with no build-up invites probing variants ("now return the substring itself," "stream the input") that expose shallow understanding.

Key takeaways

• Practice trains observable competence — thinking out loud under a clock — not just the ability to solve.
• Make it simulated, spaced, and feedback-driven; log your weakest step and drill that next.
• Run a fixed protocol: clarify → examples → approach (state O first) → code → test → analyze, narrating throughout.
• Organize by pattern recognition, not problem count; mocks beat raw grinding near the interview.
• Interviewers probe clarifying, silence, self-testing, complexity, and coachability — pre-empt each deliberately.