The same seven phases, every time, in the same order. A script frees your attention for the actual problem, and it keeps you moving when the problem is hard.
Two candidates can produce the same final code and get opposite verdicts. The difference is almost always the first ten minutes and the last five. This page is what to do in those minutes.
For a 45-minute slot with one problem. Adjust the middle if there are two.
| Phase | Minutes | Output |
|---|---|---|
| 1. Clarify | 3 | You can restate the problem in one sentence. |
| 2. Example by hand | 2 | One worked case on the board, plus one edge case. |
| 3. Brute force | 2 | Named and costed. Not coded. |
| 4. Optimise | 6 | A pattern named, an approach agreed. |
| 5. Code | 18 | Working code, narrated as you go. |
| 6. Test | 6 | A dry run and the edge cases. |
| 7. Complexity and follow-ups | 3 | Time, space, and one improvement you would make. |
Ask until you could write the function signature with no guesswork. Six questions cover most problems.
| Ask | Why it changes your answer |
|---|---|
| “How large can the input get?” | It picks the target complexity. See Guide 2. |
| “Can the values be negative? Zero?” | Kills or enables the sliding window outright. |
| “Can the input be empty, or have one element?” | Decides your guard clauses, and shows you think about edges early. |
| “Are duplicates possible?” | Changes dedup logic in 3Sum, backtracking, and rotated binary search. |
| “Am I allowed to modify the input?” | Decides between cyclic sort and Floyd on the same problem. |
| “If several answers are valid, does it matter which?” | Decides whether you need a tie-break, as in topological sort. |
Take the given example and actually compute the answer yourself, on the board, slowly. Two reasons: it forces you to understand the rule, and it frequently reveals the pattern before you have looked for it.
Say it. Cost it. Do not write it.
This costs thirty seconds and does three things. It proves you understand the problem. It gives you a correctness baseline for later. And it sets up the optimisation as a deliberate step rather than a lucky guess. Some interviewers will also let you keep it as a fallback if you run out of time, which is far better than nothing.
This is the phase being graded hardest. Make your reasoning audible.
| Move | What to say |
|---|---|
| Name the waste | “The brute force recomputes the same range sums over and over.” |
| Name the pattern | “Contiguous plus an exact target plus negatives, so a window will not work. This is prefix sums with a hash map.” |
| Justify it | “A range sum is a difference of two prefixes, so I can look up the partner instead of scanning for it.” |
| Cost it before coding | “That is one pass, O(n) time and O(n) space. That fits the constraint.” |
| Get agreement | “Shall I code that?” |
Write it the way you would want to read it in a review.
| Do | Why |
|---|---|
| Start with the signature and types | It confirms the contract one last time. |
| Guard clauses first | Empty input, single element. Gets the edges out of the way. |
| Name variables for what they mean | window_sum, not s. first_index, not d. |
| Write the invariant as a comment | One line. It is how you and the reviewer both stay convinced. |
| Narrate the non-obvious lines only | “I look up before recording, so a prefix cannot pair with itself.” |
| Extract a helper when a block gets long | Small named functions read better under time pressure, not worse. |
| Do not | Why |
|---|---|
| Narrate every line | “Now I set i to zero” is noise. Explain decisions, not syntax. |
| Go silent for three minutes | The interviewer cannot score thinking they cannot hear. |
| Golf it | A dense one-liner is harder to debug and harder to grade. |
Leave a TODO and move on | Finish the piece you are on, or say clearly that you are deferring it. |
| Silently change approach mid-way | Say “I have realised this does not handle X, I am switching to Y”. |
Do not say “I think that works”. Prove it, out loud, on the example still on the board. The method is in Guide 4. The short version:
State time and space using the four-part form in Guide 2. Then offer one thing you would do next. Good closers:
heapq.nlargest, which is this same algorithm.”One is plenty. Volunteering an improvement you did not have time to build still demonstrates you saw it.
Being stuck is normal and is not itself a failure. Being stuck and silent is. Work down this list, out loud.
| Move | The prompt to give yourself |
|---|---|
| Shrink it | Solve n = 1, then n = 2, then n = 3 by hand. The recurrence often appears. |
| Re-read the constraints | “n is at most 20” is an instruction. See the hint table. |
| Walk the decision table | Sorted? Contiguous? All paths? Fewest steps? Run down the sixteen triggers. |
| Change the data structure | What if this were sorted? In a hash map? On a heap? In a stack? |
| Invert the question | “Fewest to remove” is “most to keep”. “Rooms needed” is “peak overlap”. |
| Solve a relaxed version | Drop a constraint, solve that, then add the constraint back. |
| Say where you are | “I have the O(n²) version. I am looking for a way to avoid rescanning the left side. Can I think for a minute?” |
A hint is not a penalty. Interviewers hint because they want you to finish. How you take it is what gets scored.
| They say | They mean | Do this |
|---|---|---|
| “What if the array were sorted?” | Sort it. | Take it immediately. “Good idea, then two pointers work because…” |
| “Do you need to recompute that?” | You have a redundant scan. | Find the repeated work. It is usually a cache or a running total. |
| “Walk me through your example again.” | There is a bug and they want you to find it. | Dry-run slowly. Do not defend the code. |
| “Is that the best you can do?” | No. | Say your current complexity, then name the next target. |
| “What happens if the input is empty?” | Your code crashes. | Trace it honestly, then add the guard. |
| Silence after you finish | They are waiting for the complexity. | Give time, space and one follow-up. |
Problem: count the subarrays summing to exactly k. Compressed, but this is the shape.
[1, 2, 3] with k = 3. Subarrays are [1], [1,2], [1,2,3], [2], [2,3], [3]. Two of them sum to 3, so the answer is 2. And an edge case: [0, 0] with k = 0 should be 3, because both singles and the pair all work.”P[j] - P[i] = k, which rearranges to P[i] = P[j] - k. So as I walk along keeping a running prefix, I ask a hash map how many earlier prefixes equal running - k. That is the Two Sum rearrangement. One pass, O(n) time and O(n) space. Shall I code it?”[1, 2, 3] with k = 3: running goes 1, 3, 6. At running = 3 I look for 0, which is in the map once, so count is 1. At running = 6 I look for 3, which is there once, so count is 2. Correct. On [0, 0] with k = 0: running stays 0. First step looks up 0 and finds the seed, count 1, then records, so the map has 0 twice. Second step looks up 0 and finds two, count 3. Correct.”