Data structures & algorithms · Interview craft
The six-step method
Clarify, examples, brute force, optimise, code, test. This page runs one real problem — Two Sum — all the way through, showing what you say and what you write at every step.
Run the interview step by step →Clarify → Examples → Brute force → Optimise → Code → Test. Same order, every problem. Each step leaves something on the board the interviewer can point at.
01 The idea
A method beats a memory
An interview is not a test of whether you have seen the problem before. It is thirty-five minutes of someone watching how you behave when you have not. Two candidates who know exactly the same things get different results, and the difference is almost never the algorithm. It is that one of them has an order to fall back on and the other has only the problem.
The order does not change with the question. Clarify, examples, brute force, optimise, code, test. Six steps, always the same six, always in that sequence. Because you never have to invent what to do next, you never go quiet — and going quiet is the thing the interviewer actually writes down.
Clarify, examples, brute force, optimise, code, test — in that order, out loud. Every step has to leave something behind: a written constraint, a worked example, a stated complexity. If nothing appeared on the board, the step did not happen.
ContractThe block of constraints you write down in step 1 from the interviewer's answers. Every later idea gets checked against it — including your own optimisation.
BaselineThe brute-force solution, stated with its complexity, before you try to improve anything. It is a correct answer on the board, and it is what "can you do better" is measured against.
Dry runWalking your finished code line by line over your own example, out loud, before you say you are done. Finding your own bug is a signal; the interviewer finding it is a red flag.
02 One problem, all six steps
Two Sum, said and written
The problem: given an array of integers and a target, return the indices of the two numbers that add up to the target. Work it on [2, 7, 5, 3] with target 8. Each step below shows the words you say and the thing that lands on the board. The clock is a thirty-five minute round.
1
Clarify · minutes 0–3You say: "Before I start, can I check a few things? Are the numbers sorted? Can they be negative? Is there exactly one answer, or could there be none? Do you want the indices or the values? Can I use the same element twice? And how large can n get?"nums: int[], unsorted, negatives ok
target: int, exactly one answer
return two indices, i != j
n <= 100000 → O(n^2) is too slow
target: int, exactly one answer
return two indices, i != j
n <= 100000 → O(n^2) is too slow
2
Examples · minutes 3–7You say: "Let me work a small case. 2+7 is 9, 2+5 is 7, 2+3 is 5, 7+5 is 12, 7+3 is 10, 5+3 is 8. So the answer is indices 2 and 3. Now the six-item edge list: an empty array, a single element, duplicates, negatives, all elements the same — and overflow, which does not apply because these are Python ints. One more that is specific to this problem: an input with no valid pair at all."[2, 7, 5, 3], target 8 → [2, 3]
edges: [] [5] [4,4] t=8 [-3,1] t=-2 [3,3,3] t=6
overflow n/a (Python ints) · no pair
edges: [] [5] [4,4] t=8 [-3,1] t=-2 [3,3,3] t=6
overflow n/a (Python ints) · no pair
3
Brute force · minutes 7–11You say: "The obvious solution is every pair: i from 0, j from i plus one. That is O(n²) time and O(1) space. On my array that is six pairs, and the match is the last one it tries. Shall I code this, or go straight to improving it?"for i in 0..n-1:
for j in i+1..n-1:
if nums[i]+nums[j]==target: return [i,j]
6 pairs = n(n-1)/2 · O(n^2) time, O(1) space
for j in i+1..n-1:
if nums[i]+nums[j]==target: return [i,j]
6 pairs = n(n-1)/2 · O(n^2) time, O(1) space
4
Optimise · minutes 11–16You say: "The waste is the inner loop. For every i I re-scan the array to ask one question — does target minus nums[i] exist? That is a lookup, so a hash map answers it in constant time. I trade space for time: O(n) time, O(n) space."repeated question: does (target - nums[i]) exist?
lookup → hash map
seen = {value → index} · O(n) time, O(n) space
lookup → hash map
seen = {value → index} · O(n) time, O(n) space
5
Code · minutes 16–22You say: one sentence of reason per line as it lands. "I keep a dictionary from value to index… for each value I work out what I still need… if it is already there I return the stored index first, because it came earlier… I insert after the check, so an element can never pair with itself."def twoSum(nums, target):
seen = {}
for i, v in enumerate(nums):
need = target - v
if need in seen:
return [seen[need], i]
seen[v] = i
return []
seen = {}
for i, v in enumerate(nums):
need = target - v
if need in seen:
return [seen[need], i]
seen[v] = i
return []
6
Test · minutes 22–29You say: "Let me run it on my own example, then the edges. Empty array returns the empty list. [4, 4] with target 8 returns [0, 1] — correct, and only because I insert after the check; [3, 3, 3] with target 6 gives [0, 1] the same way. That is O(n) time and O(n) space, down from O(n²) and O(1)."i=0 v=2 need=6 miss seen{2:0}
i=1 v=7 need=1 miss seen{2:0, 7:1}
i=2 v=5 need=3 miss seen{2:0, 7:1, 5:2}
i=3 v=3 need=5 HIT → [2, 3] matches step 2
edges: []→[] [5]→[] [4,4]→[0,1] [-3,1]→[0,1] [3,3,3]→[0,1]
i=1 v=7 need=1 miss seen{2:0, 7:1}
i=2 v=5 need=3 miss seen{2:0, 7:1, 5:2}
i=3 v=3 need=5 HIT → [2, 3] matches step 2
edges: []→[] [5]→[] [4,4]→[0,1] [-3,1]→[0,1] [3,3,3]→[0,1]
✓
What the interviewer wrote downAsked about constraints before coding. Worked an example by hand. Gave a baseline with a cost. Found the optimisation by naming the waste, not by remembering a trick. Narrated every line. Tested it before claiming it was done.correct O(n) solution at minute 22 · dry-run by minute 29 · zero silence
Nothing above needed a clever idea. The hash map is one line, and it came out of step 4 by naming the repeated work rather than by recognising the problem. Everything else in those twenty-nine minutes was order — and order is the part you can rehearse.
03 Mechanics
The same six steps, done badly
Students do not lose marks in the left-hand column. They lose them in the right-hand one, usually without noticing. Read it as a list of the things you are about to do in your next mock.
| Step | Done well | Done badly |
|---|---|---|
| 1 Clarify | Four to six questions in ninety seconds, and the answers written down as a constraint block. | "OK, I'll start." You find out that duplicates are allowed at minute twelve, from the interviewer. |
| 2 Examples | One case worked by hand with the expected output written, then the edge list said out loud. | You reuse the interviewer's example and never write down what the answer should be, so there is nothing to test against. |
| 3 Brute force | Stated in three lines with its complexity, offered as a baseline the interviewer can accept or skip. | Skipped because it "feels too easy" — leaving an empty board when the clever idea does not arrive. |
| 4 Optimise | Name the repeated work, then name the structure that removes it. Say which resource you are spending. | Guessing algorithm names — "binary search? two pointers? DP?" — until one sticks or the time runs out. |
| 5 Code | One sentence of reason per line. No gap longer than a few seconds. | Head down, typing, four minutes of silence, then "done". |
| 6 Test | Dry-run your own example, then the edge list, then state the complexity unprompted. | "I think that's it." The interviewer finds the off-by-one instead of you. |
The edge-case checklist — six items, every problem. Empty input, a single element, duplicates, negatives, integer overflow, and everything the same. Say them in step 2 before any code exists, and run them in step 6 against the code you wrote. Saying "overflow does not apply here, these are Python ints" counts too — it shows you checked rather than skipped. The common advice — and it matches most mock-interview feedback you will get — is that an otherwise-sound solution is more likely to break on one of these six than on the main idea.
When you do not know what to do next, say what you do know. "This is O(n²) and the waste is the inner loop" is visible progress even when the fix has not arrived. If you genuinely need to think, name the pause: "give me twenty seconds on the data structure." A named pause is fine. An unexplained one is the thing that gets reported back.
05 Cheat sheet
The six steps on one card
| Step | The sentence that starts it | Clock (of 35) |
|---|---|---|
| 1 Clarify | "Before I start, can I check a few things?" — sorted, negatives, duplicates, size, what to return, what if there is no answer. | 0–3 min |
| 2 Examples | "Let me work a small case by hand." — then the six edge cases, out loud. | 3–7 min |
| 3 Brute force | "The obvious solution is… that's O(n²) time and O(1) space." | 7–11 min |
| 4 Optimise | "The repeated work is… so a hash map removes it. I'm trading space for time." | 11–16 min |
| 5 Code | One sentence of reason per line, spoken while you type. | 16–22 min |
| 6 Test | "Let me dry-run this." — your example, then the edges, then the final complexity. | 22–29 min |
Say the cost before you are askedEvery solution you put on the board gets a time figure and a space figure in the same breath. "Can you do better?" is the question you invite when the cost was left unsaid — and when you did say it, the same question is a compliment rather than a correction.
Silence is the only unrecoverable mistakeA wrong approach you narrate is a conversation, and the interviewer can steer it. A right approach typed in four minutes of silence is a blank sheet to the person grading you.
Two Sum — know all three answersBrute force is O(n²) time, O(1) space. Hash map is O(n) time on average and O(n) space. If the input is already sorted, two pointers give O(n) time and O(1) space. Which one is allowed is a line in the contract.
06 Where & why
When to run all six, and when to compress
The full method spends about sixteen minutes before the first line of code — steps 1 to 4 on the clock above. That is a defensible spend in a thirty-five or forty-five minute round and the wrong spend in a twenty-minute screen with three short questions. What never gets cut, in any format, is step 1 and step 6.
Run all six when…
The round is forty minutes or longerOne open-ended problem and one person watching. What is being graded is your reasoning, not your typing speed, so the reasoning has to be audible.
The problem statement is vague"Design a way to find…" with no function signature given. The constraints genuinely do not exist until you ask for them.
You do not recognise the problemThe method is what replaces recall. Steps 3 and 4 derive an answer from the brute force instead of retrieving one from memory.
The interviewer is silentSilence from the other side is not disapproval. It means they are grading your narration, and the six steps give you something to narrate for the whole round.
Compress it when…
| Situation | Better choice | Why |
|---|---|---|
| A twenty-minute screen with three short questions | Steps 1 and 2, then code and test | There is rarely an optimisation to find, so the marks that are left sit in clarifying the input and testing the output. |
| The interviewer says "we're short on time, just code it" | One sentence of approach, then code | An explicit instruction outranks the method. Ignoring what you were just asked reads worse than skipping four steps. |
| An automated online round with hidden test cases | Steps 2 and 6, wrapped around the code | Nothing you say is recorded. The edge list and the dry run are the only two things that can still earn you marks. |
| You already know the optimal solution cold | Still give the baseline one line | Jumping straight to the memorised answer reads as rehearsed. One line of brute force shows you could have derived it. |
The six steps are not a script to recite. They are an order to fall back on when you do not know what to do next — which, in a real interview, is most of the first ten minutes.
07 Interview questions
Say these out loud
These are asked in almost every round, and the first one is asked in words very close to these. Rehearse the answers until they are twenty seconds each.
Walk me through how you approach a problem you have never seen before.
Six steps, in order: clarify, examples, brute force, optimise, code, test. The first three minutes are questions about the input, with the answers written down as a constraint block. Then I work one small case by hand so I know the expected output, state a brute force with its complexity so there is always something correct on the board, and only then write code — narrating as I go and dry-running it before I say I am done.
What does "can you do better?" actually mean?
It almost always means your solution is accepted as correct and the interviewer wants the optimisation, not that you are wrong. Answer it by naming the repeated work rather than by guessing algorithms. In Two Sum the inner loop re-asks "does target - nums[i] exist?", and a hash map answers that in O(1) on average. If you have not stated a complexity yet, expect this question, because it is what gets asked when the cost was left unsaid.
What are you doing in the first two minutes?
Asking, and writing. Five or six questions about the input — sorted or not, negatives, duplicates, size, what to return, what happens when there is no answer — and every answer goes on the board as a constraint block. That block is what I check every later idea against, including my own optimisation. It is the cheapest two minutes in the round.
What if brute force is all you can come up with?
Say it, cost it, and code it — a working O(n²) solution usually scores better than an unfinished clever one. Then keep working the bottleneck out loud: name the repeated work and ask what structure answers that question faster. The guidance you will hear from almost every interviewer is the same: a shipped baseline plus honest reasoning about the gap reads far better than a good idea and an empty board.
Five minutes in you realise your approach is wrong. What do you do?
Say it immediately, in one sentence, and say what killed it. In Two Sum the sort-and-two-pointers idea dies against a line in my own constraint block: the answer must be original indices, and sorting destroys them. Announcing that costs thirty seconds; defending a dead approach costs the round. Catching your own mistake against something you wrote down reads as a signal, not a failure.
Do you code the brute force, or go straight to the optimal solution?
State the brute force, then ask. "That is O(n²) — shall I code it, or go straight to improving it?" hands the interviewer the decision, and they almost always say improve it. Skipping it silently is the risk: if the optimisation stalls, you have nothing on the board at minute twenty-five.
How do you stop yourself going silent?
Narrate what you know instead of waiting until you know the answer. "This is O(n²) and the waste is the inner loop" is visible progress even before the fix arrives. If you genuinely need to think, name the pause — "give me twenty seconds on the data structure". A named pause is fine; an unexplained one is what gets reported back.
Which edge cases do you check, every time?
Six: empty input, a single element, duplicates, negatives, integer overflow, and all elements the same. I list them in step 2 before writing code and run them against the finished code in step 6. In my experience and in most interview guidance, a solution that is otherwise right is more likely to break on one of those six than on the main idea — in Two Sum, [4, 4] with target 8 is the one that catches people.
Can you ask for a hint?
Yes, once you have shown work. "I have the O(n²) version and I think the bottleneck is the repeated lookup — am I on the right track?" is a normal engineering question and costs almost nothing. Asking before you have stated anything is different, because there is nothing for the interviewer to correct.
How do you finish?
Dry-run your own example line by line, run the edge list from step 2, then state the final complexity unprompted and stop talking. "That is O(n) time and O(n) space, down from O(n²) time and O(1) space" should be the last thing you say. "I think that's it" without the numbers invites exactly the questions you could have pre-empted.
In your Two Sum code, why insert into the map after the check and not before?
Because inserting first lets an element pair with itself. With nums = [4] and target 8, inserting first would put 4 in the map, then find need = 4 already there and return [0, 0] — which the constraint block ruled out with i != j. Checking first and inserting after gets both that case and [4, 4] right, and saying why out loud turns a one-line detail into a visible decision.
08 Practice problems
Drills, not puzzles
These are rehearsals for the method, so write the words down. Say them to a wall, a friend or a recording — the point is that the sentences exist before the interview does.
The first ninety seconds
EasyFor "given a string, return the length of the longest substring with no repeated characters", write down the five clarifying questions you would ask and the constraint block that would go on the board.
Follow-up
At least three of your five have to be questions whose answer changes the code. "Is it case sensitive?" changes the code; "what is a substring?" only changes the conversation.
Show the hint
Work through the problem statement one noun at a time — string, longest, substring, repeated, characters — and for each one write the single thing the sentence has not pinned down. Stop when five of them survive the "would this change a line of code?" test.
Six edges, borrowed problem
EasyFor "given an array of daily prices, return the largest profit from buying on one day and selling on a later day", take the six-item checklist and write, for each edge, the smallest input of that shape and what the function should hand back.
Follow-up
Some of the six do not have an answer you are allowed to decide on your own — those turn into step 1 questions instead of step 2 examples, and the drill is not finished until you have said which ones and why.
Show the hint
Do the six in order and build the input before you argue about the output. Where you cannot state the expected output without making a decision for the interviewer, you have found a clarifying question, not an edge case.
Baseline first
MediumFor "return the k largest elements of an unsorted array", write a brute force in three lines, give its time and space complexity, and then name the repeated work it does.
Follow-up
More than one brute force is defensible here and they do not have the same complexity, so step 3 is not finished until you have said which one you mean and costed that one.
Show the hint
Write the cost as a formula in both n and k before you simplify it; that is where the repeated work becomes visible.
Kill your own idea
MediumFor "the numbers arrive one at a time and you may read the stream only once — return true as soon as two of them have summed to the target", write the constraint block, then say which of the two solutions in this lesson that block rules out, and why.
Follow-up
You still owe step 3 something. "There is no brute force here" is not a finished sentence in an interview — say what you would put on the board instead and what it costs.
Show the hint
Read the step 3 pseudocode one line at a time and ask what each line needs from the input that a single pass never gives you.
Narrate the dry run
MediumWrite out, word for word, the sentences you would say while dry-running the hash-map solution on [5, -2, 7, 1] with target -1 — one sentence per iteration, four sentences total.
Follow-up
You have to state the contents of seen after every iteration, not just "it is not in there", because the interviewer is checking whether you are reading the code or reciting it.
Show the hint
Each sentence needs four facts: the index, the value, what that value still needs, and whether the need is already in the map. Negative targets are where reciting a remembered trace falls apart.
All six on a new problem
HardRun the full method end to end on "given an array, return true if any value appears at least twice" — constraint block, one worked example with edges, a brute force with its complexity, the optimisation with its trade, the code, and the dry run.
Follow-up
Step 4 has more than one defensible answer here and they spend different resources, so the job is to state the trade and let the interviewer choose rather than declare a winner.
Show the hint
Do step 4 the way this lesson does it: name the question the brute force keeps re-asking before you name any data structure. Every candidate optimisation is just a different way of answering that one question once.