Your code ran the sample input and printed the expected answer. You clicked
submit and the judge came back with 2 of 12 test cases passed, or a red panel
saying IndexError: list index out of range, KeyError, ZeroDivisionError,
or Expected: [] Got: None. In a live round the interviewer instead says "what
happens if the table is empty?" and you find out on the spot that you do not
know.
Any coding round with hidden tests: an online judge, a take-home with a private test file, or a live round where the interviewer supplies the awkward input from memory. Most common on problems that look finished after the happy path works — top-k counting, pair sums, group-by reports, and anything that divides. It also bites on pandas and SQL questions, where a null or a duplicate key changes a total without raising anything at all. Linked module: 6.3 (Coding round for AI roles).
Sample inputs are chosen to explain the problem, not to break your code. They are almost always the middle of the range: several rows, no nulls, no ties, no duplicates, sorted the way you expect. Hidden tests are chosen to break your code, so they live at the edges. Passing the sample tells you your reading was right, and tells you nothing about whether your code is right.
There are only six edges, and they repeat forever. Empty input, where a loop never runs and a division has no denominator. One element, where any code that compares neighbours has no neighbour to compare with. Duplicates, where an element can wrongly pair with itself and a "unique" key silently is not. Nulls, where a comparison is neither true nor false and a group-by drops the whole group. Unsorted order, where a two-pointer answer is quietly wrong rather than loudly broken. And huge input, which is a time problem rather than a correctness problem, covered in WR-156.
The pandas and SQL versions of these are the dangerous ones, because they do
not raise. A group-by on a column containing nulls drops those rows by default,
so a total of eight becomes seven and nothing warns you. COUNT(*) and
COUNT(column) differ for exactly the same reason. A merge against a master
with a repeated key multiplies rows, so a report that should count eight
transactions confidently reports eleven.
Run the checklist before the word "done" leaves your mouth, and run it out loud so it also earns process marks.
The six-case checklist, in this order
f([]), an empty DataFrame, a table with zero rows. Expect a
defined answer, not a crash. Decide whether empty means [], None or 0,
and say which you chose.f([5]). Any loop over pairs must not run. Any "second
largest" must have an answer for "there is no second".f([5, 5], 10) must return two different positions, never
the same one twice. In pandas, check the join key with .is_unique and pass
validate="many_to_one" to merge.None in the middle of the data. In pandas, groupby(..., dropna=False); in SQL, know that COUNT(col) skips nulls and that
col = 'X' is not true for a null.Two guards that cost one line each in a data problem
assert len(after_merge) == len(before), "merge changed the row count"
df.merge(master, on="store_id", how="left", validate="many_to_one")
When the judge has already failed you, read the panel in a fixed order: which test failed, what your code produced, what was expected. Then name the edge case that input belongs to. That naming step is what turns a random patch into a fix, and it usually takes under a minute.
Write the six cases as literal asserts at the bottom of every practice solution, so testing becomes part of writing rather than a separate act of virtue. Keep one file of edge cases per problem shape — counting, pair finding, group reports — and reuse it. In every mock round, say the checklist aloud even when you are sure, because the marks are for saying it. When a hidden test does beat you, add that exact input to your file and note which of the six it was; after a few weeks the list stops growing, which is the sign that you have covered the space.
Q: "How do you know your solution is correct?" Strong answer: name the six cases, then give one concrete example of a bug that only an edge case would have caught — an empty group, a duplicate key that doubled a total, a null that made a count disagree with a row count. Interviewers ask this to separate candidates who test from candidates who hope. Saying "I would write unit tests" is a weak answer on its own; naming the actual inputs you would feed and what you expect back is the strong one.