The coding interview

1 · The process beats the answer essential

Here's the failure almost everyone lives once. You get a problem you actually know. You see the answer in your head, so you put your head down and type it out in silence, fast and correct. You hand it over feeling great — and the rejection email lands two days later. What happened? You solved the puzzle but never showed the interviewer how you got there, and the whole point of the hour was to watch you think. A correct answer with no visible reasoning reads, to the person grading you, almost exactly like a memorized answer you can't repeat on a harder question.

Think of it like a maths exam that says "show your work." The final number is worth almost nothing; the marks are in the steps. A coding interview is the same contract — except the "work" isn't just algebra, it's the engineering conversation: what did you ask before assuming, what trade-off did you weigh, how did you check you were right. The interviewer is a stand-in for your future teammate, and they're answering one quiet question the entire time: would I want this person debugging a production incident next to me at 2am?

So the precise idea this section teaches: a coding interview grades a repeatable process, not a single right answer. That process is five visible steps — clarify → approach → code → test → complexity — and each one is a signal the interviewer is explicitly listening for. Clarifying shows you don't build the wrong thing confidently. Stating an approach first shows you plan before you type. Narrating while you code shows your reasoning is sound even when your syntax slips. Testing shows you don't trust your own code blindly. Stating complexity shows you know what your solution actually costs at scale.

The most common mistake — and it's the one that sinks strong programmers — is treating those steps as ceremony to rush past on the way to the "real" work of coding. They are the real work here. A candidate who talks through a clean brute force, tests it, and names a path to optimize routinely out-scores one who silently produces a slicker solution, because the first candidate demonstrated the exact behaviours the job needs and the second left the interviewer guessing. Master the loop below and you turn interviewing from a lottery of "did I happen to see the trick" into a skill you can reliably execute — even on problems you've never met.

The DSA track taught you to solve the problems. This is the process interviewers actually grade: how you clarify, communicate, and verify — many candidates who reach the answer still fail on process.

The 5 steps, every time

1. Clarify: restate the problem, ask about inputs/edge cases/constraints. Never code immediately.
2. Approach: propose an approach out loud, state its complexity, get a nod before coding.
3. Code: implement cleanly, narrating as you go.
4. Test: walk through an example + edge cases; fix bugs you find.
5. Complexity: state time/space, and whether you could do better.

2 · Think aloud essential

Picture the two minutes that decide the interview. You've read the problem, you're staring at the whiteboard, and your mind is churning through ideas — but from the outside, the interviewer sees a person frozen, saying nothing, for a full silent minute. They can't tell if you're brilliantly working toward the optimal approach or completely lost. And here's the cruel part: because they can't tell, they usually assume the worse of the two. Silence doesn't read as "deep thought"; it reads as "stuck and hiding it."

The fix is a habit that feels unnatural at first: narrate your thinking out loud, continuously, as if you were pair-programming with a colleague who can only hear you, not read your mind. Say the idea before it's polished. Say the trade-off you're weighing. Say the thing you just rejected and why. Compare it to a surgeon in a teaching hospital talking through every cut — the value isn't just the operation, it's making the invisible reasoning visible so it can be followed and trusted.

Why this earns its own section rather than being a throwaway tip: thinking aloud is not decoration on top of solving — it is most of what is being measured. The interviewer is building a model of how you reason, and that model is made entirely of what you say. A sentence like "I could brute force this in O(n²) with nested loops, but if I trade some memory for a hash map I get O(n) — let me do that" does three jobs at once: it shows you know multiple approaches, that you reason about cost, and that you choose deliberately. That single narrated sentence can be worth more than ten lines of correct code.

The mistake to name plainly: going quiet exactly when it's hardest, because that's when you feel most exposed. Counterintuitively, the stuck moments are when narration matters most — "Okay, my first idea doesn't handle duplicates, so let me think about what structure would" keeps the interviewer with you and often lets them drop a hint, whereas silence gives them nothing to help with. Talk through your options even when you don't have the answer yet; a candidate reasoning aloud toward a solution beats one who arrives silently at it. If narrating feels awkward, that's normal — it's a muscle, and the practice ladder and mock-interview exercise later in this page exist to build it until it's automatic.

