How to use this4 min · 1 of 290

How this course works

Read the module lesson, then work its problems in order, writing code before you read the solution — the order is the method, not a suggestion.

Fourteen patterns account for most of what an interviewer will ask you to do with an array, a tree or a graph. This course teaches those patterns and then gives you problems that stress them, in an order where each one is a small step from the last.

Every problem here is written from scratch — its own scenario, its own examples, its own constraints — and every solution is Python that ran against its test cases before it reached the page. When a page says a solution is correct, the code you are reading is the code that passed.

The shape of a module

A module opens with concept lessons: what the pattern is, when it applies, and the failure mode it exists to prevent. Then comes a problem set, ordered so that the first problem introduces the pattern in its plainest form and the last one bends it.

Work them in order. Problem 7 in a module usually assumes you have felt the thing problem 3 taught you.

How to work a problem page

Each problem page is the same shape, and the order of the sections is the method:

  1. The problem — read it, then close the page and restate it in one sentence. If you cannot, you have not understood it yet.
  2. Hints — collapsed by default. Open one only when you are stuck, and only one at a time. A hint you did not need costs you the practice.
  3. Approach — always starts with the brute force and its complexity, then the single observation that beats it. The observation is the thing worth remembering; the code is just bookkeeping.
  4. Solution — the tested Python, with the cases it passed.
  5. Pitfalls — the two or three ways this specific problem goes wrong. Most of them are off-by-one or an unconsidered empty input.

Write code before you read the solution. Not perfect code — a function that handles the first example is enough. Reading a solution you have not attempted feels like learning and is not; you will recognise the approach next month and still not be able to produce it.

The order of the sections is the method. Everything below the line is the answer, and it only teaches you anything if you crossed the line with code of your own.
The five sections of a problem page, and the line you cross by writing code1The problemRead it, then restate it in one sentencewith the page closed.2HintsCollapsed. Open one only when you arestuck, and only one.3ApproachThe brute force and its complexity first,then the single observation that beats it.4SolutionTested Python, the cases it passed, andits complexity with the reason.5PitfallsThe two or three ways this one breaks:off-by-one, an empty input.Write code before you read onNot perfect code — a function that handlesthe first example is enough. Reading asolution you have not attempted feels likelearning and is not.YOURSAttempt both before you open anythingbelow. A hint you did not need costs youthe practice.THE ANSWERThe observation is the thing worthremembering; the code is bookkeeping. Sayyour own complexity out loud before youread theirs.

Scroll to zoom · drag to pan · 0 fits · Esc closes

What the difficulty chips mean

They describe the idea, not the typing.

  • Easy — the pattern applies directly. If you know the pattern, you are done.
  • Medium — the pattern applies after one transformation: sort first, or search a different space than the obvious one, or track one extra piece of state.
  • Hard — two patterns compose, or the invariant is genuinely subtle.

A hard problem you cannot solve in twenty minutes is not a verdict. Read the insight, close the page, and write it yourself tomorrow.

Complexity is a required answer

Every solution here states its time and space complexity with the reason. Get into the habit of saying yours out loud before you write code, because an interviewer will ask, and because a complexity you cannot justify usually means a solution you do not understand. The next lesson, complexity by counting, gives you a way to produce it in seconds without recalling any rules.

In an interview

You will not be asked "what is the two-pointer pattern". You will be handed a problem whose statement hides one, and scored on whether you find it, justify it, and get the boundaries right under time pressure.

That is why the problems here are phrased as situations rather than as textbook exercises: a warehouse, a playlist, a sensor log. Recognising that a question about delivery vans is really a search-space problem is most of the skill, and it does not develop if every practice problem announces its own category.

The mistake that loses points: naming a pattern and then implementing it without checking that its precondition holds. Binary search needs a monotone predicate; two pointers need an ordering that makes one side's movement safe. Say the precondition out loud before you use the tool.

Check yourself

You have read a problem and recognised the pattern immediately. What do you do before writing any code?

State the complexity you expect to end up with, and the precondition that lets the pattern apply. If the precondition does not hold, you have recognised the wrong pattern — better to find that out now than forty lines in.

You have been stuck for fifteen minutes on a medium problem. Is opening a hint a failure?

No, but opening all three is a waste. Open one, close the page, and try again. The value is in the attempt after the hint, not in the hint.

A solution here runs in O(n log n) and you wrote one in O(n²) that passes the examples. Does it matter?

Yes, and it is worth knowing exactly why: at n = 10⁵, n² is about 10¹⁰ operations — minutes — while n log n is about 1.7 million, well under a second. The examples do not distinguish them; the constraints do.