Testing, edge cases and debugging under pressure

Why testing is part of the answer

Interviewers watch whether you find your own bugs. A candidate who traces the code, spots "this misses the last window" and fixes it calmly scores better than one who writes the same code and says "done". In online assessments, hidden tests check exactly the edge cases that people forget.

An edge-case checklist

Dry runs with a table of variables

A dry run means executing your code by hand on a small input, writing each variable after every step. It is slow, but it finds off-by-one errors that reading never finds. Choose the smallest input that reaches the tricky part, for example a target at the very end of the list.

The table above traces a binary search for 7 in [1, 3, 5, 7] written with while lo < hi and hi = len(nums) − 1. When lo and hi meet at index 3, the last candidate is never checked. The fix is while lo <= hi. Without the dry run, this bug hides until a hidden test finds it.

Off-by-one checks

• range(a, b) stops BEFORE b. If you need the last index, the end is len(nums), not len(nums) − 1.
• In a sliding window of size k, the windows end at indexes k − 1 to n − 1: that is n − k + 1 windows. Count them on a 5-item example.
• With "inclusive" bounds (lo <= hi), move with mid + 1 and mid − 1. With "exclusive" bounds (lo < hi, hi = len), move with lo = mid + 1 and hi = mid. Do not mix the two styles.
• Slices: s[i:j] has j − i characters.

Quick asserts

In an editor that runs code, write three to five one-line checks right under your function. They take a minute and protect you while you change things.

def second_largest(nums):
    first = second = None
    for x in nums:
        if first is None or x > first:
            first, second = x, first
        elif x != first and (second is None or x > second):
            second = x
    return second

assert second_largest([3, 1, 4]) == 3
assert second_largest([5, 5]) is None
assert second_largest([]) is None
assert second_largest([-2, -1]) == -2
print("all tests passed")   # Output: all tests passed

Reading error messages

Read a Python traceback from the BOTTOM: the last line names the error, and the line above it shows where it happened in your code. The common ones in interviews:

• IndexError: list index out of range. An index went past the end, often i + 1 in a loop over range(len(nums)).
• KeyError: a dictionary key is missing. Use d.get(key, default) or collections.defaultdict.
• TypeError: 'NoneType' object is not subscriptable. A function returned None (often a forgotten return) and you indexed it.
• RecursionError: maximum recursion depth exceeded. Missing base case, or recursion too deep for Python; use a loop or an explicit stack.
• UnboundLocalError: a variable is used before it is set inside the function, often a counter you forgot to initialise.

Common mistakes

• Testing only the example from the question. Fix: always add empty, one item and one tricky case from the checklist.
• Changing code randomly until the output looks right. Fix: dry-run, find the exact line where a variable goes wrong, then fix that line.
• Mutable default arguments in Python, such as def f(x, seen=[]), which keep values between calls. Fix: use seen=None and create the list inside.
• Panicking at a red error. Fix: read the last line and the line number, say what it means aloud, and check that line.