Coding Interview Mistake Log Template: Edge Cases, Complexity, and Retesting

A coding interview mistake log records why an attempt failed, what input exposes the failure, what complexity was required, and when to retest the skill. It is more useful than a list of missed LeetCode problems because it turns each failure into a reusable rule and a scheduled second attempt.

The Excel template includes a 100-row Mistake Log, an automatic Retest Queue, a category dashboard, dropdowns, and three fictional examples.

What the coding interview mistake log tracks

Use one row per attempt, not one row per problem. If you solve the same problem three times, those attempts may reveal three different failure modes. Preserving them separately makes improvement visible.

Field group	Essential fields	What it should answer
Attempt context	Date, problem, source, company, pattern, difficulty, mode, result, time	What happened under what conditions?
Diagnosis	Primary mistake type, root cause, minimal failing input, wrong assumption	Why did the approach fail?
Complexity	Claimed and target time complexity; claimed and target space complexity	Was the solution viable at the stated constraints?
Correction	Fix or reusable rule	What should transfer to a new problem?
Retesting	Last reviewed date, review count, next date, retest result, status	Did the correction survive a delayed attempt?

The workbook separates these fields because missed an edge case is only a symptom. The root cause might be an undefined interval convention, an invariant that was never stated, a loop boundary copied without testing, or a data structure that cannot meet the target complexity.

Use the five-sheet template

The workbook follows a short review loop:

• Read Me: field definitions and the suggested cadence.
• Mistake Log: 100 editable rows, filters, dropdowns, IDs, and date formulas.
• Retest Queue: due and overdue open items.
• Dashboard: category, retest, mastery, and time metrics.
• Lists: controlled dropdown values.

Delete the three fictional rows before using the workbook; they only demonstrate the formulas and status colors.

If you rebuild the log yourself, start with this header row:

Log ID | Attempt Date | Problem | Problem URL | Source / Company | Pattern | Difficulty | Attempt Mode | Attempt Result | Time Spent (min) | Primary Mistake Type | Root Cause | Missed Edge Case / Minimal Failing Input | Wrong Assumption | Claimed Time Complexity | Target Time Complexity | Claimed Space Complexity | Target Space Complexity | Fix / Reusable Rule | Last Reviewed Date | Review Count | Next Retest Date | Last Retest Result | Status | Days to Retest | Notes

Use dropdowns for difficulty, attempt mode, result, primary mistake type, retest result, and status. Microsoft documents data validation as a way to restrict entries or provide a dropdown list; Google Sheets supports dropdowns from a range or an explicit list. Controlled values prevent edge case, edges, and boundary bug from becoming three unrelated dashboard categories.

Record the attempt while the reasoning is fresh

Log the row immediately after the timer stops. Do not begin by reading the editorial. First reconstruct your own decisions:

1. What did you believe the problem required?
2. Which pattern or data structure did you choose?
3. Where did the first incorrect state appear?
4. Which test would have exposed it sooner?
5. What did you claim for time and space complexity?

Attempt mode matters. A solution completed with hints during untimed practice is different evidence from a clean 30-minute mock. Keep the labels factual. Solved with hint is useful data, not a failure that needs to be softened.

Separate the symptom from the root cause

Weak logs describe the visible outcome: failed hidden tests, TLE, or forgot an edge case. Strong logs identify the decision that produced it.

Symptom	Better root-cause entry	Reusable rule
Hidden test failed	Assumed every target has a valid pair	Test both a valid and an absent answer before submission
Interval answer off by one	Mixed closed and half-open endpoint rules	Write the interval convention beside the function signature
BFS grouped levels incorrectly	Reused the changing queue length inside the level loop	Snapshot the level size before processing that layer
Timed out	Used an all-pairs scan despite a large input limit	Translate constraints into a target complexity before coding
Correct code, unclear interview	Explained implementation but never stated the invariant	State the invariant before walking through the loop

The Wrong Assumption field is especially valuable. It records why the code looked reasonable at the time. When the same assumption appears twice, mark the item Recurring and choose a practice problem that forces the same decision in a different surface story.

Capture the smallest failing edge case

Do not write test duplicates. Save a concrete input and expected behavior. A minimal example is easier to remember, rerun, and explain.

Use an edge-case checklist as a prompt, not as a substitute for reasoning:

Edge-case family	Questions to ask
Empty and smallest input	What happens at zero elements, one element, or the minimum permitted value?
Duplicates and ties	Does equality change ordering, counting, or which answer is returned?
Boundaries	Are endpoints inclusive, exclusive, or mixed? Can indexes reach either end safely?
Missing result	What should be returned when no valid solution exists?
Negative and zero values	Do signs break sorting, division, modular arithmetic, or sentinel choices?
State across calls	Does mutable state leak between operations, users, or repeated tests?
Large constraints	Which input shape creates the worst runtime or memory use?

An observational software-testing study examined 13 developers thinking aloud while testing real open-source methods, then surveyed 72 developers. Its scope was broader than interviews, but it treats revealing tests as an explicit engineering activity rather than a final checkbox.

Audit complexity before accepting the fix

A correct output on examples is not enough when constraints require a different algorithm. Record both the claimed and target complexity.

