Coding Interview Mistakes: 20 to Avoid (and What to Do Instead)

The most common coding interview mistakes are jumping into code before you understand the problem, coding in silence, ignoring edge cases, never testing your solution, and not stating its time and space complexity. Almost all of them are process mistakes rather than knowledge gaps, which is good news: you can fix them with a repeatable routine and a few weeks of practice out loud.

Interviewers in a coding round usually assess more than whether your code runs. They watch how you clarify a vague prompt, how you choose between approaches, how readable your code is, how you test it, and how you respond to hints. This list groups the 20 mistakes by stage of the problem, gives the fix for each, and shows a short example we wrote of the better habit. For the bigger picture of the round itself, see our guide to what a technical interview is; for mistakes in every kind of interview, see the common interview mistakes roundup.

What are the most common coding interview mistakes?

Here is the full list at a glance. The sections below explain each one.

Mistakes before you write any code

1. Jumping straight into code

Typing within the first minute feels productive, but it usually means you are solving the problem you assumed rather than the one you were given. If the approach turns out to be wrong, you have burned time and now have to undo code under pressure.

Fix: Spend the opening minutes restating the problem, asking questions and agreeing on an approach.

Example we wrote: "Before I start typing, let me restate it: given an array of integers and a target, return the indices of two numbers that add up to the target. I'll confirm a few things first."

2. Not asking clarifying questions

Many coding prompts are deliberately underspecified. Not asking leaves gaps you will fall into later, and it misses an easy chance to show how you would approach a real ticket.

Fix: Ask about input size, data types, sorted or unsorted input, duplicates, negative numbers, empty input and what to return when there is no answer. Pick the three or four that matter here.

Example we wrote: "Can the array contain duplicates? Is there always exactly one valid pair? And roughly how large can the input get, thousands or millions?"

3. Skipping a worked example

Without an example, it is easy to misread the problem or design an approach that fails on the very first input. It also becomes your first test case.

Fix: Write one small input and solve it by hand before designing anything.

Example we wrote: "Let me use [3, 8, 2, 5] with a target of 10. By hand, 8 and 2 work, so I'd return indices 1 and 2."

4. Hiding the brute-force idea

Some candidates stay quiet until they find the optimal solution. If they never find it, the interviewer has nothing to evaluate.

Fix: State the brute-force approach and its complexity in one or two sentences, then explain why you want something better. It gives you a baseline to improve on.

Example we wrote: "The simplest version checks every pair, which is O(n squared) time. That works, but with a large input I'd rather trade some memory for speed."

5. Coding before the interviewer agrees with your plan

If you start coding an approach the interviewer has doubts about, you may spend twenty minutes on something they were hoping you would rethink.

Fix: Summarize your approach and its complexity, then check in before coding. If they push back, that is a hint, not a rejection.

Example we wrote: "My plan is a single pass with a hash map from value to index, so O(n) time and O(n) space. Does that sound reasonable before I write it?"

Mistakes while you code

6. Coding in silence

Long silences leave the interviewer guessing whether you are stuck, on track, or heading somewhere wrong. They can't credit reasoning they never hear. Our guide on how to practice thinking out loud in coding interviews covers this habit in depth.

Fix: Narrate at decision points: what this block does, why you chose this data structure, what you are checking next. If you need quiet to think, say so and give a time.

Example we wrote: "Give me about thirty seconds to think about how the window should shrink, and then I'll talk it through."

7. Narrating syntax instead of reasoning

The opposite problem is reading code aloud: "for i in range, open bracket…". That fills the silence without telling the interviewer anything they can't already see.

Fix: Explain the why and skip the what.

Example we wrote: "I check the map before inserting the current number, so an element can't be paired with itself."

8. Ignoring hints

Interviewers often give hints as questions: "What happens if the input is sorted?" or "Is there a way to avoid the nested loop?" Brushing past them costs you the help and makes you look hard to work with.

