The Coding Interview Cheat Sheet for Edge Cases

Back with another one in the series where I break down the parts of interviewing that quietly cost people offers. This one is not about a fancy algorithm. It is about the thirty seconds after you think you are finished, when the interviewer leans in and asks, "what happens if the array is empty?"

The first time that happened to me, I froze. My solution was correct for the example they gave me. It ran, returned the right answer, and I said "I think that's it." Then they asked about an empty input, and I realized I had never once thought about it. I was not being tested on whether I could reverse a linked list. I was being tested on whether I could be trusted to ship code that does not fall over the moment real data hits it.

That gap is where most candidates lose points. Not on the core logic, but on the boundaries around it.

The gap nobody warns you about

You can grind hundreds of problems and still walk into an interview optimizing for exactly one input: the happy path the interviewer wrote on the whiteboard. You get the sample working, dopamine hits, and your brain files the problem as solved. The edge cases were never in the picture because the example never forced you to think about them.

Interviewers know this. Many of them give you a clean example, watch you solve it, then wait to see whether you test your own code or hand it over and hope. Candidates who catch their own bugs before being asked look senior. The ones who need to be prompted look junior. Same algorithm, very different signal.

One of the most underrated coding interview tips is simple: test your own code before you say done. So this post is the cheat sheet I wish I had taped to my monitor, the categories of edge cases that show up over and over, and a short routine for running through them out loud.

The building blocks: categories that repeat

Edge cases are not infinite. After enough problems you start seeing the same handful of shapes. Most edge cases coding interview questions test for are boring on the surface: empty inputs, single elements, duplicates, overflow. Learn the categories and you can generate the specific cases on the spot.

Empty and null input

This is the single most common one, and the one that tripped me up. What does your function do when the array is empty, the string has zero characters, or the pointer is null? Very often the answer is "it crashes on line one" because you index into arr[0] without checking length.

# find_max.py
def find_max(nums):
    best = nums[0]          # IndexError if nums is empty
    for n in nums:
        best = max(best, n)
    return best

Start with the base case: an empty input. State the assumption out loud, then handle it.

# find_max.py
def find_max(nums):
    if not nums:
        return None        # or raise, depending on the contract
    best = nums[0]
    for n in nums:
        best = max(best, n)
    return best

Notice I did not silently pick a behavior. The right move is to ask, "if the input can be empty, what should I return, None or an error?" That one sentence shows you think about contracts, not just code.

Single element

A surprising number of solutions assume there are at least two things to compare. Two-pointer problems, sliding windows, and "find the pair" questions all break when the collection has exactly one element. Walk your loop bounds through a length-one input. If your window needs left and right to be different indices, what happens when they cannot be?

Duplicates

Duplicates quietly break more solutions than any exotic case. If the problem says find two numbers that sum to a target, what happens when the same number appears twice? If you use a set to track what you have seen, you might return the same index twice or miss a valid pair. Ask early: can the input contain duplicates? The answer changes your data structure.

Boundaries and integer overflow

In languages with fixed-width integers, left + right in a binary search can overflow when the array is huge. The classic fix is left + (right - left) // 2. Even in Python, where integers do not overflow, interviewers ask because it signals you know what happens under the hood in Java or C++. Sums of large arrays, products, and factorials are all places where a value silently wraps around and correct-looking logic returns garbage.

Sorted, reverse-sorted, and all-equal input

If you are writing anything sort-adjacent, these three inputs are your stress test. Quicksort with a naive pivot degrades to quadratic time on already-sorted data. An all-equal array can send a two-pointer partition into an infinite loop if your comparisons are careless. You do not have to handle every degenerate case perfectly, but naming them shows range.

Negative numbers and zero

Zero is a troublemaker. Division by zero is the obvious one, but zero also breaks assumptions in prefix-sum and product problems. Negative numbers break anything that assumed monotonic growth. If your solution only ever tested [1, 2, 3], you have no idea what it does with [-1, 0, 2].

