Technical interviews can be very overwhelming. Where do you start when you are given 45 minutes to solve a coding problem? How do you organize a plan when you don’t even know what the question is asking? But, whether over Zoom, on a whiteboard, or through an online portal, if you follow these six steps on each practice problem you do, you will be set up for success in the real interview.
First thing’s first. Getting the correct solution is not the most important thing in a technical interview. Let that sink in. Obviously, it’s never a bad thing to answer the question correctly; however, it’s more important to demonstrate that you are a capable and smart coder who thinks ahead. In technical interviews, interviewers are looking to understand your thought process. They want to hire someone who can work with others, not a robot who has memorized how to solve a DFS problem.
Before we start, I want to make one thing clear. You will make mistakes in your technical interviews. That is fine. I cannot stress this point enough. Mistakes are inevitable. What’s important is to stay calm. Freaking out about a mistake will only prevent your ability to think logically. Just acknowledge the issue and move forward.
1) Clarify the Problem
Once you are presented with the problem, verbally repeat it back to the interviewer in your own words. If you have any questions, ask! You don’t want to waste any time or brain power thinking about how to solve the wrong problem. Even if you are confident you understand the question, clarify it. Companies are looking to hire engineers who fully understand what they’re coding before they start typing.
2) Write the Function Signature
Depending on what language you pick, the function signature will include parameters and possibly the return type. Not only will writing the function signature keep you focused once you actually begin coding, but it also demonstrates that you are thinking ahead about what inputs and outputs are necessary.
3) Write Small Test Cases
Physically type out small test cases above your function signature. Write more than you think you need to. As you write, you can ask clarifying questions about allowed inputs. These test cases should be smaller than example test cases you may see. Make each one small enough such that you can easily run through it with pen and paper.
Problems in technical interviews are purposefully under-constrained. Do not assume that all test inputs will be in the form you expect them to be. What if you are passed an int rather than an array? Having thorough test cases already written out will help ensure that you include checks for corner cases in your code before you submit your final answer. But beyond that, it also illustrates to your interviewer that you can write shippable code.
Here’s an example. Say you are writing a function to find the smallest element in an array. You’ve already asked your interviewer and learned that the function will only be passed arrays. Your list of test cases should include: [], [0], [2], [-3], [1,5,2], [5,1,2], [5,2,1], [1,5,1], [1,-3, 3], [-1, -2, -3], [-1, 0, 2]. Note that I included an empty array, arrays with all positive values, arrays with all negative values, arrays with both positive and negative values, and arrays with repeat values. Think critically as you create your test cases. If your function is attempting to sort an array, what happens if you pass it an array that is already sorted?
4) Pseudocode
Next, both type out and verbally explain to your interviewer some pseudocode. In order to do well in a technical interview, you and your interviewer must be on the same page about your intended plan. If you silently code out the answer without explaining your logic, the interviewer will have no actual sense of your coding abilities. You also might save yourself some time by finding flaws in your logic before you’ve taken the time to get the syntax right.
You don’t need to go into too much detail with your pseudocode. Just jot down some notes and speak aloud about how you plan to organize your code.
5) Code
Now it’s time to actually implement the code! Although it may feel unnatural at first, continue to speak aloud each step that you type. It’s imperative that the interviewer understands what you’re thinking as you code.
Offer time and space complexity as you think of it. It’s okay if you don’t implement the fastest solution. But make it clear to the interviewer that you are aware that there are more efficient solutions. Verbalize that, for example, the for loop you wrote takes O(n^2) time, but if you had had more time, you would have looked into using a hash-map or a graph as a more efficient solution.
6) Test
Once you finish coding, be sure to check your code against each and every test case you brainstormed earlier. Companies want to hire employees who search for bugs in their own code before its shipped.
Importantly, test the code you actually wrote, not the code you think you wrote.
Following these six steps with each practice problem you do will build the confidence and develop the clarity in communication you need to succeed in a technical interview.
Comments