Fix: Pause, repeat the hint back, and say how it changes your plan.

Example we wrote: "That's a good point. If it's sorted, I could use two pointers from each end and drop the extra memory. Let me think through whether that still holds with duplicates."

9. Vague names and one giant function

Variables called a, tmp and x2, inside one 60-line function, make your code hard to follow and hard for you to debug when something breaks.

Fix: Use descriptive names and pull distinct steps into small helper functions. If time is short, write the helper's signature, explain what it does, and fill it in if time allows.

Example we wrote: "I'll write is_valid_window(counts, k) as a helper so the main loop stays readable. I'll come back and implement it once the main logic works."

10. Stalling on syntax you can't recall

Forgetting an exact library method name under pressure is normal. Spending three minutes trying to remember it is the mistake.

Fix: Say what you need, write a clearly named stand-in, and keep going. Most interviewers care far more about your logic than about memorized method names.

Example we wrote: "I don't remember the exact name of the method that sorts by a key in this language, so I'll write sort_by_end_time(intervals) and we can treat it as the standard sort."

11. Off-by-one and boundary errors

Loops that run one step too far or stop one step short are among the most common bugs in interview code, especially with two pointers, sliding windows and binary search.

Fix: For each loop, say the start, the end and whether the end is inclusive. Then check it against the first and last elements of your worked example.

Example we wrote: "The right pointer stops at length minus one, and the loop runs while left is less than right, so we never compare an element with itself."

12. Getting rattled by a bug

Finding a bug mid-interview is normal. What hurts is changing lines at random, going quiet, or apologizing repeatedly.

Fix: Pick one small input, trace it through your code out loud, and find the first line where the actual value differs from the value you expected. If a whole answer goes wrong, our guide on how to recover from a bad interview answer gives reset phrases that work in coding rounds too.

Example we wrote: "The output is off by one element. Let me trace [3, 8, 2, 5]. After the second step, the map should hold 3 and 8, but I'm inserting before checking, so that's the bug."

Mistakes after the code runs

13. Ignoring edge cases

Code that handles the example but crashes on empty input or a single element suggests you think about the happy path only.

Fix: Keep a short, standard checklist and run through it for every problem: empty input, one element, all elements the same, duplicates, negatives and zero, very large values, and no valid answer.

Example we wrote: "Edge cases: an empty array returns an empty list, a single element can't form a pair, and with duplicates like [5, 5] and a target of 10, my code still works because I check before inserting."

14. Not testing your code

Saying "I think that works" without checking is one of the most avoidable mistakes in a coding interview.

Fix: Dry-run your code line by line on your worked example, writing variable values as you go.

Example we wrote: "Let me walk through it. i is 0, value 3, complement 7, not in the map, store 3. i is 1, value 8, complement 2, not in the map, store 8. i is 2, value 2, complement 8, found at index 1, return [1, 2]. That matches."

15. Testing only the happy path

Testing with the same example you designed the code around proves very little, because your code was shaped to pass it.

Fix: After the main example, run one edge case and one case designed to break your logic, such as a duplicate value or the answer sitting at the last index.

Example we wrote: "Now a tricky one: [4, 6] with a target of 10, where the pair is the only two elements. Then [1, 2] with a target of 10, where there's no answer, so I return an empty list."

16. Not stating time and space complexity

Many interviewers expect a complexity analysis, and waiting to be asked makes it look like an afterthought.

Fix: When you finish, state the time and space complexity of your final code and explain where each comes from. If you need a refresher, the Big-O complexity visualizer and our Big-O cheat sheet cover the common cases.

Example we wrote: "This is O(n) time because each element is visited once and map lookups are O(1) on average, and O(n) space for the map in the worst case."

17. Missing hidden costs in your complexity

Candidates often call a solution O(n) while slicing a list inside the loop, concatenating strings repeatedly, or sorting first. Interviewers do notice.

Fix: Before stating complexity, scan for sorting, slicing, copying, string building in loops, recursion depth and library calls that aren't constant time.

