So last week I wrote about the reflections on my tecnical interview, and I'm glad to say that after a short period of disappointment, I was able to get back on my feet, and really use this failure as fuel. Although I could be looking at things to blame about my situation, it has been a very energizing week, as I continued to push myself, set a high goal, and continue to look at what needs improvement.
As I started to focus again on data structures and algorithms (and I think I was starting to mention this last week with my point on lacking a plan or approach), I've begun to realize that I need to develop a system for doing algorithm problems. I have looked at some approaches from a previous Udemy course and other resources, and from what I've learned I wanted to share what I've assembled as my personal plan of approach to tackle these questions.
1) DON'T start coding first. Read the problem.
So the first step is a stop sign, and for good reason. Personally, I've found it very tempting to just start coding, to check smaller issues. I find this embarassing to admit, but there are times that I've console logged hello, just to make sure that the function in my Leetcode application was working. This is probably not as bad as most people's inclination to just start coding, so especially for me, I've had to stop and remind myself I start to first read the problem and think about what you will be doing first. I read on a Django developer's github "Think more, code less".
2) What are the inputs and outputs?
What are some things to look for as you read your problem? For starters, the input and output might be a good place to start. This is your starting point. Whatever your solution is going to do, knowing where you're starting and where you have to go, will help you clearly define what are the missing elements to close that gap.
3) Find the main point of the solution
Now that you've identified the bookends to your solution, try to formulate the main point of your solution, by finding the main differences between your input and your output. Start asking yourself what is required in delivering this given output. What is the question asking for you to do? There might be a lot of details missing, but to start of by staking some general idea, is very helpful in starting on the right foot to start exploring possibilities for the actual steps.
4) Use visual aids
I found this tip very helpful from a Pramp interview I was a part of. We were working on a problem that involved grids and I was impressed at how quickly he could type up an example grid on the code editor and use it to visualize his solution. You might not have similar skill, but this can be a very useful tool to understand and talk about your solution. It's not that easy to tell a story with lines of code, but it is with a picture. In the case of whiteboard interviews, this is very accessible, but even in other situations, a notepad and pen can do the trick. Especially for all us visual learners, drawing out our thinking can make it easier for everyone, you and your interviewer, to internalize the solution's main point.
5) Write down the steps of the question in comments for a brute force solution
After getting the general idea of what the problem is asking for, I usually start to write comments within the function itself to determine the steps toward a solution. After marking out basic requirements for a function, I usually start with a solution that can be followed in a step by step solution. The biggest challenge will be to find what actual algorithm or tools you will use, you should be able to vocalize your solution with the steps themselves.
6) Test out your solution with brute force solution, with given/imaginary input
After figuring out the steps, I use the steps to test various inputs that are usually given to you. If not, you can just imagine something basic to start with. Taking the input and running through the solution can help you confirm whether the steps you are taking will give you what you expected or not.
7) Begin to code
Finally, after all of that mental work, we can now begin to code. Having laid down much of the groundwork, this part should now be much easier to execute. I usually find this step consists of checking whether the steps and algorithms I used to execute those steps were accurate. Ideally, these should all be ironed out in the 5th step, but I find myself often asking things like "Do I need a for loop or a while loop?" or "Is this conditional statement covering all of the cases that I thought they would cover?". The better you do your prep, the more seamless this portion should be, but I find this often to be a phrase that consists of editting.
8) Modularize your code using the steps you created
One of the steps that I find useful is modularizing your code, which is to break up the problem into smaller steps. It's quite often that we imagine a step to the solution that is too general for the scope of the problem we are trying to solve. One of the most common solutions I find helpful is using a helper function, to try and divide up my work. With helpful names and good organization, it can also be much easier to see what you're doing.
9) Assume Darth Vader is trying to use your code, find weak points
I got this from a Udemy course, and ever since I heard this tip I have imagined an actual Darth Vader throwing all sorts of malevolant inputs into my code. I'd say it's been pretty helpful. Particularly with inputs, you want to make sure that your solution solves for more than the example input that was given to you with the problem. A lot of times I notice the first check in a solution is seeing if the input equals null. That doesn't involve the solution, but that's good code that was written aware of potential Darth Vaders.
10) Think about space and time complexity
Now this is a topic that is too big to cover in one small tip, but in general, it's important to start thinking about ways that you can optimize your solution after you complete it. This is a topic that interviewers will always ask, and it's important that you prepare. It might be tempting to walk away once your code was submitted and you get that green button, but take that "Faster than 5% of submitted solutions" be your motiviation to realize your solution kind of sucks, and you need to rethink your solution. This can be done by identifying repeated work or poor structure. Also, most of the time, solutions have a 'trick' to them, and doing remembering ideal solutions to many problems will be helpful.
Focus and Persevere. You got this!
Technical interviews are hard and so are the questions. They are meant to be difficult, so that they can be a true rubric for whether you are qualified or not. I would say one theme and attitude you should have is focus and persevere. Usually, there's a ton of details you have to keep a track of, and if you're not void of all distractions, it's easy to end up with a half baked solution. Keep practicing, focus, do your best! You got this!
Top comments (1)
Awesome