Silence is the killer. Interviewers hire for how you think, so narrate: "I could brute force this O(n²), but a hash map gets O(n) — let me do that." Even when stuck, voice your options.

3 · Test & state complexity intermediate

Watch the moment that quietly costs candidates the offer. You finish typing, lean back, and say the fatal word: "Done." The interviewer says, "Are you sure? What happens on an empty list?" — and you realize, in front of them, that your code crashes on []. You didn't fail because of the bug; every real codebase has bugs. You failed because you declared victory without checking, and that tells your future teammate you'll push code to production the same way. The candidate who says "let me trace a couple of cases before I call it done" and catches their own bug looks strictly stronger than the one who needed to be caught.

So this section teaches two disciplines that a whiteboard tempts you to skip but the job never lets you: testing your own solution and stating its complexity. Treat testing like a pilot's pre-landing checklist — the plane usually lands fine, but you run the list every single time because the one time you skip it is the time it matters. Before you say "done," you walk through: a normal input, then the edges that break naive code — an empty input, a single element, duplicates, and the largest/smallest values. Trace them by hand or, better, write quick assert lines that pin the behaviour down so a failure stops you loudly instead of passing silently.

The second discipline, complexity, is you answering the question "what does this cost at scale?" before the interviewer has to ask it. State the time and space in Big-O — the analysis skill from DS1 — and, crucially, say whether you think you could do better. "This is O(n) time and O(n) space; I don't think you can beat linear time since every element must be read" shows a maturity that a bare "it works" never will. Volunteering the cost turns a passive candidate into one who owns their engineering decisions.

The mistake to avoid is treating tests and complexity as an afterthought you tack on if there's time left — or worse, waiting to be prompted for them. Offer both unasked. The two-sum example below is deliberately built the way you should build live: the solution, its own asserts covering normal, duplicate, and no-answer cases, and a stated complexity, all in one piece. Read it as a template for the habit, not just for the algorithm — the algorithm is the easy part; the surrounding rigor is what's actually being graded.

Before saying "done," trace an example and the edges (empty, one element, duplicates). Then give big-O — the analysis skill from DS1. Here's a clean solution with its own test, the way you should verify live.

two_sum.pydef two_sum(nums, target):
    """Return indices of two numbers summing to target. O(n) time, O(n) space."""
    seen = {}                              # value -> index
    for i, n in enumerate(nums):
        if target - n in seen:
            return [seen[target - n], i]
        seen[n] = i
    return []

# TEST like you would out loud in the interview:
assert two_sum([2, 7, 11, 15], 9) == [0, 1]     # normal
assert two_sum([3, 3], 6) == [0, 1]             # duplicates
assert two_sum([1, 2], 10) == []               # no answer (edge)
print("all cases pass — O(n) time, O(n) space")

all cases pass — O(n) time, O(n) space

4 · Advanced — recovering when stuck advanced

It will happen to you, and it happens to strong engineers too. Twenty minutes in, the clever approach you were sure would come… doesn't. Your pulse climbs, your mind goes blank, and the temptation is to stare at the board in humiliated silence hoping the trick materializes. Here's the reframe that changes everything: interviewers expect you to get stuck — many problems are designed so you will — and they are not grading whether you get stuck. They're grading what you do next. Getting stuck isn't the test failing; it's the test starting.

Think of it like a hiker who loses the trail. The panicked hiker thrashes deeper into the woods and makes things worse. The trained one stops, gets their bearings from a known landmark, and walks back to solid ground before pushing forward again. Recovery in an interview is that same move: instead of chasing the elusive optimal solution, you retreat to something you know is correct — even if it's slow — and advance from there on firm footing. A working brute force is your known landmark.

