Most people fail their coding interviews for the exact same reason, and they still don’t know it.

This frustrated me a lot back in the days. I went to interviews. I solved every question optimally. I discussed several approaches with the interviewer. I communicated well. I explained the time and space complexities.

And I still didn’t pass to the next round. I couldn’t explain why to myself. I’ve followed every advice I found online. What was wrong with me!?

Until one day I left my ego at the door and asked for feedback from a senior software engineer friend. I simulated my last interview with him. He found my blind spot in less than 5 minutes. It was the way I wrote code.

He told me: “You solve these coding questions very well, and your communication is neat, but you are missing the biggest piece of the puzzle. The code you write is going to be the clearest indication of your software engineering skills”.

He continued by dissecting every piece of my code and rewriting its own version of it. The difference was huge. I understood why my code would have never been pushed into production. It was messy, over-complicated and hard to follow.

During interviews, I was getting super excited that I came up with a solution and wanted to code it as quickly as possible. I was jumping too quickly into coding without having a clear picture of how exactly it will work.

I didn’t put too much thought into naming my variables: variables like “map” or “arr” were very common in my quickly written code.

I was not respecting a Coding Style: I mixed camel case with snake case a lot, I wasn’t using enough spaces and tabs for visibility and my brackets were all over the place.

I didn’t divide my code into smaller reusable components. I was putting everything in one long and confusing function.

I was having too many obfuscated if statements that could have been easily rewritten in a simpler and easy to follow way.

And the list continues…

So I spent most of my time working on this sticking point.

I studied about quality code. I learned what makes for clean, reusable code.

Usually I would spend 75% of time coming up with the optimal solution and 25% writing the code. I flipped those percentages to 25-75.

I started to focus on solving the bigger picture and link up all the parts instead of getting distracted by less important aspects of the task at hand.

I put time into thinking through the clear use cases and environment of the code and how I want to structure it.

After I finished writing code, I would spend extra time thinking how I could make it better.

I would look at every separate piece of code and think if it can be rewritten in a cleaner, more readable way.

I would look at every function and ask myself: Can this be split up into smaller helper functions? Can reduce the number of “return” statements? Can I choose a better name for it?…

I even rewrote most of my past source codes so that they follow all the guidelines and good practices.

And it did wonders for me. Interviewers were wow-ing themselves with how reusable and adaptable my code was.

The code was super easy to follow along and clearly understand what it does. I rarely was asked to explain again what I want to achieve with a specific line of code.

They often changed the problem a little as a follow up and were impressed with how easily I could adjust my existing code to work for that scenario also.

They also complimented me for how I named my variables and functions and how readable and easy to follow my code was.

And you can imagine what happened next. I started getting offers.

This was mind blowing for me and made me ask myself: “How could I have missed this? Why didn’t I learn this earlier?”

It’s truly incredible how things you don’t know that you don’t know get in the way of your success. It opened my eyes once again about the importance of asking for feedback.

Code Quality is the most important thing interviewers are looking for. Many times a non-optimal well written solution will pass but an optimal bad implementation will not.