Technical interviews are scary; the thought of having to write code on a whiteboard is anxiety-inducing.

Throughout our research and years in the industry we've put together some tips for helping you during your coding challenges.

Whether you're frontend or backend, knowing these tips, and practicing them before your interview, will ensure you put your best foot forward and hopefully land a job offer!

Do you have any additional tips? Leave them in the comments below!

Communication is key in any interview but in technical interviews it's imperative you explain your thought process.

Your interviewer wants you to succeed, but in order to help you, and potentially give you hints, they need to know your thought process.

If you need a minute to think, tell your interviewer! There's no shame in saying "I just need a second to think."

But if you're internally reasoning between two solutions, talk it out.

For example, if you're trying to decide the best method of sorting an array of integers from lowest to highest.

"I have two ideas in my mind. The first requires brute forcing the solution where we would compare every element in the index to its neighbor and if the integer on the right is lower in value than the integer on the left, swap them.

But this isn't optimal as it would require O(n^2) checks to ensure everything is sorted. I know merge sort is a more optimized sorting algorithm with a worst-case runtime of O(n log n), however I'm a bit unsure how to code that."

Stating your thoughts out loud will allow the interviewer to guide you and is often a chance to showcase your knowledge about data structures and algorithms.

In almost every case the question you receive for a coding challenge will have a few holes in it. The interviewer won't give you all of the information up front because they want to see you deductive reasoning and problem solving skills.

Thus it's important to think through all of the key information you'll need to solve the problem, and ask if something is unclear.

If you receive a question and you have no idea where to start, don't panic; we've all had this moment!

First, think about the information you have. What pieces of information do you need to solve this problem?

Second, what are you missing? In the previous tip we mentioned asking clarifying questions. This is great practice if you're stuck or need a moment.

Next, at the core of the problem, how would you brute-force this answer? In tip one we had the example problem of sorting an array of integers from lowest to highest.

The brute force method would be bubble sort where we're comparing every integer against every other integer and swapping if needed. And even though this isn't an optimized solution, getting the brute-force solution up on a whiteboard will allow you to refactor to something more optimal.

Is it possible to remove one of the nested for-loops in our sorting algorithm? Perhaps we can refactor to use a divide and conquer algorithm like merge sort!

A brute-force solution is better than no solution.

There will inevitably come a time when you simply don't know the answer to a question.

For example if you're asked "what's the difference between == and ===?" and you simply have no idea, just tell the interviewer!

You might say: "I'm not positive but if I had to make an educated guess I would say..."

This indicates that you're self-aware and honest but you're still willing to take a guess.

If you simply BS the answer and pretend you know what you're talking about, this indicates that you're not a truthful person and you likely won't receive a job offer.

Additionally if you ever receive a coding challenge question that you've seen the solution for or have already gotten in a past interview, be honest about it.

Your interviewer will be able to tell if you're regurgitating a memorized answer so it's best to be transparent. Plus your interviewer should appreciate your honesty.

Once you have a solution down, take ten minutes to test it. What are the obvious use cases? What are the corner cases? You'll likely find holes in your solution and can go back and refine them.

If you spit out an answer without testing it, you probably won't receive a job offer.

For example if you're asked to write an algorithm which determines whether there is a loop (or a broken edge) in a binary tree, think about the possible use cases.

• Does your algorithm work if there are no nodes in the tree?
• How about if there is only a root node
• What if there is no broken edge/loop?
• What if the broken edge is on the last node in the tree (bottom right)?
• What if it's in the first level?

These questions will allow you to refine your solution. It might help you determine whether you want to use depth-first search over breadth-first search.

Testing is important! So don't forget it!

Keeping these five tips in mind will help calm your anxiety about coding interviews. Focus on solving the problem at hand while communicating clearly. You'll receive a job offer in no time!

You can check out our full episode for more tips!