Foundations

Common mistakes

Most failed practice sessions do not fail because the person had never heard of the right data structure. They fail because a correct idea was implemented with a boundary error, tested only on the sample, or replaced at the last minute by a pattern the person could name and not justify. This page collects those mistakes in one place, with pointers back to the guides that slow down and do the repair. It is a review, not a new technique.

None of the examples are assessment questions. If your goal is a list of recent prompts, this site will disappoint you on purpose. The format guide explains why a list like that is the wrong study plan even when someone offers it to you.

Reading the prompt as if it were a genre

You have solved "find a pair that sums to a target" before, so you stop reading when those nouns appear. The prompt asked for every pair, or for the earliest index, or for a contiguous subarray, and your memory answered a different question. The fix is the three-line comment from the time management page: input, output, and what the function must not do. Write it before the approach. If you cannot, you are not slow. You are early.

A particular version of this mistake is ignoring a constraint. "n can be 10 to the fifth" is an instruction about complexity. An n-squared double loop may still be the right first draft on paper, and it is the wrong thing to submit unchanged. Say the bound out loud. Then decide.

Off-by-one and the sample that hides it

Samples are usually the happy path. They rarely sit on the boundary where your index walks off the array or your comparison uses the wrong equality. The average bug on the debugging page passes an empty list and fails the list that contains only non-positives. Build the second test yourself.

Binary search concentrates this mistake. Mixing a lower-bound loop with a mid - 1 copied from an exact-match loop returns the wrong index and still looks like a binary search. The binary search page keeps one loop shape for a reason. Pick it, write the invariant, and stop editing operators until an assert forces you to. An infinite loop is the same family: left and right do not shrink when mid is computed and then not excluded. If a search runs forever, print the range. Do not add a cache.

Here is a tiny original repair. The function should return the last index of target, or -1. The broken version returns the first index because it keeps searching left after a match and then returns too early in spirit: it never looks right. The fixed version searches the right half while the match is still a candidate.

def last_index(nums: list[int], target: int) -> int:
    left, right = 0, len(nums) - 1
    answer = -1
    while left <= right:
        mid = (left + right) // 2
        if nums[mid] == target:
            answer = mid
            left = mid + 1
        elif nums[mid] < target:
            left = mid + 1
        else:
            right = mid - 1
    return answer


assert last_index([1, 2, 2, 2, 3], 2) == 3
assert last_index([1, 2, 2, 2, 3], 4) == -1

The list must be sorted, or the function is not a search. The assert uses duplicates on purpose. A sample of [1, 2, 3] looking for 2 would pass even if you returned the middle index by luck. Duplicates are the mean example. Time is logarithmic. Space is constant. The two pointers page has the cousin of this bug: left <= right when a pair must be two different indexes.

Maps, windows, and graphs

In a pair-sum map, inserting the current value before the lookup lets a single half-target pair with itself. Lookup, then insert. The arrays and hashing page makes you assert the two-copies case separately so the bug has somewhere to show up.

A sliding window that remembers the previous index of a value must not jump left backward. Old indexes outside the window are stale. The sliding window page's condition is last_index[code] >= left. Drop the comparison and a repeated value from far behind the window will corrupt left.

Graphs: a missing visited set is not a style issue. It is an infinite loop as soon as a cycle exists. Mark nodes when you enqueue them for BFS, and when you enter them for DFS. The graphs drill asks you to add a cycle on purpose. If you only test trees, you will not notice the set is missing, which is why the trees page tells you to switch pages when the structure might not be a tree.

Naming a pattern you cannot justify

"This is greedy" is not an explanation. The greedy page shows a soonest-ending rule that survives a swap argument and a soonest-starting rule that fails on three meetings. If you cannot tell the argument or the counterexample, say you are trying a heuristic. Interviewers can work with that. They cannot work with a wrong proof delivered confidently.

"This is DP" has the same failure mode. A table whose cells you cannot define is a place to hide an off-by-one. The dynamic programming page asks you to reject the table when a single pass or a greedy choice is enough. Using a table for a fixed window sum is the tell: you paid for a bigger structure and got a worse constant, and you still might get the index wrong.

Heaps have a quieter version. Sorting n items is allowed when n is small or when you need a total order anyway. A heap of size k is the tool when k is small or the input is a stream. Reciting heapq without that sentence is costume. The heaps page tells you to time both once so the costume is harder to put on.

Stories and designs

Behavioral answers fail in a few repeatable ways. The situation takes three minutes and the action takes one sentence. "We" hides what you did. The result is an adjective. A teammate is described as careless. The STAR guide is the repair: one real story, two minutes, a checkable result, an alternative you rejected. Do not borrow the fictional mailer story from that page and tell it as yours. Fictional practice is fine. Fictional employment is a different act.

Design answers fail when the diagram cannot survive "this box is down" or when every box is a product name. The system design page uses a tiny flag service so you can practice deleting unnecessary boxes. If your sketch needs a number, label the number as given or as guessed. An unlabeled number will be treated as a requirement, and you will be asked to design to it.

Leaks and last-night cramming

The mistake that sits under the others is studying a supposed list of exact questions. It trains panic and recognition instead of the ritual. It also crosses a line this site will not help you cross. If you have spare energy the night before, redo one drill from a pattern you already started, sleep, and reread the three lines you wrote about your own most common bug. The four-week plan is built around that kind of repetition.

A short personal checklist beats another tab. Before you submit a practice solution: did I restate the output, did I test an empty input and a boundary, did I quote a complexity that matches the code, and can I point at the line that would fail if the structure contained a cycle or a duplicate? If any answer is no, you are not done. That checklist is the whole page, compressed into something you can use when you are tired.