10 DSA Mistakes Freshers Make in Interviews

By Pooja Goenka · Published 2026-11-04 · Updated 2026-11-12

The most common DSA mistakes freshers make in interviews are not about missing a clever algorithm. They are about process: starting to code before the problem is clear, ignoring edge cases, going silent, and never stating the time and space cost. Interview-prep sites such as DesignGurus and AlgoCademy list the same three habits again and again (checked on 4 Nov 2026). They are coaching-site opinions, not hiring data, so treat them as advice and not as statistics.

This post goes a step further. Several mistakes below are small bugs that look correct and still fail. Each one comes with code, and I ran every snippet in Python 3.9 before putting it here.

1. Coding before you understand the question

You hear "find two numbers that add up to a target" and start typing. Then the interviewer says the array can have repeated values, and your approach breaks.

Fix: spend the first minute asking. Can the array be empty? Can values repeat? Is it sorted? Can I use the same element twice? Then say the problem back in your own words.

2. Skipping the brute force

Freshers often stay silent because they only have a slow idea and think it is embarrassing. It is not. A correct slow answer, said aloud, gives the interviewer something to improve with you.

Fix: say "the simple way is two loops, which is O(n²). Let me see if a hash map removes the inner loop." That sentence shows you can reason about cost, which is the real test.

3. Never testing edge cases

Your solution works on the example in the question. Does it work on an empty list, one element, or two equal values? Run this small two-sum:

def two_sum(nums, target):
    seen = {}
    for i, n in enumerate(nums):
        if target - n in seen:
            return [seen[target - n], i]
        seen[n] = i

print(two_sum([3, 3], 6))     # [0, 1]
print(two_sum([3, 2, 4], 6))  # [1, 2]

The duplicate case [3, 3] works only because we check the map before inserting the current number. Swap those two steps and the same element can be matched with itself.

Fix: before you say "done", walk through an empty input, a single item, duplicates and the largest case you can imagine.

4. Sharing one list by accident

This is a classic Python trap when building a grid for dynamic programming:

a = [[0] * 3] * 2
a[0][0] = 1
print(a)   # [[1, 0, 0], [1, 0, 0]]

b = [[0] * 3 for _ in range(2)]
b[0][0] = 1
print(b)   # [[1, 0, 0], [0, 0, 0]]

In the first version both rows are the same list, so changing one changes both. The second builds a fresh row each time. The same idea explains why a default argument like def f(x, seen=[]) keeps its contents between calls: the Python FAQ says default values are created once, when the function is defined.

Fix: build 2D grids with a list comprehension, and default to None for mutable arguments.

5. Writing a binary search that loops forever or skips the answer

Binary search looks easy and fails on the details: < versus <=, mid + 1 versus mid. Here is a version that handles the small cases:

def binary_search(a, x):
    lo, hi = 0, len(a) - 1
    while lo <= hi:
        mid = lo + (hi - lo) // 2
        if a[mid] == x:
            return mid
        if a[mid] < x:
            lo = mid + 1
        else:
            hi = mid - 1
    return -1

print(binary_search([], 1))         # -1
print(binary_search([1], 1))        # 0
print(binary_search([1, 3, 5], 4))  # -1

Notice mid = lo + (hi - lo) // 2. In Python this makes no difference, because integers do not overflow. In Java or C++ the shortcut (low + high) / 2 can overflow on very large arrays. Joshua Bloch wrote about this in a Google Research blog post dated 2 June 2006, and the safer form is the one above. Interviewers like it when you mention it.

Fix: pick one template, test it on empty, one element, and a missing value, and keep using it.

6. Forgetting the recursion limit

A recursive solution that works for 10 items can crash for 10,000. In CPython the default limit is 1000 calls deep. You can confirm it yourself:

import sys
print(sys.getrecursionlimit())  # 1000 on the machine I tested

Fix: when the input could be large, say so out loud and offer an iterative version or an explicit stack. You do not need to code it, just show you know the risk.

7. Staying silent while you think

The interviewer cannot give a hint to a blank screen. Thinking aloud, even half-formed, lets them nudge you when you drift.

Fix: narrate in short lines. "I am trying a hash map because I need fast lookup." "I am stuck on how to handle duplicates." If you need a full minute of quiet, say that: "give me a minute to think".

8. Not stating time and space complexity

A working answer with no complexity is half an answer. Interviewers will ask, and a hesitant reply costs you.

Fix: after each solution, say both numbers. For the two-sum above: "O(n) time, O(n) space, because the map can hold every element." Then name the trade: "the brute force uses O(1) space but O(n²) time."

9. Changing code without re-running it by hand

You spot a bug, fix one line, and move on. The fix breaks something else.

Fix: after any change, trace the smallest failing input line by line, writing the variable values. It is slow on purpose. Interviewers read it as care.

10. Falling apart after a hint

A hint is not a failure. Interviewers give hints to see how you respond. Candidates who argue, freeze or ignore the hint lose more than candidates who needed it.

Fix: repeat the hint in your own words, say what it changes, and try it. "So you are suggesting I sort first. That makes the pairs adjacent, so I can use two pointers."

A quick practice routine

Pick one problem and do this out loud: ask three clarifying questions, state the brute force, state the better idea, code it, test three edge cases, then say time and space. Do it for five problems and the habits start to stick. The point is to rehearse the process, not to memorise answers.

Try one thing free

Open LogicWiz Learn DSA and pick the topic you find hardest. If binary search is the one that trips you, the binary search foundations page walks through it step by step. Then practise saying your answer aloud in a free mock on LogicWiz Interviews. The Spark plan is free and needs an account, and you can see current plans on the pricing page.

Common questions

What is the biggest DSA mistake freshers make?

Starting to code before the problem is clear. Two minutes of questions and a spoken brute force prevent most of the others on this list.

How many edge cases should I test?

Cover the standard four: empty input, one item, duplicates, and a very large input. Say them aloud even if you do not run them.

Is it okay to ask the interviewer for a hint?

Yes. Ask after you have tried and can say what you are stuck on. "I have a hash map idea but I cannot handle duplicates" is a better request than "I do not know".

Should I always write the optimal solution first?

No. Start with a correct one, state its cost, then improve it. A correct slow answer beats an incomplete clever one.

Which language should I use?

Use the one you know best and that the company allows. Python is short to write, but know its traps, such as the shared list in mistake 4.

Back to the blog