Very large input

You will rarely type out a million-element array, but you should say what happens to it. Does your solution stay linear, or did that innocent nested loop make it quadratic? Interviewers care less about the exact number and more about whether you can reason about scale without running the code.

The cheat sheet: a testing routine you run out loud

Here is the actual coding interview cheat sheet. It is not a list of tricks. It is a routine you perform every time, right after you write the last line and before you claim victory. Say it out loud so the interviewer hears you.

# coding_interview_cheat_sheet.txt
1. Empty / null      -> [], "", None. Does line one survive?
2. Single element    -> [x]. Do my loop bounds hold?
3. Two elements      -> smallest case my two pointers need.
4. Duplicates        -> [2, 2, 3]. Same value twice.
5. All equal         -> [5, 5, 5]. Does the loop still terminate?
6. Sorted / reverse  -> best and worst case for ordered logic.
7. Negatives / zero  -> [-1, 0, 3]. Any assumption of positivity?
8. Overflow / bounds -> mid = left + (right - left) // 2.
9. Big N             -> is this still the complexity I claimed?

The trick is not memorizing nine lines. It is building the reflex to walk the list before you hand over the keyboard. Ten seconds of "let me trace an empty input" turns a silent bug into a moment where you look like someone who tests their work.

Putting it together: testing a real solution

It is not enough to solve the problem for the happy path. Say the problem is "return the indices of the two numbers that add up to a target." You write the standard hash-map solution.

# two_sum.py
def two_sum(nums, target):
    seen = {}
    for i, n in enumerate(nums):
        need = target - n
        if need in seen:
            return [seen[need], i]
        seen[n] = i
    return []

Now run the cheat sheet before you say done. Empty input: two_sum([], 5) returns []. No crash. Single element: two_sum([3], 3) returns [] because one number cannot form a pair. Worth saying out loud so the interviewer knows you checked.

Duplicates are the sneaky one: two_sum([3, 3], 6). Because we store seen[n] = i after checking, the second 3 finds the first 3 and returns [0, 1] correctly. If we had populated the whole map first and then looked up, we might have returned [0, 0]. Catching that distinction is exactly the senior signal interviewers want.

Negatives and zero: two_sum([-1, 0, 1], 0) returns [0, 2]. The logic never assumed positivity. Big N: still one pass, still O(n) time and space. That whole check took forty seconds, and it turned "I think that's it" into a narrated proof that the code is correct.

Mistakes I made so you do not have to

I tested only the example input for the first month of practice. The example works by construction, so it teaches you nothing. Now I never use the given example as my test. I invent a smaller, nastier one.

I mutated the input while testing and then could not reproduce the bug. If your function sorts or reverses the input in place, your second test runs on already-mangled data. Copy first when you are probing.

I announced "done" instead of "let me test this." Those are two different sentences to an interviewer. The first says I hope this is right. The second says I am about to prove it is.

What to practice next

Pick problems that punish sloppy boundaries, and run the cheat sheet on each one. Binary search variants are the fastest way to internalize boundary and overflow thinking, because an off-by-one on left or right fails loudly. Sliding window problems force the single-element and empty-window cases into the open. Graph traversals like breadth first search break on disconnected nodes and empty graphs. Linked list reversal and cycle detection break beautifully on null and single-node inputs. Anything with in-place partitioning, like Dutch national flag, is a masterclass in the all-equal and two-element cases.

For each one, do not just solve it. Solve it, then narrate the nine-line cheat sheet against your solution and watch how many latent bugs fall out.

Where this came from

I put this cheat sheet together after losing an offer to exactly the empty-array question above, and I have been drilling it on problems from Levelop, which is where a lot of these interview write-ups start. For the broader picture, the complete coding interview preparation guide covers the full arc, and the 30-minute pacing plan shows where the testing pass should land in your timeline. For the mindset of narrating your work, the piece on talking through a coding interview pairs well with this one. More write-ups live on the Levelop blog.