The concrete recovery script has a few reliable moves, and saying them out loud is the whole point. State what you know: "The answer clearly involves checking pairs, so a nested-loop brute force would work — it's O(n²), but it's correct." Try a smaller example by hand; shrinking the input from ten items to three often makes the pattern visible. Name the wasted work in the brute force ("I'm re-scanning the same range every time") because the inefficiency you can name is usually the exact thing the optimization removes. Or ask a targeted question — not "I'm stuck," but "would you expect the input to be sorted?", which sometimes unlocks the intended trick.

The mistake this section exists to prevent is the two failure modes that actually sink candidates: panicking (flailing between half-ideas, erasing working code) and going silent (giving the interviewer nothing to help with and nothing to grade). Both read as "can't handle being stuck," which is a terrible signal for a job that is mostly being stuck. Methodical recovery, narrated aloud, can pass an interview even when you never reach the elegant answer — because it demonstrates precisely the resilience the role demands. The callout below states the rule this all builds to: a tested, working simple solution plus a clear path to better beats a half-finished clever one, every time.

Getting stuck is normal; how you recover is graded. Say what you know, try a smaller example, state a brute force and improve from there, or ask a targeted question. Panicking or going silent fails; methodical recovery can still pass.

5 · Professional — the remote/practical variants professional

Here's a trap that catches good algorithmic candidates off guard. They ace the whiteboard rounds, get sent a take-home project, and submit a single file with a working function and nothing else — no tests, no README, a cryptic variable named x, and a crash on the first malformed input. They're baffled by the rejection: "but the algorithm was correct!" The problem is they answered the take-home as if it were a whiteboard puzzle, when a take-home is grading something entirely different — whether the interviewer would merge your code into their repo.

Modern hiring has moved well beyond the standing-at-a-whiteboard format, and each variant grades a different slice of the job. A take-home is a miniature of real engineering: you have time and a real editor, so the bar rises to production standards — clear structure, a docstring, input validation, tests, a note on assumptions and complexity. Treat it exactly like code you'd open a pull request for (the DF and TQ tracks are the standard). A pair-programming round drops you into a shared editor with the interviewer as collaborator, not examiner — here they're watching whether you communicate, ask when unsure, and actually use your tools (docs, a REPL, running the code) rather than performing from memory. A debugging round hands you broken code and grades the systematic loop from TQ4: reproduce the failure first, isolate it, then fix — never guess-and-poke.

The unifying idea is that these formats deliberately test your everyday engineering habits instead of your ability to reinvent an algorithm under pressure. That's usually good news: the habits are more controllable than whiteboard luck, and they're the ones you're building across this whole course. The mistake to avoid is applying whiteboard instincts to a non-whiteboard round — dumping a bare function into a take-home, coding silently through a pair round as if being observed, or randomly mutating a debugging problem instead of reproducing it methodically. Match your behaviour to the format, and let your working habits — clean commits, tests, clear communication — be the differentiator that a raw algorithm never is.

