“Focus on what you have full control on” — not an official quote, but I’m pretty certain that someone, at some point throughout history, said something that is similar to this, but using fancier words of course. Regardless, having this mentality is beyond powerful and can be very helpful throughout your daily life.
But today, ladies and gents, we’re not here to talk about how to live our life, but rather how to ace our tech interview. Now I understand that there is a ton of blogposts that were written about this specific topic and most of these have the same content: “Practice, practice, practice!”, “Do mock interviews!” or “Learn one algorithm every day!”. All these tips are great and essential, but chances are, even after spending months on leetcode and hackerrank, your interviewer will ask you to solve a programming question which you have never seen before, or worse have NO CLUE how to solve it! That’s where my opening quote comes into play. We, glorious candidates, are focusing too much on the aspect of the interview that we have no control over. Now again I want to state that it is crucial to practice and get as much exposure as we can to interview questions. But what is even more important is to have the right mindset going into an interview since that is the only thing you have full control over.
I am going to give you the recipe for the right mindset. I want you to memorize these steps and go through each one of them next time you try to solve a programming question. Thank me later.
Step #1: Read the question carefully
First things first, make sure you understand what you are supposed to solve. Ask questions like “what are the inputs? what is the output?”. This seems obvious, but under the pressure of interviews, you might want to remind yourself to do this every single time to confirm your assumptions.
Step #2: Ask questions about the input
Ah my favourite! Here is where you identify your base and boundary cases. Thankfully, the questions you ask in this section are unique to all problems:
For arrays/strings:
- Can the input be empty or null?
- Can the array contain duplicates?
- Are all the characters lower case?
For numbers:
- Can the input negative?
- Are we passing large numbers that can cause a variable overflow? (specially relevant when you’re summing up Integers for example)
For graphs:
- Is my graph acyclic?
- Is my graph directed?
For trees:
- Is it a binary tree?
- Is it a binary search tree?
Keep in min that not all of these are relevant to all problems. However, as soon as you get answers to these questions, you already have a better idea of what you are dealing with.
Step #3: Think of the tools you have
I’m gonna need you to use everything you learned from those endless leetcode/hackerrank/cracking the coding interview sessions in here… EVERYTHING! Depending on the problem that you are trying to solve, think of the most common data structures and algorithms that you found useful when tackling similar problems. Here is a quick list:
Graphs — BFS, DFS, ….Trees — in-order, pre-order and post-orderArrays/Strings — 2 pointers, tries, sortingMax/Min algorithms — heapsHistograms— increasing/decreasing stacksContiguous subarrays — sliding windowPartitioning array— Knapsack/Dynamic prog
And the list goes on and on and on….
Step #4: Start with a brute-force
Here’s where the challenge starts. At this point you have enough information to solve your problem. But what do you do if you still have no clue how to solve it. BRUTE FORCE IT! Coming up with a brute force approach has several benefits. Let’s start with the obvious one. We all found ourselves unable to come up with a solution to a question during our midterms. Did you ever leave this question blank? Of course not! You wrote anything, even though it wasn’t even close to the correct answer. Well think of brute-forcing the same way. It’s obviously NOT the answer your interviewer is looking for, but it helps you set a starting point and even sometimes discover edge cases you haven’t thought about.
Step #5: Optimize and talk about time complexity
This step is where you make me proud. You take your disgusting brute-force approach and start optimizing it. Don’t forget to talk about the Big-O notation for the time and space complexities of the algorithm you came up with in step #4, as well as your optimized algorithm.
There is no secret here. Take a deep breath, relax and stay focused. If you find yourself stuck, ask your interviewer for a quick hint. It’s not ideal, but better solve it with a small help than ending the interview with that ugly piece of code you came up with in step #4 right?
Last step: Talk about testing
There you go! You came up with a beautiful solution that handles edge cases, probably used a fancy algorithm and covered the time/space complexities. One last thing you have to do is talk about how you would test your code. Usually this step involves a quick discussion with your interviewer during which you just enumerate a bunch of test cases. Nothing overcomplicated here, just showing that testing is a big part of your development process.
Conclusion
Organizing your thought process is one of the most underrated processes when it comes to interviewing. Following these 6 steps has definitely helped in all my tech interviews. I find myself focusing on the algorithm only, without worrying about whether I missed something or not.
So go ahead. Go ace that job interview and let me know if these steps work for you. Good luck!