Learn

You solved it last month and cannot start it again today

18 October 2026 · A practice plan for the week

You open a problem you solved three weeks ago. You remember the name of the pattern, and you remember that it was not hard. Then the blank file sits there for five minutes. What you kept was the label, not the reason the method works, and the reason is what you need to start.

The weakness

Recognising a solution and rebuilding one are different skills. Reading an old answer feels like knowing it, because every line looks familiar. Starting cold needs the condition that makes the method valid, said before any code. Without it you stall, or apply the method where it does not hold.

This week is built around that one weakness. It does not add new problems until Friday.

What goes wrong, on one small input

Take an original task. Given a list of integers and a limit, return the length of the longest contiguous stretch whose sum is at most the limit.

Most people reach for a sliding window, and it is right on the first input anyone tries.

def longest_within(a, limit):
    best = total = left = 0
    for right, x in enumerate(a):
        total += x
        while total > limit:
            total -= a[left]
            left += 1
        best = max(best, right - left + 1)
    return best

On [2, 1, 3, 1, 1] with limit 4 it returns 2, which is correct. On [5, -4, 1] with limit 2 it also returns 2, but the whole list sums to 2, so the answer is 3. The window dropped the 5 before the -4 arrived to pay for it.

The label was "sliding window". The reason was missing: shrinking from the left is only safe when every value is non-negative, because then a longer window can never have a smaller sum. With negatives allowed, the method needs prefix sums and a different search. If you can recite the pattern but not that sentence, this is your week.

What to say out loud

Before the first line of code, say the method and the condition together: "I will use a sliding window. That is valid only because the values are non-negative, so extending the window never lowers the sum and shrinking it never raises it. Can I assume that?" One sentence: the interviewer hears why it works, and you have checked an assumption instead of guessing it.

When you do not know the condition yet, say that as well: "I recognise the shape. Before I commit, I want to check what makes shrinking from the left safe." That is a pause with a purpose, not silence.

The exercise

Seven days, starting tomorrow. Each day has one check, and you write the result down in one line.

1. Monday: the inventory. List ten problems you solved in the last month. For each, write the method and the condition that makes it valid, from memory, in one line each. Check: how many of the ten conditions could you write? Pick three where you could not. Call them A, B and C.
2. Tuesday: cold start on A. Ten minutes, no code. Say the method and its condition aloud, then the smallest input that would break it if the condition failed. Record yourself on your phone. Check: did you name the condition before you named the data structure?
3. Wednesday: cold starts on B and C, then code A. Same routine for B and C, then write A from a blank file. Check: does A pass an input you built to sit on the edge of its condition, such as a zero, a duplicate or an empty list?
4. Thursday: break all three. For each of A, B and C, change one rule of the task (allow negatives, allow duplicates, make the input empty or a single element) and decide aloud whether the method survives. Check: for each change, can you say why, in one sentence, before you test it?
5. Friday: one new problem, same patterns. Choose a problem you have never seen that uses the method of A, B or C. Spend the first five minutes talking only: method, condition, one breaking input. Check: did your opening minute sound like Tuesday's recording, or better?
6. Saturday: rebuild A, B and C. Blank file, timer, no notes. A was last touched on Wednesday, so this is a real gap. Check: which of the three needed more than twenty-five minutes, and was the slow part the code or the condition?
7. Sunday: the review. Read your seven one-line results. Any problem that failed Saturday goes back on the list for next Wednesday and the Saturday after. Any that passed comes back once, in two weeks. Check: write the condition for every pattern you touched this week on one page. Read that page before the interview, not the solutions.

The order matters more than the volume: condition first, code second, new problems only once old ones rebuild.

Where this fits in Gadfly

Gadfly has four rooms, and in the algorithms room you code in Java or Python. Its catalog has 711 practice problems tagged by the pattern they train. In tutor mode it asks the next question rather than revealing the solution, so "what makes shrinking from the left safe here?" is the kind of question it would put to you; asking for help gives one more step, up to pseudocode, never finished code. Its problem tracker brings a problem you struggled with back on day 1, 3, 7 and 14, and one you found easy back once, depending on how you rate yourself. The plan above works with a notebook and a timer instead.