In my software engineering career I have taken 200+ coding interviews.
In this article, sharing top 10 most common blunders interviewees make in the interviews and tips on fixing them.
TL;DR
- Not understanding the problem
- Not asking questions
- Not planning before coding
- Not thinking out loud
- Not using hints
- Not giving brute-force solution
- Not optimizing the solution
- Not speaking while coding
- Not knowing Big O notation
- Not testing the solution
❌ Not understanding the problem
Fix:
✅ Re-read the question until you understand constraints and edge cases.
✅ Re-phrase question in your own words and verify understanding with the interviewer.
❌ Not asking questions
Fix:
✅ Clarify any detail about the problem you find ambiguous.
✅ Ask for problem constraints. Range of values, size of input, etc.
✅ Ask the interviewer if they prefer time or space optimized solution.
❌ Not planning before coding
Fix:
✅ Determine starting and ending points for solving the problem.
✅ Develop a high level algorithm before refining details.
❌ Not thinking out loud
Fix:
✅ Discuss solution approach with the interviewer.
✅ Walk them through your implementation by dry running code.
❌ Not using hints
Fix:
✅ Acknowledge the hint and how does it help.
✅ Expand on hint and see where else can it improve the solution.
❌ Not giving brute-force solution
Fix:
✅ Start by sharing simplest brute force solution.
✅ Explain why the approach is sub-optimal.
❌ Not optimizing the solution
Fix:
✅ Go through the solution step by step and identify the inefficiencies.
✅ Resolve inefficiencies by using right data structure or algorithm for the task.
❌ Not speaking while coding
Fix:
✅ Keep explaining to the interviewer what you are coding.
✅ Don’t speak code verbatim, also explain why you made a decision.
❌ Not knowing Big O notation
Fix:
✅ Know time and space complexity of classic algorithms.
✅ Practice calculating complexity of your code.
❌ Not testing the solution
Fix:
✅ Dry run the code with sample inputs and edge cases.
✅ If code doesn’t work, show that you understand why is that so.
Wrapping up 📝
Hope you will avoid these blunders in your next coding interview.
If you liked this post, follow me for more of these. 🙂
Also, share ONE interview mistake that you never want to repeat in comments. 👇
Top comments (22)
Never once needed or been asked about big 'O' in 27 years of professional development
Hello Jon! You seem to have a lot of experience with interviews and coding in general. Could you give me any tips or advice for my upcoming interview with Laravel? P.S: This is my first interview.
Relax and be yourself is the best advice I can give. Be confident in your abilities and DO NOT do last minute cramming and practice - you'll only stress yourself out and make yourself more nervous.
Thanks Jon. Appreciate you helping out.
😲 Not even in DSA interviews?
Never had one, and I never quiz candidates about those things. In my opinion, it's a bizarre thing to ask them about.
If they can write good code to solve given problems - that's what I'm looking for. Interrogating them about things that they probably use all the time anyway and may or may not know the 'correct' name for is not really of any use. I've found that a lot of self-taught developers (myself included) have often internalised many concepts without having any idea that they have formal names. You may be unwittingly turning down very talented coders just because they cannot behave like a search engine for computer science terms.
Gotcha!
Hey everyone, I have an interview/test coming up for a Laravel internship and I'm feeling a little nervous because i have only one week dealing with laravel . Do any of you have experience with Laravel or any tips for preparing for interviews/tests? Any advice or encouragement would be greatly appreciated! Thanks in advance!
As long as you know PHP like the back of your hand, anything written in PHP will be relatively straightforward to pick up, including Laravel.
Regardless of actual experience, I think before the interview you should write a test application in Laravel that does something non-trivial. The app doesn't have to be anything fancy but should involve a database, some backend logic, and a frontend form. That way you gain some experience. My classic goto is an address book app - it's complex enough to demonstrate all the major concepts of app design and can be written by one person in a single sitting while also having some potential real world utility. You should also probably get familiar with git if you aren't already.
A software development internship program implies prerequisite knowledge of how to write software to some degree but also carries the implication that you'll receive some sort of on the job training. They probably won't hand hold you through the basics (if-then, loops, integers, strings, arrays, objects, etc.) but beyond that it depends on what they are looking for. At the very least, writing a small app in Laravel will tell you if you even like Laravel.
As far as being nervous for an interview/coding test? Well, everyone gets jitters in unfamiliar situations/environments. Remember that interviewing is a two way street. You are interviewing them to see if you want to work for them as much as they are interviewing you to decide if you'll be a good addition to the team.
Thanks cubicle for helping out.
I've started applying as a front-end web developer. Especially JavaScript and React. Do you have any suggestions for me? Please let me know of some markets where I have the greatest chance of receiving calls for interviews in this area as well.
Btw, thanks a lot for sharing this awesome tips.
The experience i shared was mostly for DSA interviews but apart from big o notation i think other steps are relevant for any coding interview.
Regarding getting calls it largely depends on the company you are interviewing for so you will need to do company specific research on what they ask. But generally, having a portfolio of projects and updated GitHub profile should help with screening. Also you can try requesting referrals on LinkedIn.
Curious if you can expand on this point with an example.
Sure. In other words, before coming up with an algorithm - clearly define its inputs and outputs.
Nice summary 👌
Glad you liked it Ramo :))
Up to the point as always!!
Thank you for reading Devarshi 😀
Thanks for the tips
Thank you for reading :)
Very Helpful!
Thanks for reading Supriya 😀