Coding Interview Edge-Case Checklist: 30 Edge Cases You Should Say Out Loud

February 9, 2026

TL;DR

Most interview “bugs” aren’t the main idea—they’re one missed edge case or one unstated assumption.

If you say edge cases out loud before you code, you sound more reliable and you invite the interviewer to confirm rules early.

Use one simple talk track: boundaries, duplicates/ordering, and one worst-case performance check—then pick the 3–5 cases that actually match the constraints.

Why saying edge cases out loud changes the vibe

Edge cases aren’t trivia. They’re a signal.

When you verbalize a few break tests early, you’re doing two interview-relevant things at once: (1) proving you think about correctness, and (2) making it easy for the interviewer to confirm constraints before you commit to the wrong path.

If you’ve ever felt yourself “spiral-debugging” mid-interview, it usually started with a missing assumption you could’ve caught in ten seconds.

A one-sentence talk track that sounds natural

Before you write code, try this:

“I’ll sanity-check boundaries, duplicates or ordering, and one worst-case performance case—just to make sure the logic holds under the constraints.”

Then you name three to five tests that actually apply.

One table: small category scripts you can reuse

Category	Say this out loud	Example break test to name
Boundary inputs	“I’ll check the smallest valid input.”	empty input / single element
Value range	“I’ll confirm value range and signs.”	negatives / very large values
Duplicates	“I’ll check what happens with repeats.”	many duplicates clustered together
Ordering	“I’ll check adversarial ordering.”	sorted vs reverse-sorted
Termination	“I’ll confirm the loop always progresses.”	pointers stall / window never moves
Graph shape	“I’ll check disconnected and cyclic cases.”	isolated nodes / cycles
Parsing	“I’ll confirm formatting assumptions.”	leading spaces / empty tokens
Performance	“I’ll sanity-check worst-case size.”	max input size with worst ordering

Use this as a reminder of how to talk, not as something to recite.

The 30 edge cases checklist

You don’t need all 30. You need the ones that stress your approach under these constraints.

Boundaries & sizes

empty input (empty array/string/list)
single element
two elements (smallest non-trivial case)
very large input size (stress time/memory)
off-by-one around thresholds (k, index bounds, inclusive/exclusive)

Value ranges & numeric traps

negative values when you assumed non-negative
zeros (multiplication/division, “falsy” checks)
very large values (overflow risk in some languages)
sentinel values (INT_MIN/INT_MAX) interacting with comparisons
ties / equal comparisons (especially when sorting or selecting)

Duplicates & frequency logic

all values equal
duplicates clustered together
duplicates at boundaries (first/last)
repeated keys in maps (update vs overwrite)
missing keys / default values (“not found” semantics)

Ordering & adversarial layouts

already sorted input
reverse sorted input
nearly sorted input (looks random but isn’t)
alternating pattern (high-low-high-low)
periodic / repeated segments (patterned sequences)

Pointers, windows, termination

pointers cross quickly (termination correctness)
pointers stall on duplicates (needs movement rule)
window never grows (guard condition too strict)
window always grows (performance under monotonic growth)
“exactly one” vs “at most / at least” confusion in window constraints

Graphs, trees, traversal shape

disconnected components
cycles (avoid infinite loops)
self-loops (node points to itself)
skewed tree (deep recursion)
missing children / null nodes during traversal

DP, recursion, state validity

unreachable states (initialization correctness)
multiple paths to same state (min/max correctness)
repeated subproblems (memoization necessity)
base case not covered (recursion correctness)
deep recursion (stack depth risk)

Strings & parsing assumptions

leading/trailing spaces
multiple consecutive separators (spaces/commas)
casing rules (case-sensitive vs insensitive)
Unicode / non-ASCII characters (normalization assumptions)
empty tokens after split (parsing edge)

Performance & resource limits

worst-case arrangement for time complexity
worst-case memory growth (maps/sets/arrays)
recursion depth limits
large intermediate allocations (copies, slices)
repeated conversions (string concatenation traps)

Using the checklist in real time

Start by locking constraints: can input be empty, are negatives possible, can duplicates exist, what’s max size?

Then pick a few cases and connect them to why they matter:

“My invariant is X, so the risky case is when Y violates X.”
“This approach assumes Z, so I want to test where Z fails.”

Finally, say one quick performance line: “I’ll also sanity-check worst-case size so the complexity fits the constraints.”

