Home / Blog / Coding Interview Edge Cases Checklist

Coding Interview Edge Cases Checklist

Published 2026-09-25 · Luna Interview

Most coding interview bugs are not exotic. They are edge cases you forgot to name before you typed. Interviewers notice whether you reach for a checklist—or only fix edges after they prompt you.

Use this coding interview edge cases checklist as a pre-flight and as your dry-run script before you say “done.”

Why edge cases are a signal

Handling edges shows:

• You understand the full contract, not only the happy sample
• You can test without being spoon-fed
• You communicate risk (“I’m going to verify empty and duplicates”)

Unprompted testing ranks as senior. Waiting for “what about empty?” ranks as junior—even if your core algorithm is fine.

Universal checklist (run every problem)

Before or while planning, scan:

1. Empty input — [], "", null/None if the language allows
2. Single element — length 1 arrays, single-node trees
3. Two elements — off-by-one in windows and pairs
4. All equal values — duplicates everywhere
5. Already sorted / reverse sorted — sorting and two-pointer assumptions
6. Duplicates — allowed or not; stable order requirements
7. Negatives / zero — especially products, windows, binary search bounds
8. Min / max bounds — Integer overflow; INT_MIN negation traps
9. Output requirements — any order vs sorted; in-place vs new structure
10. Impossible / no answer cases — return value convention

Write the ones that apply as a tiny list on the pad. Checking them verbally later is faster when they are visible.

Category add-ons

Arrays / strings

• Leading / trailing spaces or zeros
• Unicode vs ASCII (if relevant)
• Overlapping windows; inclusive vs exclusive indices
• Subarray vs subsequence confusion

Binary search

• Left/right inclusive conventions
• Infinite loop when lo/hi do not move
• First vs last occurrence
• Search on answer space empty ranges

Linked lists

• Empty list; single node
• Cycles (if possible)
• Even vs odd length for mid-pointer tricks
• Dummy head needs for head deletion

Trees

• Empty tree; single node
• Skewed left/right (recursion depth)
• Duplicate values if BST
• Not a BST when you assumed it was

Graphs

• Disconnected components
• Self-edges; parallel edges
• Cycles in directed vs undirected
• 0-index vs 1-index nodes
• Unreachable targets

Heaps / top-k

• k larger than n
• Ties in frequency or value
• k = 0 or k = 1

Dynamic programming

• Base cases off-by-one
• Empty string / zero capacity
• Reconstruction path when multiple answers exist

You will not recite every bullet live. You will pick the three that threaten your approach.

The three-case dry-run (non-negotiable)

Before “done,” walk out loud:

1. Prompt example — prove happy path
2. Boring edge — empty or single element
3. Breaker — the case most likely to break your approach (often duplicates, bounds, or disconnected structure)

Point at variables. Update them on paper or in comments if helpful. Catching your own bug mid-dry-run is a strong signal.

How to talk about edges without stalling

Early:

“I’ll handle empty as return 0, and duplicates are allowed—confirm?”

Before coding the main loop:

“I’m assuming indices are inclusive on the left; I’ll verify with a length-1 case.”

Before finish:

“Dry-run: empty → …; sample → …; all duplicates → …”

Short. Specific. On the pad.

Tie edges to clarifying questions

Many edges are really clarification:

• Are empty inputs possible?
• Are negatives allowed?
• How are ties broken?
• Is the graph guaranteed connected?

Ask early; checklist later becomes verification, not discovery.

Practice drill

Take five recent problems you solved. For each, write the three dry-run cases without looking at the solution. Then check: which edge would have broken your first code? Add that edge type to a personal “frequent miss” sticky note and review it before live rounds.

Soft tooling note (practice only)

If you want a Chrome side panel beside your question and coding pad while you rehearse plan → code → three-case dry-run under a timer, Luna Interview is built for that practice loop. Use it to build calm verification habits—not as a substitute for knowing the material or for anything that violates interview rules.

Quick reference table

FAQ

What if time is almost out?

At least run the prompt example and one edge verbally. Say what you would test next. Partial verification still scores.

Should I write unit tests in the pad?

If the environment makes it easy, yes—two tiny asserts. Otherwise, verbal dry-run with clear expected values is enough.

Do interviewers expect every edge handled in code?

They expect awareness and correct handling of realistic edges for the prompt. Named-but-unimplemented edges with a clear plan can still earn partial credit if time dies; silent misses do not.

Bottom line

Keep a coding interview edge cases checklist, pick what applies, clarify early, and always dry-run three cases before you claim done. Edges are not pedantry—they are how correct engineers finish under eyes and a clock.

Rehearse with an AI interview copilot, then browse commonly reported interview questions.