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!
Top comments (7)
I think the most important factor is being honest without taking into an account the situation of the interview, there's a solution for nearly every problem but some people create problems for some solutions and I think every developer should be aware about himself.
Thank you for these tips! As someone who gives a lot of technical interviews, honesty is the number one thing I look for. If you have skills bolded on your resume, I'm going to dig into those hardcore. I never judge someone for not knowing an answer, especially when I'm probing to see the depth of his or her expertise, but if someone tries to bullshit me the interview will conclude shortly.
Also, before the interview, make a list of all your skills. Figure out examples and learn to tell a story with your skillset. The biggest mistake I find myself making in my own interviews is selling myself short because I get lost in the moment and forget to advocate for skills I am not directly questioned about.
Thank you Emma. In some areas you explained are useful.
1) if somebody asks you to write an n log n sorting algorithm on a whiteboard, you are interviewing with a company you don't want to work for.
2) it is very far from clear that the interviewer wants you to succeed. there are way too many who are out to make themselves look good. worse is when you can see that their diversity is only the subtle color differences in their lumbersexual shirts.
3) if you think that it's ok to not know something, you are sadly mistaken. i had a brain fart trying to remember the keyword for constant in java (final). i was rejected for that alone.
4) if people are expecting Knuth level algorithm optimization in an interview, see #1.
Really Appreciate your effort but I have a question and I am going to share my experience here as well.
I had been to an interview and the interviewer asked me so many data structures related questions and the post was for the React Developer. Once I finished the answer to a single question he started to ask a question about answer that I have provided. I was very frustrated because he was not asking any question related to React or any front-end concept and At the End, I told him that I am going frustrated and I am no more interested in this post best of luck then.
My question is how to tackle such a situation where the interviewer is asking same question repeatedly and not coming to questions on which you will really working on.
I was gonna ask what BS stand for... but then I googled it.
It is a good article. Thank you.
It was a good article Emma. Thank you