If you want a clean, natural complexity talk track that pairs well with edge cases, link this: Big-O in interviews: a natural time/space script.

30-Min Mock Interview Scenario (Question → Answer Template → Practical Example)

Interviewer:

“You’re given an array of integers nums and an integer k. Return the length of the longest contiguous subarray that contains at most k distinct values.”

Candidate answer template (what you say out loud)

(1) Clarify → lock constraints (10–20s)

“Quick sanity checks: can nums be empty? can values be negative? what’s the range of k—can it be 0 or bigger than n? and are we returning length only, not the subarray itself?”

(2) Commit → name approach + invariant (15–25s)

“I’ll use a sliding window with a frequency map.

Invariant: the window always contains ≤ k distinct numbers. If it ever exceeds k, I shrink from the left until it’s valid again.”

(3) Break tests → 3–5 edge cases before coding (15–25s)

“I’ll sanity-check:

empty input ([])
k = 0 (answer should be 0)
all duplicates ([1,1,1], k=1)
k >= distinct(nums) (whole array)
worst-case pattern like alternating values that forces frequent shrink.”

(4) Complexity line (5–10s)

“Each pointer moves at most n times, so time is O(n), space is O(k) for the map.”

If you want the exact spoken phrasing for time/space, I keep it consistent with: Big-O in interviews: a natural time/space script.

Practical walk-through (how it sounds in a real round)

Example: nums = [1,2,1,2,3], k = 2

“I’ll walk one run quickly.

Start l=0, expand r and track counts.

Window [1,2,1,2] has distinct {1,2} so length is 4.

When I add 3, distinct becomes {1,2,3} which breaks the invariant.

So I shrink from left: remove 1 → still 3 distinct, remove 2 → still 3, remove 1 → now {2,3} valid again.

At every step I update the best length.”

Interviewer follow-up (the moment people spiral):

“What breaks if k=0 or the input is empty?”

Calm answer (no restart):

“For k=0, the invariant says the window must contain 0 distinct values, so best length is 0.

For empty input, we just return 0 immediately.”

If you freeze on the “say it cleanly” part, templates help more than more practice problems: Explain code in interviews: templates.

How you practice this without becoming dependent

After you attempt, you can ask AI one high-signal prompt:

“Given my approach + invariant, generate 5 break tests that would fail my current implementation.”

That’s the exact “coach not crutch” loop described here: LeetCode assistant: use AI as an interview coach.

And if you want a single place to pull targeted prompts (coding + design + behavioral) without guessing what to practice next, use the hub: Interview Questions & Answers.

For the “what to practice” layer, IQB can reduce decision fatigue: IQB interview question bank.

How AI helps without becoming a crutch

AI is great at generating break tests—after you attempt.

A high-signal request: “Given my approach, generate tests that would fail it, and explain why.”

Then you do the learning: connect each failing test to a missing assumption or violated invariant.

For the “use AI like a coach” workflow, anchor here: LeetCode assistant: use AI as an interview coach.

And if you want the broader ecosystem view, use the guide: Beyz AI coding interview assistants guide.

If you’re using tools during practice, keep them lightweight—more like cue cards than scripts. Some candidates use a small structure layer (for example, Beyz real-time interview assistant) to stay calm while narrating, but the goal stays the same: you do the thinking, the tool helps you verify.

For curated prompts across coding + system design + behavioral, start from the hub: Interview Questions & Answers.

If you want a “what to practice next” layer, IQB can reduce decision fatigue: IQB interview question bank.

References

Frequently Asked Questions

Why do interviewers ask about edge cases in coding interviews?

Edge cases show how you think about correctness. Interviewers listen for assumptions, failure modes, and whether you can defend your approach under constraints.

When should I bring up edge cases during an interview?

After you state your approach and before you implement. Three to five high-signal break tests is usually enough to confirm constraints and avoid painful mid-code rewrites.

How many edge cases should I mention out loud?

Aim for three to five: one boundary, one duplicates/ordering trap, and one performance stress case. Add more only if the interviewer pushes.

How do I avoid sounding like I’m reading a checklist?

Use a category line, then name one or two cases that actually apply. The checklist is for your brain—your delivery should sound like you’re reasoning in real time.

Can AI help me find edge cases without making me dependent?

Yes, if you attempt first. Use AI to generate break tests that would fail your current plan, then explain why each test matters. Over time, you should need less help to name the common ones.