3 Mistakes Junior Developers Make During an Interview

Being a genius software engineer won’t get you very far if you can’t get past the interview. I am not talking about communication skills or not knowing substantial details about the company that you are interviewing for. Those problems in my opinion are not the deciding factors in most cases.

Instead, I will mention mistakes that I have seen developers make which eventually became the reason for their rejection. These are also very easy to fix and can have a huge impact during the interview.

Responding Too Quickly

The biggest mistake I see when interviewing candidates is jumping to solutions before understanding the problem. Candidates are eager to answer questions, so they believe the faster they come up with a solution, the cleverer they will sound. But this is not what our job is about.

Stop acting like a translator, translating business problems into code. You are a problem solver first and then a programmer. You should always understand the problem, asking as many questions as possible to understand the dynamics of the problem. Don’t rush!

No one is expecting you to provide the solution right away. It is the way you approach the problem that gets evaluated.

Running Around The Bush

Another problem that I constantly see is that candidates are afraid to say “I don’t know.” You don’t have to pretend you know it all. Even if it is something that you have mentioned on your resume, you can call that out.

It is very easy to figure out when you just don’t know a piece of trivia (‘how are hash collisions handled in Python?’). Great candidates know there’ll always be some things they don’t know, so they just give a confident, non-apologetic “I don’t know.” Which is completely fine and a valid answer.

You only get an hour or less for an interview. You have to make sure that you don’t waste that on anything else apart from showing why you are the best candidate to hire.

Bad Quality Code Submission

Oftentimes, before the technical interview, you are supposed to solve a problem and send the code back. You are given two days in general to write the solution. You can select the language you are comfortable with and also make a few assumptions if you don’t exactly understand something.

There are generally two mistakes in a bad submission — assuming the code quality is good and the solution works.

• Poor documentation: Failing to mention the critical parts of the solution in writing can be very irritating for the person who is looking at your code for the first time. You have to be very vigilant in writing the assumptions, the dependencies that you are using, and how to run the application.

• Test coverage: Considering the amount of time you generally get, it should not be too hard to add proper tests and have a test coverage of a minimum of 80 %.

One quick trick is to quickly ask your friend to try and run the code. If they are able to run it and understand it, then you are good to go.

Conclusion

These are a few things that I have noticed interviewing candidates. To me, it made a lot of difference while making the final decision.

“The average person puts only 25% of his energy into his work. The world takes off its hat to those who put in more than 50% of their capacity, and stands on its head for those few and far between souls who devote 100%.” — Andrew Carnegie

This is not an exhaustive list by any means and does not guarantee anything. But taking these aspects into consideration would definitely add a lot of value to your interview experience.

Thanks for reading!