Test Cases Coding Interview: Reason About Edge Cases
A repeatable way to enumerate and justify test cases aloud in a coding interview, with worked examples and a verbal template you can rehearse.
When an interviewer asks "how would you test this?", they are not checking whether you memorised a list of inputs. They are checking whether you can reason about correctness out loud. Test cases in a coding interview are a reasoning exercise: you name a case, say what it is designed to catch, and connect it to the complexity you quoted. This test cases coding interview guide gives you a repeatable order for doing that, two worked examples, and a short verbal template so your reasoning is followable rather than a recital.
Why Interviewers Ask About Test Cases At All
A solution that passes the example in the prompt proves very little. A candidate who can say "this fails on an empty array because my initialisation assumes at least one element" is showing engineering judgement.
Interviewers often listen for three things:
- Structure. Do you move through categories, or name random inputs as they come to mind?
- Prioritisation. Do you lead with the case that exercises the core logic, then move to boundaries? If the interviewer seems impatient, lead with the case most likely to break your core logic — the one that would make the algorithm return the wrong answer, not the one that is easiest to describe.
- Connection to complexity. Do you explain which input shape produces the worst case you quoted?
The common mistake is listing inputs without saying what each one tests. "Empty array, single element, duplicates" is a checklist. "Empty array, because my loop assumes a first element exists" is reasoning. The difference is one clause, and it is the clause interviewers tend to grade.
A Repeatable Order for Test Cases in a Coding Interview
Use the same order every time. It keeps you from freezing and it lets the interviewer follow your thinking.
1. The happy path
One typical input that exercises the core logic. For a function that returns the maximum subarray sum, that is an array with a mix of positive and negative numbers where the best window is not the whole array. Say why you chose it: "this one forces the algorithm to actually choose a window rather than return the total."
2. Boundaries
Empty input. A single element. The first and last positions. These catch off-by-one errors and initialisation bugs, which is where a lot of incorrect solutions go wrong.
3. Shape edge cases
Duplicates. Negative numbers. Already-sorted input. Reverse-sorted input. These catch assumptions you did not know you had made — like a two-pointer approach that quietly relies on sorted data.
4. Structural edge cases
Null or missing values, values large enough to overflow a fixed-width integer, malformed input if the prompt allows it. Mention these briefly and move on unless the interviewer pulls on one.
State the order as you begin: "I'll start with a typical case, then boundaries, then some shapes that stress my assumptions." That one sentence tells the interviewer where you are going, so they can redirect you if they want something else.
Worked Example: Test Cases for an Array Problem
Prompt: return the maximum sum of any contiguous subarray.
Here is how the reasoning sounds when spoken.
Typical case: [2, -1, 3, -4, 5, -2]. Walk the running total: 2, then 1, then 4, then 0, then 5, then 3. The best sum is 5, ending at the fifth element. Adding the final -2 would drop the total to 3, so the window stops there and the best subarray is [2, -1, 3, -4, 5]. This case checks that the algorithm keeps extending a window that is still worth keeping, and knows when to stop.
A case that forces a reset: [3, -5, 4]. Running totals are 3, then -2, then 4. Carrying the negative prefix forward gives 2, but the correct answer is 4, from [4] alone. This is the case that catches an implementation which never resets, and it is worth saying so out loud: "this one fails if I carry the negative prefix instead of starting fresh."
All-negative array: [-3, -1, -7]. The answer is -1, not 0. This catches the classic bug where the running total is reset to zero and the function returns an empty subarray's sum instead of the best single element.
Single element: [4]. Checks the base case. Also checks that the loop runs at least once.
Empty array: []. What should happen? The prompt probably does not say. Naming this case and asking the interviewer what they want is itself a good signal.
Which cases does the naive solution pass? A brute-force double loop over all subarrays passes all of these. It fails only on time. That is worth saying: it shows you understand that correctness and efficiency are separate questions, and it sets up the complexity discussion later.
Here is the same pass spoken end to end, as an example of the full routine in one go:
"I'll start with a typical case, then boundaries, then shapes. Typical:
[2, -1, 3, -4, 5, -2]. The running total goes 2, 1, 4, 0, 5, 3, so the best sum is 5 at the fifth element; adding the -2 would take it down to 3, so the window stops there. That checks I keep extending a window that still helps and stop when it stops helping. Now a case that forces a reset:[3, -5, 4]. Totals are 3, -2, 4. If I carry the negative prefix I get 2, but the right answer is 4, so this catches a missing reset. Boundary:[-3, -1, -7]should return -1, not 0, which catches resetting to zero. Single element[4]checks the loop runs. Empty array is a design question — what should it return?"
For more on narrating array solutions, see Sorting Coding Interview: Reason Through the Algorithm Out Loud.
Worked Example: Test Cases for a String or Hash Map Problem
Prompt: return the first character in a string that appears exactly once.
Typical case: "aabbcd" returns "c". Exercises the core counting logic.
Empty string: what does the function return? This is a design decision, not a bug, and saying so aloud is better than guessing.
Single character: "z" returns "z". Checks the loop boundary.
All identical characters: "aaaa" should return null or an empty string, depending on the agreed contract — there is no character that appears exactly once. This catches an implementation that returns the first character of the map rather than the first non-repeating one.
Case sensitivity and unicode: if the prompt says "characters", does "A" and "a" count as the same? Does an emoji count as one character or two? Ask. Do not assume.
Ordering assumption: if your solution iterates a hash map to find the first unique character, iterating the map returns the first key in map order, not the first unique character in string order. That is a real bug, and naming it shows you know the difference between a map's contents and a string's order.
Phrase each one as "I would test this because..." — the because is the point. "I would test aaaa because a map-based solution can return a character that appears four times if I forget to check the count."
For more on these structures, see Hash Maps Coding Interview: How to Explain Your Reasoning and Python Interview Questions: Concepts and Trade-Offs.
Connecting Test Cases to Complexity in a Coding Interview
The worst-case input shape usually determines the complexity you quote. "What input makes this slowest?" is a test-case question in disguise, and it is where test cases coding interview answers earn their keep.
Practise this sentence: "For insertion sort, the worst case is O(n²) because a reverse-sorted array makes the inner loop run every time." That single sentence does three jobs: it names the algorithm, names the complexity, and names the input that triggers it.
A second example, with a hash map: a solution that counts characters in one pass is O(n) time, because each character is processed once. The map holds up to k distinct characters, so space is O(k), and the input that maximises k is a string where every character is different. Saying "space is O(k), and the case that maximises k is a string of all-distinct characters" shows you know which input produces the bound you quoted — and keeps the time and space claims separate.
Avoid quoting complexity without naming the input. "It's O(n²)" is a number. "For insertion sort it's O(n²) when the input is reverse-sorted, because..." is an argument. Interviewers can evaluate the second one.
How to Talk About Test Cases in a Coding Interview Without Rambling
Use a short verbal template: category, example, what it catches.
"Boundary case: empty array. This catches an initialisation bug where I assume at least one element."
Three clauses. Ten seconds. Move on.
Cap yourself at three or four cases unless the interviewer asks for more. After that, say: "I've covered the main categories. Should I keep going, or move to complexity?" That signals a transition and gives them a chance to redirect you.
If you blank, fall back to the boundary-first order: empty, single, first, last. It is mechanical, it is always relevant, and it buys you time to think.
Practising Test-Case Reasoning Before the Interview
Pick five problems you already know how to solve. Write test cases for them without writing any code. Then rehearse aloud, because silent reasoning does not transfer to a live interview — the skill you are building is narration, not analysis.
Record yourself and listen back with one question: could someone who has not seen the problem follow my reasoning? If the answer is no, the cases were probably listed rather than justified.
A useful weekly routine:
- Choose three familiar problems.
- For each, say the happy path, two boundaries, and one shape case aloud.
- Add one sentence connecting the worst-case input to the complexity.
- Note where you hesitated, and rehearse that part again.
Repeat the record-and-review loop until narrating edge cases before you are asked feels like a habit rather than something you invent under pressure. You can find more practice material on our blog.
Common Mistakes and How to Avoid Them
Listing cases without saying what each one tests. Fix: add "because..." to every case.
Jumping to complexity before establishing correctness. Fix: finish the test-case pass first, then transition explicitly.
Forgetting the empty or single-element case because it feels trivial. Fix: make it step two of your order, every time.
Treating test cases as a formality. Fix: remember that this is the part of the interview where you demonstrate judgement rather than recall.
Before Your Next Mock Interview
The takeaway: every case you name should carry three things — the case, what it catches, and the input that makes it worst. That habit is what turns a list into reasoning the interviewer can follow. The action: tonight, pick one problem you already know and record a five-minute spoken pass through the happy path, two boundaries and one shape case, then listen back once. If a stranger could follow it, you are ready to repeat it live, and your next test cases coding interview answer will sound like reasoning rather than recall.
Frequently asked questions
How many test cases should I mention in a coding interview?
Judge it by the interviewer's signals rather than a fixed number. If they nod and stay quiet, keep going through your categories; if they glance at the clock or start writing, wrap up and offer to move on. A short, fully justified set usually lands better than a long recital, but read the room before you stop.
Do I need to write test cases in code, or can I describe them verbally?
Often you describe them verbally, unless the interviewer asks you to write a test. What is being evaluated is your reasoning about correctness, so saying what each case is designed to catch matters more than producing runnable test code.
What if the interviewer asks for test cases before I have finished the algorithm?
Give a short pass anyway. Say something like: "Before I finish, the cases I know I need to handle are an empty input, a single element, and duplicates." That shows you have a plan, and you can return to the full pass once the algorithm is written.
How do test cases relate to time complexity questions?
They are usually the same conversation. A complexity question often arrives right after your test-case pass, and the bridge is naming the worst-case input: once you have said which input shape is hardest, the bound you quote follows from it. Treat the two as one reasoning step rather than two separate topics.
Should I mention test cases for problems I solve with a brute-force approach first?
Yes, and be ready for the follow-up. After you confirm the brute force is correct, the interviewer often asks how you would speed it up. Point to the case that makes it slow — the largest input, or the one that forces the most repeated work — and use that to motivate the optimisation.
What is the most common edge case candidates forget?
The empty input and the single-element input, usually because they feel too trivial to mention. Naming them earns credit even when they seem obvious: they show the interviewer you check assumptions before trusting your code, and they often expose initialisation bugs that a typical input hides.