Twitter engineer shares 5 tips on how to ace coding interviews

Coding interviews are a daunting experience. You interview for your dream job, and a random stranger asks you to think on your feet for an hour. You’re being put under a microscope, and every comment you make and every code code you write is being analyzed intensely. Beads of sweat drip from your palms, and your mind ricochets everywhere. How do I solve this problem? Will my approach handle all edge cases? How many minutes are left? What’s the facial expression of my interviewer?

I agree. It’s not an easy experience. It’s tough.

1. Come up with a game plan

Before you start writing code, you should come up with a plan on how to tackle the problem. You should spend around 5 to 20 minutes on this portion. Typically my game plan involves drawing diagrams and doing test examples. For instance, whenever I get a graph problem or a recursion problem, I like to draw a tree to identify the different states that I will be visiting and the order of states that I will be visiting. More importantly, drawing these trees highlights any logic I may need to perform, such as backtracking.

Coming up with a game plan has several advantages. First, the interviewer can inform you if you are heading in the wrong direction. If so, you just saved yourself 30 minutes from writing all that wrong code! Second, it is easy to pinpoint what data structures and variables will be needed to solve the problem.

If your initial game plan is not the most efficient, that is okay! Do not worry about defining the most efficient solution early on. This is because it is better to have a working code than a broken code or even worse no code. This tends to be the downfall of numerous interview candidates.

Once you have implemented your game plan, you can come back to refining your approach to be more optimal.

2. Always communicate

Because the interviewer does not know what is going on inside your head, you have to communicate your thought process to your interviewer. This is an important soft skill to focus on because the interviewer is evaluating your problem-solving skill and your journey to solve that problem.

I am stressing about this skill because communicating effectively landed me a job offer at a top company. During that onsite interview, a senior engineer asked me a difficult dynamic programming interview for a 45-minute session. I drew out a 2D matrix and the different states in the matrix. However, I was stuck the longest time in expressing the correct recurrence relation. I would test my recurrence relation on numerous edge cases, and sometimes, my approach would yield an incorrect answer. I would explain why my recurrence relation was wrong and discuss approaches to refine it. I communicated every step of my thought process.

At the end of the session, I had a defined recurrence relation, but no code was written. Zero code. The whole entire whiteboard was filled with a bunch of matrices and arrows. As I walked out of the interview room, I was confident that I failed that interview. I would have bet my whole life savings that I failed. A few days later, I got a call that I got the job.

So when do you need to communicate?

You need to communicate

• when you are coming up with a game plan
• when you notice that there are several approaches to solving the problem, and you identify which approach is the most efficient one
• when you see a bug in your code
• when you are stepping through your final code with a test case to validate the correctness

3. Always test your code

It is a rewarding feeling once you write out the final line of code. You feel accomplished for solving a difficult problem under pressure. However, you have not crossed the finish line yet. If you say to your interviewer you are done with your code without validating it with test cases, you could be significantly jeopardizing the interview performance.

If the interviewer catches bugs in your code and informs them to you, the interviewer will mention in the feedback review that “the interview candidate did not test code, and I identified bugs for candiate.” Not testing your code is not abiding by the most fundamental practices in software engineering. No one writes perfect code on the first try. You always need to validate your code in order to gain and maintain the trust of your customers.

So always make sure to step through your code with at least two test cases, and one of them should be an edge case. Make sure to communicate during the testing portion.

4. Ask about the input

Before you start coding, you need to think about the various forms of your input. This will determine which game plan to come up with.

You should pose these types of questions to your interviewer:

• Can my input be null?
• Is my array sorted or unsorted?
• Is it a doubly linked list or a singularly linked list?
• Will my array contain negative numbers?

How can asking this be helpful?

For instance, let’s say the task at hand is to find a target number in an array. If the interviewer confirms the array is sorted, then you can do a binary search, which has a runtime of O(log N). However, if the interviewer says the array is unsorted, then you have to do a linear search, which has a runtime of O(N). The nature of the input can change the approach to solving the problem.

5. It’s okay to ask for help but not too much

There may be situations where you have no idea what to do. It is okay to ask for guidance from the interviewer. You don’t want the interviewer to give away the solution, but you want him or her to nudge you toward the right direction. If you are able to come up with the correct solution with just a hint or two, that is still a positive feedback. It means you are still an independent thinker with the right guidance.

However, you do not want to keep asking for a lot of help. You do not want to seem you are incapable of problem solving. A good safe number of hints to use is 2. Going more than that may drastically lower your chances at getting the job offer.

Extra tip: Study Leetcode effectively

Doing more leetcode problems will not help you get a job. It is not a numbers game. You should not just memorize every leetcode solution out there. There are people who have done over 500+ leetcode problems, but they have gotten rejected at every dream company.

What you should be focusing on is the techniques and approaches. A lot of times, these techniques can be applied in other problems as well.

Some important techniques to focus on:

• rabbit and tortoise 2 pointer approach
• level order traversal using a queue
• backtracking
• drawing a recursion tree

Reason for sharing my tips

I want to help people who are struggling to land their dream job. Trust me, I had my fair share of it. It is not an easy process. It is a draining process, and sometimes it can get depressing.

No one told me any tips and tricks to succeed in the interview game. I had to go through countless interviews to come up with the best approaches in succeeding in this game. I hope my tips can at least help someone out there get his or her dream job! Please reach out to me if you do.