Once you’ve scheduled the interview, the real show has begun. Solving the problem is a must, but interviews are also a chance for interviewers to understand someone’s thought process and logical reasoning skills. But also, someone’s success could depend on how good at communicating and receptive they are to suggestions.

In my opinion, you need to accomplish four things in an interview:

1. Solve the problem
2. Show that you can take your thoughts and convert them into code
3. Be able to communicate why you made certain coding decisions
4. Logically reason through your code

Finishing the problem with the most optimal solution is not the only goal! Hopefully, some of the advice I’ve gotten will be helpful to whoever reads this in the future.

Know what the problem is (and constraints)

Did you know you can ask the interviewer as many questions as you want? When it comes to the original problem, it’s good to know all its constraints. I’ve made many false assumptions in the past, and it just made it harder to fix code later on.

I like to re-verbalize the problem and constraints before I attempt the problem. Finding inconsistencies or false assumptions at this stage is so much better than 20 minutes into the problem.

Think before you code

One of the mistakes I made early on in interviewing would be to start too quickly. I’ve always thought it was good to write code down immediately; however, that is no longer something I do. Moving code around or rewriting can be frustrating and prone to introduce edge case bugs.

Solve with brute force if you can’t optimize

Ideally, you can come up with an optimal solution initially and work from there. But there will be instances where you can only find a brute force solution. It’s always nice to mention that you know that it isn’t the most optimal, but you couldn’t think of a better algorithm at the time. A good interviewer can work with you on a brute force algorithm to improve the runtime. Remember, writing no code won’t help the interviewer judge your skillset.

Even in scenarios where you know a faster solution, it’s always worth mentioning how you implement the brute force method. Sometimes the constraints of the problem allow for a more straightforward solution, and it can save you time to implement that. The last thing you need is a bug in your program because you wanted to do it the ‘better’ way.

Think out loud

In an interview, you should never do one thing: sit there in silence without typing for a while (like more than a few minutes). As an interviewer, it’s hard to figure out where you are in the thought process. As a side node, it is often helpful to think aloud when coding. On top of that, the interviewer sometimes will help guide you to the correct solution and help you realize mistakes you made along the way. 

I’ve heard contradictory advice on this, but most of my interviewers were pretty helpful.

“This is what I’d google” and ask the interviewer questions.

I personally enjoy saying, “I’d google [something; i.e., how to trim the whitespace of a string],” when unsure of certain functions. I’m not the best when it comes to remembering things, and sometimes I know there exists a python function that simplifies something, but I don’t remember the name or how to use it.

Not all coding interviewers require the code to be fully functioning, and if it should, the interviewer should* help you get the code to be syntactically correct. 

Don’t do a roundabout solution for something quickly asked/googled.

O-notation in time complexity and memory!

Most people forget, but there is also memory complexity involved in technical interviews. Remembering each data structure’s O notation can help you reason through solutions, especially if an interviewer gives you a constraint (i.e., function must only store O(log N) space).

Extras:

• Test your own code :) – boundary conditions can catch you off guard, and thinking about them can help you find bugs. Running through an example verbally can be a good way of double checking your code works.
• How to change if the specs change – Sometimes, interviewers will take a simple problem and give you more and more constraints. Just be aware of that when writing a solution that might seem too simple.
• Naming and style – good variable naming and style are underrated. Focusing on that can give off a more experienced vibe when interviewing. It also improves readability when you inevitably have to debug your code.
• Figure out why the interviewer works at the company – At the end of the interview, you usually get the opportunity to ask questions to the interviewer. One of my favorite questions is how the interviewer ended up working at the company. It can give you a sense of their motivation and why they choose to stay at the current firm.