Practice like it is the job

Practice like it is the job

You have the patterns. Skill now comes from reps under realistic conditions, and the shape of a rep matters more than the number of them.

A rep that actually builds skill looks like this.

1. Pick by topic, not at random. Weakest pattern first, and work a batch of problems on that one topic until the trigger phrase is automatic.
2. Time-box 25 minutes with no hints. Restate the problem, write down the trigger phrase, name the pattern out loud, then code.
3. Stuck at 25 minutes? Read a hint, not the solution. Stuck at 35? Read the full explanation, close it, and re-implement from memory.
4. Log a one-line note, such as "missed that sorted input means two pointers". Your miss-log is your syllabus.
5. Re-solve every miss 3 days later. A problem is only done when you have solved it cold, twice.

Steps 3 and 5 are the ones people skip, and they are where the learning is. Reading a solution feels productive and teaches recognition rather than recall.

The one-line note is also what keeps the practice pointed. Without it you drift toward the patterns you already like.

The interview-day protocol

A four-week baseline that has carried many people through interviews. Week 1 is searching, sorting, and two pointers. Week 2 is sliding window, recursion, and backtracking. Week 3 is BFS, DFS, and greedy. Week 4 is DP plus mixed random sets.

One or two problems a day beats ten on Sunday, because the spacing is what moves a pattern from recognized to recalled.

In the room, run this script every single time.

1. Restate the problem and invent a small example.
2. Ask about edge cases: empty input, duplicates, sizes.
3. Name the brute force and its Big-O in one sentence.
4. Spot the trigger, name the pattern, and state the target complexity.
5. Code it, narrating as you go.
6. Trace your example through your code before saying you are done.

Step 3 is the one candidates skip when they think they know the answer, and it is cheap insurance. Stating the brute force proves you understood the problem, and it gives you something to submit if the clever solution stalls.

Step 6 catches the off-by-one that would otherwise be found by the interviewer, which is a much worse way to find it.

Interviewers pass people they can follow. The narration is not decoration, it is the deliverable.

Read one hint and keep going.

If you are still stuck at around 35 minutes, study the full solution, close it, re-implement from memory, and then re-solve the problem in 3 days.

The two failure modes are unbounded struggle and outright copying. Struggling for two hours on one problem buys very little, and reading a solution straight through teaches recognition rather than recall.

The graded escalation is what avoids both. Hint, then explanation, then closed-book re-implementation, then a spaced re-solve, each step forcing retrieval rather than review.

Closing the tab before re-implementing is the part that does the work. Typing along with a visible solution feels like learning and produces almost none.

The miss-log entry is the compound interest, since it turns a single stuck problem into a pattern you deliberately drill later.

longest_run

The longest streak of consecutive integers by value, not by position, in O(n).

def longest_run(nums):
    values = set(nums)
    best = 0
    for n in values:
        if n - 1 in values:
            continue
        length = 1
        while n + length in values:
            length += 1
        best = max(best, length)
    return best

print(longest_run([100, 4, 200, 1, 3, 2]))
print(longest_run([]))

Output

4
0

The trigger from the 11-1 checklist is the membership question, which points at a hash set from lesson 1-1. Sorting also solves this and costs O(n log n), so the set is what hits the O(n) target.

The run-start check is the whole trick. Counting upward from every number would be O(n²) on a long streak, and skipping any n whose predecessor exists means each streak is walked exactly once.

That makes the total work linear despite the nested while, which is the amortized argument from lesson 4-2. Each value is visited once as a candidate start and at most once inside a streak walk.

Iterating over values rather than nums handles duplicates for free, since the set has already collapsed them.

For [100, 4, 200, 1, 3, 2] the streak is 1, 2, 3, 4, giving 4, and the isolated 100 and 200 each count as runs of length 1.

The empty input returns 0 because best starts at 0 and the loop never runs, which is the kind of edge case step 2 of the protocol is for.

DP, from lesson 9-3.

Greedy's biggest-coin-first rule fails on [1, 3, 4] making 6, returning three coins where 3 + 3 uses two.

That failure is diagnostic rather than incidental. It means the choices interact, since taking the 4 changes what the remaining amount can do, and interacting choices are DP's trigger row in the checklist.

The DP answer states its two sentences and then writes itself. table[a] is the fewest coins making amount a, and table[a] = 1 + min(table[a - c]) over every coin c that fits.

You have now seen the same problem defeat one pattern and yield to another, and that judgment is the real outcome of this course. The patterns are the easy part, and knowing which one the problem's structure permits is the skill.

Go and use it. Pick a weak pattern, run the protocol from this lesson, and keep the miss-log honest.