The disruption caused by the coronavirus is presenting an opportunity for employers to think about how they can become more agile. Organizations are cutting costs and reducing headcounts to keep their business afloat during the crisis. Along with that, this brings an opportunity for organizations to change the way they hire new employees.

This is a second chance for so many employers to change their hiring process. This is becoming apparent from the fact that a lot of companies are conducting live-coding interviews instead of take-home assignments.

This is bad news for many but this is how employers are trying to ensure quality hiring. Although, this might not be a good criterion to vet the technical abilities of the candidate and to understand the value a candidate can deliver as a member of an engineering team. But this does tell you a lot about the candidate.

I have recently given a lot of interviews and I had a live-coding round with most of them. Although I am aware that challenges differ among companies, roles, and positions, I’d like to share a few tips that helped me get through the live-coding interviews. Hopefully, these will enable you to nail a live coding interview in the best way possible.

1. Practice, practice, practice

As straightforward as it may sound, the most important thing to do is practice. Many engineers are of course experienced in coding, but not often do they code with an audience looking over their shoulders.

I have experienced that this can make the engineer nervous and even completely freeze on the spot. To avoid that, It’s absolutely essential to practice and get used to the idea. Choose your favorite language and solve basic algorithms with it.

Write code

I started by solving easy algorithms from Leetcode. Start off with the easy ones and gradually move on to the harder challenges. This will enable you to dust-off on data structures and algorithms and will get you familiar with the types of challenges you could come across during the actual coding interview.

Try solving the problem, if you can’t then quickly jump to the solution. The idea is to practice writing the code. It does not matter whether you are able to solve it.

Write tests

This is the most important part of solving any problem. Think about the scenarios that you can test against. Start with basic and then think about the edge cases.

Interviewers are looking exactly for that. They know that you will be able to solve the problem, as the problems are generally simple. They want to see whether you can make it production-ready.

Here is an article that has a step-by-step explanation for writing tests for an algorithmic question! Let’s Talk Test-Driven Development It is meant to support you by focusing on “what” before “how”.towardsdatascience.com

2. Don’t jump straight in

When in the interview, many engineers tend to jump straight into the challenge, coding away from the get-go. Although an eagerness to show off your coding skills might push you in that direction, it’s better to first step back, take your time and discuss the problem at hand.

Ask any questions you might have; share any doubts you might have. This will not only provide you with a more thorough understanding of what is expected but will also enable you to avoid any pitfalls during the challenge.

Here is an article that shares the common mistakes that developers make during an interview. 3 Mistakes Junior Developers Make During an Interview Reflections on my interviews with software developerstowardsdatascience.com

3. Keep it simple; don’t over-engineer

During the interview, no one truly expects you to write a code that’s 100% correct. The most important thing is to have a code that runs at the end of the challenge, even if the solution itself is sub-optimal.

During the challenge, demonstrate how you think about the problem, how you break it into manageable chunks, and how you work towards the solution. Make it performant and demonstrate you are capable of producing a well thought and designed solution.

Keep it simple; don’t over-engineer. You won’t have the time for it, and chances are you complicate yourself or get stuck. Also, as long as you make sure the code runs, you can always still describe and discuss more optimal solutions afterward.

4. Establish a connection with the interviewer

At the beginning of the interview, make sure to create a connection with the interviewer. Ask as many questions as possible. They want to see how you think and will guide you to get to the solution. Don’t be shy in asking if the approach is what he is expecting from you.

Follow up with “how many questions will we go through in this process?” or “how much time do we have?”. The goal of these questions is to understand if the interviewer is evaluating problem-solving speed, the performance of the solution, or familiarity with the language you chose.

5. Write a solution first before explaining it to the interviewer

One of the challenges of live coding interviews is jumping between writing code and talking about code with the interviewer. For engineers who are not formally taught, this practice breaks their learned coding process, causing them to skip steps in live coding that they would not skip in a real coding environment.

This happened to me during one of the interviews. I was writing a solution for a problem that required sorting the input array before iterating over it. I mentioned that to the interviewer but failed to actually write that in the code.

Since I was not writing the code in an IDE, there was no way to figure out the part that I had missed. And because of that, I gave an incorrect answer for the time complexity of my solution.

Final Thought

In general, live-coding interviews will help you gain confidence, and if you practice enough, you will be able to easily crack it.

I have been part of interviews where I was not even allowed to Google anything, which is irritating but that gave me insights on how much I don’t know and how much I rely on Google.

Thanks for reading!