Let’s talk about Problem Solving 🧠 🔨 🤦

cracking nuts isn’t always so easy 🐿

Introduction

Let’s do it! Let’s talk about problem-solving. I will go over utilizing this skill in technical interviews, but many of these pointers can be applied to everyday life. Feel free to test them out, you could save a lot of time and energy with your day-to-day errands and choirs!

Problem solving is the act of defining a problem; determining the cause of the problem; identifying, prioritizing, and selecting alternatives for a solution; and implementing a solution. The problem-solving process. - asq.org

This quote seems pretty straightforward, yet also feels like a lot of mental work 😓. We have to define, determine, identify, select, test. How can one do all of this under observation, being timed, and expected to communicate in some formal professional manner.

The solution to this is pretty simple, will need to practice. The actual act of thinking critically and being able to produce a solution has a lot of steps to it. Yet it’s a lot easier if you spend time training your thinking patterns into a standard routine. There are many ways we can do this, but for the sake of this blog, I will be covering one way to standardize your thinking. 📏

The Steps

Most technical interviews are meant to gauge how well you handle challenges. Interviewers want to see you sweat, they want to throw you curveballs. It’s almost Socratic in nature, you’ll need to come prepared to accomplish this. Yet the real honing of your skills starts with these basic steps…

1. Understand
2. Explore
3. Break it down
4. Brute Force Solution
5. Refactor

Understand

Virtual code challenges are pretty useful in terms of practices, but they come up short when simulating a real experience. You can’t ask Leetcode or AlgoExpert questions for further understanding. Yet in technical interviews, it’s a great way to show your interviewer what you are thinking. I love to ask questions and this is a great place for them.

Sometimes it’s hard to switch into problem-solving mode, I find these questions help get the brain juices going. You should also share these thoughts with your interviewer, that way you're both on the same page. Communication will get you some points!

The Standard Set of Questions:
1. What are the Inputs? what do they look like?
2. What are the Outputs? what do they look like?
3. Do you have enough Information to solve this?
4. What's important about this problem, how can I label/explain them?
5. Can I explain this problem in my own words?

Explore

Often times the answers we seek are right under our own noses. You can count on clever wording and examples in technical interviews. No worries we can counter this with good ol’ fashion deduction.🕵️

Normally you’ll be given examples of outputs based on some inputs. That’s often enough to give you some great insight into the problem you are solving. Don’t take this for granted, spend time understanding what these examples actually imply.

In general, spend time understanding the following kinds of problems. Note what gets returned, see if there are any implications that will refine your solution later on. You can learn a lot about edge cases in this process, which will save you some much-needed time.

Explore these types of examples:
1. Simple
2. Complex
3. Empty
4. Invalid

Break it Down

Now that we have a solid foundation of what’s asked let’s write out a step-by-step plan. This process will help you concentrate your thinking into a targeted area. You can explain the broad strokes here, don’t waste time going into great detail. It’s more like a framework and less like a novel. 📚

You’ll also be able to iron out any misunderstandings you have. That’s really powerful.

Brute force Solution

Now we can speed time actually writing code. This is the point when you’ll type out your solution. Make it a brute force approach, nothing elegant just make sure you can get it to work. You have your ideas on paper, it’s more about show the interviewer you can take ideas and translate them into working code. Remember to mention the space and time complexity, it’s important.

This is can be a difficult area for many people, and that is ok. All that means is, you’ll need to practice in this area. Even if the working code is incorrect, you are working on this skill. Spend time here, and eventually, it should be a comfortable place. Test your code, and understand why it won’t work. Even if it takes you four hours, focus on the error. It’s worth your time.

Pro tip 💡 : Use comments in your code, if you can't get past this stage it's okay. The comments will show the interviewer where you were going with the solution. Remember this is more about seeing your process!

Refactor

Now it’s time to improve our code. So far we have shown our thinking process and even provided a working solution to the problem. It isn’t an ideal solution, but it works. Here your goal is to show a better way to solve the problem.

Explain your reasoning, mention time and space complexity, and provide a general idea of how you’ll get there if you can. If you’re stuck at this point that’s okay. Again this is an area of practice for many people. Describe what you’d like to do. You’re not always meant to solve the problem, focus on your reasoning and offer your best suggestion.

Conclusion

This isn’t easy. You’ll have to work at this skill set, but it is achievable. You need to put in the time, money, and effort to succeed. There’s no substitution for hard work and persistence. Tech companies what to hire hardworking + smart people, not one or the other. So keep at it!

Happy Coding 😊

Links

Problem Solving - https://asq.org/quality-resources/problem-solving#:~:text=Problem%20solving%20is%20the%20act,The%20problem%2Dsolving%20process