Example we wrote: "I said O(n), but I sort the intervals first, so the total is O(n log n). The space is O(n) for the output, plus whatever the sort uses."

18. Saying "done" with nothing more to add

Ending on "that's it" leaves unused time and misses a chance to show judgment.

Fix: Close with one improvement, trade-off or extension: a lower-memory version, how you would handle a data stream, or what changes at much larger scale.

Example we wrote: "If memory mattered more than speed, I'd sort a copy and use two pointers, which is O(n log n) time and less extra space. If the numbers arrived as a stream, I'd keep the map and check each new value as it comes in."

Mistakes in how you prepare

19. Memorizing solutions instead of patterns

Memorized answers break as soon as the interviewer changes one constraint.

Fix: Study patterns (two pointers, sliding window, hashing, BFS and DFS, binary search on the answer, dynamic programming) and practice explaining why each applies. Our guide to LeetCode patterns for interviews lists the main ones, and the coding interview cheat sheet is a quick reference.

Example we wrote: "This asks for the longest substring meeting a condition, which suggests a sliding window. I'll expand the right side and shrink the left whenever the condition breaks."

20. Practicing only in silence

Solving hundreds of problems silently at a keyboard trains the algorithm part and skips the communication part, so the first time many candidates narrate a solution is in the real interview.

Fix: Make at least some practice out loud, timed, and with someone (or something) asking follow-up questions.

Example we wrote: a weekly routine of three silent problems for pattern practice, then two timed problems narrated out loud with a 45-minute limit and a review of the recording.

Which coding interview mistakes are hardest to recover from?

Most mistakes on this list are recoverable inside the same interview. A missed edge case can be caught in testing, a wrong complexity claim can be corrected, and a bug found and fixed calmly can leave a good impression. The ones that are hardest to undo are the ones that eat the clock early (jumping into the wrong approach and refusing to change course) or that suggest you'd be hard to work with (ignoring hints, getting defensive about feedback).

If one round goes badly, it is usually one data point among several. Our guide to what to do if you don't know the answer in an interview covers getting unstuck in the moment.

How to practice avoiding these mistakes

Reading a list of mistakes doesn't change habits; repetition under realistic conditions does. Practice coding problems with a timer, out loud, and with someone asking "why?" and "what if?" as you go. You can rehearse with a free AI mock interview in your browser, which includes a coding track, or run a full mock built from your résumé and the job description in the CoPilot Interview desktop app, where each answer is scored out of 10 with what to fix. Coding questions there never auto-submit, so you can plan before you talk. The free plan gives you 15 minutes a day with no account. Follow each employer's rules on AI tools, and use AI to prepare beforehand.

FAQ

What is the biggest mistake in a coding interview?

Jumping into code before you understand the problem is the most common and most costly mistake, because it can waste a large part of the round on the wrong approach. Restate the problem, ask clarifying questions and agree on a plan before you type.

Is it bad to not finish a coding interview problem?

Not necessarily. Many interviewers weigh your approach, communication and testing alongside completion. A clear, well-reasoned partial solution with a correct plan for the remaining steps often reads better than finished code you cannot explain.

Should I start with the brute-force solution?

State it, yes. Describe the brute-force approach and its complexity in a sentence or two, then improve on it. Whether you code it first depends on time and on what the interviewer prefers, so ask.

How many edge cases should I test in a coding interview?

Usually two or three beyond your main example: one empty or minimal input, one case with duplicates or extreme values, and one where there is no valid answer. Mention any others you would check given more time.

What if I forget the syntax for a method in a coding interview?

Say that you do not remember the exact name, write a clearly named stand-in, and keep going. Most interviewers care more about your logic than memorized method names.

How do I stop going silent while coding?

Narrate at decision points rather than line by line, and if you need quiet, say so and give a time, such as thirty seconds. Practicing out loud with a timer and a recording is the fastest way to build the habit.