# The Coding Interview Method

A coding interview tests more than whether you can produce a correct function. The interviewer is scoring **how you get there**: whether you clarify before coding, whether you reason about trade-offs out loud, whether your code is clean, and whether you test it without being asked. A repeatable method makes all of that automatic, so your working memory is free for the actual problem.

![The six steps of the method, from clarifying the problem to testing and analysing the solution](diagrams/01-method-steps.svg)

## 1. What Interviewers Actually Score

Most companies use a rubric with four or five dimensions. The exact names vary, but they map to the same things:

| Dimension | What they look for | What loses points |
|---|---|---|
| **Problem solving** | You find a working approach, then improve it; you explain why it works | Jumping to code; getting stuck silently |
| **Coding** | Correct, readable code with good names and small helpers | Off-by-one errors, copy-pasted branches, cryptic names |
| **Communication** | You think out loud, take hints well, keep the interviewer in the loop | Long silences; arguing with hints |
| **Verification** | You trace an example and test edge cases unprompted | "I think it works" |
| **Complexity** | You state time and space complexity correctly and know where the bottleneck is | Guessing, or forgetting the space used by recursion |

At senior level, the bar on communication and trade-offs rises: you are expected to **drive** the session, not wait to be led.

## 2. The Six Steps

1. **Clarify.** Restate the problem in your own words. Ask about input size, value ranges, duplicates, empty input, sorted or not, and the expected output for ties or "not found".
2. **Examples.** Write one normal example and one or two edge cases *before* thinking about an algorithm. Agree on the expected outputs with the interviewer.
3. **Brute force.** State the simplest correct approach and its complexity in one or two sentences. You usually don't code it, but saying it proves you understand the problem and gives you a baseline.
4. **Optimize.** Find the bottleneck in the brute force (the repeated work) and pick a pattern that removes it: a hash map instead of a nested loop, two pointers on sorted data, a heap for top-k, memoization for overlapping subproblems.
5. **Code.** Write the optimized solution cleanly. Talk while you write, but keep sentences short. Use helper functions for distinct steps.
6. **Test and analyse.** Trace your first example through the code line by line, then run the edge cases. Finish by stating time and space complexity.

```text
"Let me restate: given an array of integers and a target, return the indices
of two numbers that sum to the target. Can there be duplicates? Is there always
exactly one answer? Can I use the same element twice?  ... OK.

Brute force: check every pair, O(n²) time, O(1) space.
The repeated work is searching for the complement. A hash map from value to
index makes that lookup O(1), so one pass gives O(n) time and O(n) space."
```

## 3. Time Budget for a 45-Minute Round

| Minutes | Step |
|---|---|
| 0–5 | Clarify and agree on examples |
| 5–10 | Brute force, then the optimized idea; get a nod before coding |
| 10–30 | Code |
| 30–38 | Trace, test, fix bugs |
| 38–45 | Complexity, follow-up questions, your questions |

If you are still choosing an approach at minute 15, say so and ask a narrowing question. Interviewers would rather give a small hint early than watch you run out of time.

## 4. Recognizing the Pattern From the Problem Statement

Most interview problems are variations of about twenty patterns. Certain phrases are strong signals:

| Signal in the problem | Pattern to try first |
|---|---|
| "sorted array", "pair/triplet with sum" | Two pointers, binary search |
| "contiguous subarray/substring", "longest/shortest window" | Sliding window |
| "subarray sum equals k", "range sum queries" | Prefix sums + hash map |
| "next greater/smaller element", "histogram" | Monotonic stack |
| "top k", "k-th largest", "merge k sorted" | Heap |
| "all combinations/permutations/subsets" | Backtracking |
| "shortest path in unweighted graph/grid", "minimum steps" | BFS |
| "dependencies", "ordering with prerequisites" | Topological sort |
| "connected groups", "merge accounts", "are x and y connected" | Union-find or DFS |
| "number of ways", "min/max cost", "can you reach" with choices | Dynamic programming |
| "minimum value such that X is possible" | Binary search on the answer |
| "intervals", "meetings", "overlap" | Sort by start, then sweep |

## 5. Communicating While You Code

- **Narrate intent, not syntax.** Say "now I shrink the window until it's valid again", not "while left less than…".
- **Flag shortcuts.** "I'll assume the input is valid here; in production I'd validate it." This shows judgment without wasting time.
- **When stuck, think out loud.** Say what you've ruled out and why. That gives the interviewer something to hint against.
- **Take hints gracefully.** Repeat the hint back, connect it to your approach, and move on. Hints are normal; ignoring them is a red flag.

## 6. Testing Like a Senior Engineer

After coding, trace one example by hand with concrete variable values. Then check this list:

- empty input, single element, two elements
- all elements equal, already sorted, reverse sorted
- negative numbers and zero, very large values (overflow in C#/Java `int`)
- the answer at the very first or very last position
- no valid answer

When you find a bug, say what was wrong before fixing it: "the window shrinks one step too late because I check after moving left".

## Common Pitfalls

1. **Coding before agreeing on the approach.** You may solve the wrong problem or an over-complicated version.
2. **Silence while thinking.** Interviewers can't score what they can't hear.
3. **Skipping the brute force.** Without a baseline, your optimization has nothing to be compared against.
4. **Testing by rereading.** Rereading finds typos; tracing concrete values finds logic bugs.
5. **Forgetting space complexity of recursion** (the call stack) and of output buffers.
6. **Over-engineering:** classes and interfaces where one clear function is expected.

## Quick Reference

```text
Clarify → Examples → Brute force (+ complexity) → Optimize (find repeated work)
→ Code (narrate intent) → Trace + edge cases → Time & space

Edge cases: [] · [x] · duplicates · negatives/zero · sorted/reversed · no answer
45 min: 5 clarify · 5 plan · 20 code · 8 test · 7 follow-ups
```