Beyond whiteboard algorithms: take-home projects (treat like real code — tests, README, clean commits: DF/TQ!), pair-programming rounds (collaborate, ask, use the tools), and debugging rounds (reproduce, isolate, fix — TQ4's bug-fix-first). Your engineering habits are the differentiator here.

6 · Tech-lead — the interviewer's seat tech-lead

One day the chair turns around. You get senior enough that instead of sweating on the candidate's side of the table, you're the one running the hour — and most people discover, uncomfortably, that being good at interviews is no preparation for giving them well. A brilliant engineer can be a terrible interviewer: firing gotcha puzzles they happen to know, staring in silence while a nervous candidate spirals, then rendering a "gut feel" verdict that's really just "reminds me of me." Those bad habits don't just misjudge one person — they quietly poison your whole team's hiring bar.

Think of the difference like a driving examiner versus a street racer. The racer is fast, but you'd never want them scoring your test — they'd grade on flash, not on whether you can safely merge onto a motorway. A good interviewer is the calm examiner: they have a consistent rubric, they're measuring the specific competencies the job needs, and they run the same fair assessment for everyone so the results actually mean something. The goal isn't to find people who impress you; it's to predict who will do the job well.

The core skill this section teaches is designing for signal over trivia. Signal is evidence that predicts on-the-job performance: did the candidate clarify before assuming, reason about trade-offs, test their own work, communicate clearly, recover when stuck? Trivia is memorized facts and rare tricks that predict nothing except whether they read the same blog post you did. A strong interviewer picks realistic problems, offers hints to unblock a stuck candidate (then grades the recovery, which is itself signal), works to make the candidate comfortable enough to show their best thinking, and takes calibrated notes tied to concrete evidence rather than impressions. The table below contrasts the weak and strong versions of each move.

There's a mistake even well-meaning interviewers make: mistaking a comfortable, nervous-free candidate for a weak one, or letting an anxious performance mask real ability — which is why the deliberate work of putting someone at ease is part of the craft, not just kindness. And here's the payoff that makes this section matter even if you never plan to lead: understanding the rubric from the interviewer's side makes you a dramatically better candidate. Once you can see exactly what signal each of your moves sends — why clarifying scores, why narrating scores, why self-testing scores — the process stops feeling like a hazing ritual and becomes a game whose rules you can see and play on purpose.

As a lead you'll give these interviews. Good interviewing is a skill: a consistent rubric, signal over trivia, making candidates comfortable enough to show their best, and calibrated notes. Knowing the rubric from this side also makes you a far better candidate.

def first_repeat(nums):
    seen = set()
    for x in nums:
        if x in seen:
            return x
        seen.add(x)
    return None

print(first_repeat([3, 1, 4, 1, 5]))   # 1
print(first_repeat([1, 2, 3]))         # None

def two_sum_sorted(nums, target):
    lo, hi = 0, len(nums) - 1
    while lo < hi:
        s = nums[lo] + nums[hi]
        if s == target:
            return (lo, hi)
        if s < target:
            lo += 1
        else:
            hi -= 1
    return None

print(two_sum_sorted([1, 3, 4, 5, 7, 11], 9))   # (2, 3) -> 4 + 5

def merge(a, b):
    i = j = 0
    out = []
    while i < len(a) and j < len(b):
        if a[i] <= b[j]:
            out.append(a[i]); i += 1
        else:
            out.append(b[j]); j += 1
    out.extend(a[i:])          # the dropped-tail bug lives here if you forget it
    out.extend(b[j:])
    return out

assert merge([], []) == []
assert merge([], [1, 2]) == [1, 2]          # one side empty
assert merge([1, 5], [2, 3, 9]) == [1, 2, 3, 5, 9]  # interleave + tail
assert merge([1, 1], [1]) == [1, 1, 1]      # duplicates
print("all tests passed")

def longest_unique(s):
    last = {}
    start = best = 0
    for i, ch in enumerate(s):
        if ch in last and last[ch] >= start:
            start = last[ch] + 1     # jump the window past the repeat
        last[ch] = i
        best = max(best, i - start + 1)
    return best

print(longest_unique("abcabcbb"))   # 3  ("abc")
print(longest_unique("bbbbb"))      # 1
print(longest_unique(""))           # 0

from collections import defaultdict
import heapq

def top_slow_endpoints(lines, k=3):
    # Given "METHOD /path DURATION_MS" lines, return the k endpoints with
    # the highest total duration as (path, total_ms), descending.
    totals = defaultdict(int)
    for ln in lines:
        parts = ln.split()
        if len(parts) != 3:
            continue                     # tolerate malformed lines
        _, path, dur = parts
        totals[path] += int(dur)
    return heapq.nlargest(k, totals.items(), key=lambda kv: kv[1])

sample = ["GET /a 120", "GET /b 300", "GET /a 200", "bad line", "GET /c 50"]
assert top_slow_endpoints(sample, 2) == [("/a", 320), ("/b", 300)]
print("passed")

def balanced(s):
    pairs = {")": "(", "]": "[", "}": "{"}
    stack = []
    for ch in s:
        if ch in "([{":
            stack.append(ch)
        elif ch in pairs:
            if not stack or stack.pop() != pairs[ch]:
                return False
    return not stack

Knowledge check check yourself