Ravi is a traveler and foodie who loves to visit off-the-beaten-track places and understand the culture, history and customs behind them.
OK, let us admit it. Coding interviews are tough.
There are nerves involved. There is uncomfortableness. There is awkwardness. There is also this strange fear that we might ‘suck’ in this interview and create a laughing stock of ourselves. The possible scenarios that can go wrong are endless.
But that brings us to a question.
Why are coding interviews tough? Is it only about the technical stuff that is asked or is it something deeper?
Charles Darwin had a similar question(no, he was not a programmer!!!) when he studied the theory of evolution. As the story goes, one day while at the London Zoo, Darwin decided to conduct an experiment. He pressed his face as close as possible to the thick glass separating him from a poisonous puff adder. He found that every time the snake would lunge at him, he would instinctively jump back several feet despite the fact that the glass was unbreakable and the snake cannot harm him.
Darwin finally concluded that human beings, despite their superior intelligence still continue to react as per their primitive survival animal instincts. This is known as the “fight-or-flight response”, a physiological reaction to perceived threats that is designed to prepare an animal to either flee from danger or fight it.
And in modern times, these threats boil down to losing reputation, becoming a subject of ridicule, or even getting tongue-tied, all of which get painfully exposed in a tough coding interview. And these possibilities are scarily real enough to make us fumble through the interview and finally lose the plot.
That said, being a good programmer does not guarantee success in a programming interview. Every interview, besides the technical stuff, is a battle of nerves in which you need to solve problems quickly, under duress, and explain your thoughts lucidly.
And here are some of the things that helped me in my career to clear interviews successfully.
Prepare well in advance
I know this sounds cliché but I have seen many programmers sitting outside the interview room and trying to learn “everything possible” in the 10 minutes before the interview. This is a recipe for disaster as not only this will make you less confident but worse still, you might jumble up key concepts during the interview.
Your ideal interview preparation should start one week prior to the interview. A simple idea can be to create a story slide of 10 to 15 slides highlighting the key areas that might be asked along with your response. A single slide can be something like this.
- Main topic 1 – Gist of the topic.
- Key Points – These can be concepts explained in a nutshell.
- Examples - something unique from my experience
- Your point of view – This is your solution
Remember, you are not writing a book here. You are just creating a flash-card like presentation which can remain fortified in your memory and come back to you as and when the interviewer asks questions. Another advantage is that you can also rehearse these slides in front of the mirror boosting your confidence further.
Yes, this might seem like a lot of preparation but there is nothing called “a lot of preparation” when the stakes are high and you need to crack the dream job of your life.
This again might sound cliché but 50% of the programmers are rejected in interviews not because of their technical skills but because they failed to exhibit the right degree of enthusiasm towards the job.
Remember, the interviewer is also evaluating you as a “right fit” for the job from all angles. Companies want candidates who are excited to join them. They appreciate those candidates who have researched their company’s products and can come up with their own unique opinion during the interview. The logic is simple; excited programmers are happy programmers and happy programmers are productive programmers.
Remember, any interview is like dating, and in dating the implicit message is that, you are one option among many and if you want to be at the top of the pile, you need to be different from others. That is why carefully preparing notes on why you find a company exciting really will increase your pass rate. Bringing prepared notes shows your preparation and subsequently your level of excitement
Get the interviewer to help you.
Yes, this is a tough one as the interviewer will not help every candidate. In fact, he will roast mercilessly most of them and will be inclined to help only a fraction of the programmers who have managed to establish some sort of trust with him.
Yes, the keyword is trust here, and establishing trust in 60 minutes is not easy but very much doable. And the trick is to understand exactly what is he expecting. Once the interview question is asked, you need to be absolutely clear with the question and if that means asking more details, do not hesitate to ask.
Ask questions even if you are almost sure of the answer. This is useful because it validates your thinking and also engages the interviewer. You also get the added advantage of getting some more time to collect your thoughts before replying with the final solution.
Remember the key is to engage with the interviewer and read his mind. If you just jump to coding without any clarification, you might miss the opportunity for your interviewer to give you further pointers or hints.
Remember showing your passion for code is not enough. To establish trust, you need to be good. People need to feel that you can do it and should feel comfortable conversing further with you.
Lastly, choose your battles carefully
Broadly speaking, there can be two types of programmers attending an interview, the pushover type, and the argumentative type.
The pushover type as the name suggests agrees with everything that the interviewer says. There is always more than one way to solve a programming interview problem. Always. There are usually multiple ways of tackling a problem, some of which might not be optimal. And good interviewers expect you to say this even if they are on the wrong track. Sometimes it is also deliberate. So agreeing with what he says might not be a good idea.
On the other extreme is the argumentative programmer who find loopholes in every concept of the interviewer. While this is good to an extent but continuously arguing just to prove your point and satisfying your ego might put you on the wrong footing. After all, nobody wants to work in the permanent conflict mode which is self-destructive behavior at its worst.
The key here is to choose your battles carefully. You need to choose only those battles where you can come out winning, showing your expertise. Software development is complex and very subjective in nature and some habits also vary a lot from programmer to programmer. So changing another programmer’s (read, the interviewer) “way of working” just to prove your point will not get you any brownie points.
Instead, concentrate your efforts on what really matters and prioritize those battles which will bring out your value faster on the table.
Passing interviews is a skill. Being a great programmer helps, but it’s only part of the picture. You need to also cultivate your mind skills to come out as a winner.
And throughout your career, you will have several “good”,” bad” and “ugly” interviews. But don’t fret too much thinking about that as every interview is a learning experience and contrary to popular opinion (and of course some self-help books), there is no sureshot, 100% guaranteed magic bullet to crack interviews. You just need to learn, prepare, attend, relearn, and improve to get better and better at it. That is, it!!
As Bo Bennett has rightly said.
“When it comes to success, there are no shortcuts.”
Ravi Rajan (author) from Mumbai on January 25, 2021:
Thanks, Umesh for your comments. These tips helped me a bit in my days.
Umesh Chandra Bhatt from Kharghar, Navi Mumbai, India on January 25, 2021: