10 Coding Interview Mistakes Indian Engineers Make (and How to Fix Them)

Mistake 1: Starting to code immediately without clarifying: This is the most common mistake. An interviewer gives you a problem and you start typing. You have not asked about input constraints, edge cases, or expected output format. You solve the wrong version of the problem and waste 15 minutes.

Fix: Before writing any code, spend 3–5 minutes clarifying. Ask: 'Can the input array be empty? Can values be negative? Should I handle integer overflow? Is the input guaranteed to be sorted?' Then say: 'My understanding of the problem is X: does that match your intent?'

Mistake 2: Solving silently: Many Indian engineers are trained to solve problems quietly. In an interview, this is invisible performance: the interviewer cannot evaluate your thinking if they cannot hear it.

Fix: Think aloud. Narrate every step: 'I am considering a brute force first: that would be O(n²). I can see a better approach using a hashmap that gets this to O(n). Let me code that...'

Mistake 3: Getting stuck without asking for hints: Indian candidates often sit in silence for several minutes when stuck, out of cultural reluctance to appear not-smart. Interviewers would prefer to give a hint than watch you struggle silently.

Fix: After 2–3 minutes of being stuck, say: 'I am exploring a couple of approaches but I am not finding the optimal path yet: would you be willing to give me a nudge in the right direction?' This is professional, not weak.

Mistake 4: Not restating the problem in your own words: If your restatement of the problem at the start has a subtle error, the interviewer corrects it immediately: saving you from solving the wrong problem for 40 minutes.

Fix: Before coding, say: 'Let me restate to make sure I understand: we are given an array of integers and need to find the two numbers that sum to a target. We can assume exactly one solution exists and we cannot use the same element twice. Is that right?'

Mistake 5: Writing messy, uncommunicative code: Interviewers read your code. Variable names like 'a', 'b', 'temp', 'arr2' make your logic hard to follow, even if it is correct.

Fix: Use descriptive variable names even under pressure. 'leftPointer', 'rightPointer', 'currentSum', 'maxProduct' take 2 extra seconds to type and make your code self-documenting.

Mistake 6: Not handling edge cases: Many candidates solve the happy path only. A function that crashes on an empty array, a null input, or a single-element list loses marks even if it handles the average case perfectly.

Fix: After your initial solution, always say: 'Now let me think about edge cases.' Check: empty input, single element, all elements the same, maximum values (overflow), negative numbers if applicable. Handle at least 2–3 explicitly.

Mistake 7: Not testing the code before claiming it is done: Announcing 'I am done' and then having the interviewer immediately find a bug is worse than never claiming you were done.

Fix: Before saying you are done, trace through your code with a simple example. Walk the interviewer through it: 'Let me test with [1, 2, 3] and target 4: my left pointer starts at index 0 (value 1), right at index 2 (value 3), sum is 4, which equals target. We return [0, 2]. Looks correct. Now let me check the edge case of an empty array...'

Mistake 8: Over-engineering the first solution: Some candidates immediately reach for the optimal solution. If the optimal solution is complex and takes 35 minutes to implement, you have left no time for testing and discussion. The interviewer does not see that you can optimise.

Fix: State the brute force first, even if you know a better approach. 'The naive approach is O(n²): let me write that quickly to have a working solution, and then I will optimise it to O(n) using a sliding window.' This demonstrates the optimisation thinking AND gives you a working solution as a fallback.

Mistake 9: Losing track of time: 45 minutes passes faster than you expect. Many candidates look up to find 35 minutes have passed and they are still on their approach: with no code written.

Fix: Internalize the 45-minute coding interview timeline. 5 minutes to clarify, 5 minutes to discuss approach, 20–25 minutes to code, 10 minutes to test and discuss. Ask the interviewer early: 'How much time do we have for this problem?' if it is not clear.

Mistake 10: Not asking about time/space complexity: Many Indian candidates simply write the solution without discussing complexity. This is a lost opportunity to demonstrate analytical depth.

Fix: After coding, always say: 'The time complexity is O(n) because we make one pass through the array. The space complexity is O(n) for the hashmap. If space is a constraint, we could switch to a two-pointer approach on a sorted copy of the array at O(n log n) time and O(1) space: would that trade-off be worth exploring?'