For each correction, answer four questions:

• What operation dominates runtime: sorting, nested scanning, heap maintenance, hashing, graph traversal, or repeated string copying?
• Is the bound worst-case, expected, or amortized?
• What data structure contributes the largest extra memory cost?
• At the maximum input size, which term becomes unacceptable?

Avoid entries such as optimized it. Write replaced O(n^2) pair scanning with an expected O(n) hash-map pass, using O(n) extra space. If sorting is necessary, record O(n log n) and explain whether the in-place sort mutates input.

Turn the fix into a reusable rule

The fix field should help on a problem you have not seen. Compare these entries:

• Weak: Use a hash map.
• Better: When the prompt asks for an earliest pair, define tie-breaking before choosing what each map entry stores.
• Weak: Check empty input.
• Better: Before the main loop, list the minimum valid input and the no-answer contract.

A reusable rule has a trigger visible in the prompt, constraints, or state model, plus an action that changes your reasoning before coding.

Do not paste a full solution into the log. Keep the problem URL for reference, but retest with the old code hidden.

Schedule retests at 1, 3, 7, and 14 days

The workbook uses a suggested interval sequence based on review count:

Review count	Suggested next interval	Purpose
0	1 day	Verify that the diagnosis is understandable tomorrow
1	3 days	Attempt the problem again without the old solution
2	7 days	Transfer the same rule to a related problem
3 or more	14 days	Check retention under realistic time pressure

This cadence is adjustable. Research reviews of learning techniques have rated practice testing and distributed practice as high-utility methods, but they do not establish one universal spacing schedule for coding interviews. Shorten the interval after a conceptual failure or an upcoming interview. Lengthen it when several clean attempts show retention.

Assuming Attempt Date is in B, Last Reviewed Date in T, Review Count in U, Next Retest Date in V, and Status in X, the template uses:

=IF(OR(B2="",X2="Mastered"),"",IF(T2<>"",T2,B2)+IF(U2=0,1,IF(U2=1,3,IF(U2=2,7,14))))

For Days to Retest:

=IF(V2="","",V2-TODAY())

Apply red conditional formatting to negative values and amber formatting to zero through two. Microsoft Excel and Google Sheets both support conditional formatting based on values or formulas. Test the rules with fictional dates before relying on them.

Use metrics that change your next practice block

The dashboard should answer what to practice, not create a vanity score.

Useful metrics include total attempts, open issues, due retests, mistakes by category, delayed retest pass rate, mastery rate, and average time. If Index / boundary appears five times, schedule intervals, binary search, and array endpoints. If Communication grows despite correct code, practice stating the invariant and complexity aloud.

Avoid a single readiness percentage. Difficulty, hints, time limits, and problem familiarity differ too much. A rising pass rate on delayed retests is more informative than the number of problems marked complete.

A 15-minute weekly review

Once a week, filter the log in this order:

1. Complete due and overdue retests.
2. Group rows by primary mistake type.
3. Identify any wrong assumption that appears more than once.
4. Select one new problem for the largest recurring category.
5. Review complexity gaps against actual constraints.
6. Mark an item Mastered only after clean delayed attempts.

If maintenance becomes heavy, remove fields you never use. Keep the minimal failing input, wrong assumption, target complexity, reusable rule, and next retest date; they are the core feedback loop.

Frequently asked questions

What should I write in a coding interview mistake log?

Record the attempt context, primary mistake type, root cause, smallest failing input, wrong assumption, claimed and target complexities, one reusable correction rule, and a dated retest. Keep the entry short enough to review before another timed problem.

Should I log problems I solved correctly?

Log them when the solution required a hint, exceeded the time limit, used the wrong complexity, or was difficult to explain. A clean independent solution with no new lesson does not need a mistake row.

How often should I retest a missed coding problem?

Use 1, 3, 7, and 14 days as an adjustable starting point. Retest sooner after a conceptual failure and include a different problem with the same pattern before calling the skill mastered.

Should I save the full solution in the spreadsheet?

Usually no. Save the problem link, minimal failing input, root cause, and reusable rule. Hiding the prior solution makes the next attempt a better test of recall and reasoning.

Is Excel or Google Sheets better for a LeetCode mistake tracker?

Both work. Excel offers durable tables, validation, formulas, and charts in one workbook. Google Sheets is convenient across devices and supports dropdowns and conditional formatting. Choose the format you will update consistently and verify imported formulas after conversion.

Final takeaway: the value of a coding interview mistake log is not the number of rows. It is the closed loop from attempt to minimal failing test, root cause, complexity correction, reusable rule, and delayed retest. When the same error stops recurring on unfamiliar problems, the log has done its job.

Sources and Further Reading

• Microsoft Excel: Apply data validation to cells
• Microsoft Excel: Use conditional formatting to highlight information
• Google Sheets: Create an in-cell drop-down list
• Google Sheets: Use conditional formatting rules
• How Developers Engineer Test Cases: An Observational Study
• Dunlosky et al.: Improving Students' Learning With Effective Learning Techniques
• Microsoft Copilot Studio: Track evaluation failures with structured logging templates

The retest intervals are a configurable workflow suggestion, not a guarantee of interview readiness or a fixed learning prescription.*