How to Practise So It Transfers

Most people practise in a way that builds recognition of problems they have seen rather than recognition of shapes. The difference shows up the moment an interviewer asks something slightly unfamiliar — which is what interviewers do on purpose.

This lesson is about how to use the rest of the course. Every pattern section that follows has a core-idea lesson and then several classic problems, each worked from the simple approach to the optimised one. You can read them straight through and feel that you understand. That feeling is the trap this lesson is designed to help you avoid.

The failure mode, named

Solving 300 problems by reading the solution after fifteen minutes produces someone who recognises those 300 problems and struggles with a new one. The recall feels like understanding because the solution is genuinely familiar. It fails on a variant because nothing was ever derived.

The repair is uncomfortable, and it works: struggle first, look second, re-derive third. The struggle is not wasted time. It is the part where you try candidate patterns and see why they fail, which is exactly the thinking the interview tests.

The protocol

1. Time-box every problem in phases.

If the 35 minutes run out, read the explanation — then close it and write the solution from a blank file without looking. That last step is where most of the learning happens. If you cannot do it, you have not learned the solution yet; you have read it.

2. Write before you run. Running code after every line hands your thinking to the interpreter. In the interview there is often no interpreter, or you are expected to be confident before you press run. Write the whole function, trace it by hand on a three- or four-element input, then run it. The trace tables in this course's problem lessons show the format.

3. State the complexity aloud, every time. Time and space, in a fixed sentence: "This is O(n) time because each element is visited once, and O(k) space for the map." It is asked straight after you finish coding, and hesitation there reads as doubt about your own solution.

4. Re-solve from scratch after a week. Keep a list of every problem you solved and the date. After about seven days, re-solve the ones you found hard, from a blank file with no notes. A second attempt is much faster when you truly understood the first one, so this costs little and tells you the truth about what you know.

5. Keep a pattern log, not a solution log. One line per problem, like this:

After forty problems you will see the same three or four bugs again and again. Those are your real weaknesses, and you can fix them in an afternoon of targeted practice.

How to use the problem lessons in this course

Each problem lesson opens with the problem statement and the clarifying questions. Stop there. Give yourself the time box before you read "Approach 1". Then read the simple approach and check whether yours matched. Before reading "The key insight", try once more to find the observation yourself — the key insight is the thing you most need to be able to produce alone.

Take the order seriously too. Each pattern section goes from the easiest classic problem to the hardest. The early problems teach the template; the later ones teach where the template bends. Skipping to the hard problems first usually means learning each one as a special case.

The last mile: practise talking

Coding rounds are graded on communication as much as on correctness. The interviewer is writing notes on how you reason, and they can only note what you say. Practise this sequence until it is automatic:

1. Restate and clarify — say the problem back in your own words and ask about empty input, duplicates, negatives and the size of n.
2. Work an example — take a small input and say the expected output and why.
3. Brute force and its cost — state the simple approach and its complexity, even if you will not code it.
4. Name the pattern and why — "the array is sorted and I need a pair, so converging pointers can discard one value per step."
5. Code while narrating — say what each block does as you write it.
6. Test and state complexity — trace your example through the code, try an edge case, then give time and space.

Doing this alone into a recording feels strange at first. It also removes most of the gap between how you perform in practice and how you perform in the room.

Check your understanding

0 of 3 answered

1.You read a solution after 15 minutes, understand it, and move on. Why does this transfer poorly to a new problem?

AFifteen minutes is too long to spend on one problemBYou recognised a solution but never derived one, so a variant gives you nothing to recallCReading solutions teaches the wrong complexity

2.What is the main value of a pattern log over a solution log?

AIt is shorter, so it takes less time to keepBIt lets you copy old solutions in the interviewCIt shows which signals you rely on and which bugs you repeat, so you can fix your actual weaknesses

3.In the interview, when should you state the brute force?

AEarly, with its complexity, before moving to the optimised approachBNever — it signals that you do not know the real answerCOnly if the optimised approach fails