So it’s the 100th time I’ve started to learn data structures and algorithms, but this time I going to see it through…I hope. In an effort to keep this promise I’m going to write about everything I learn and the mistakes along the way. And who knows, maybe this will help someone else in turn. Welp let’s get started…

Getting Started

---

1. I actually started. Instead of starting and stopping a dozen different online courses, I picked one to give a shot for at least half of the course. If I feel like I’m not absorbing or understanding the concepts in that time I’ll move on.
2. Push through the difficult parts. It seems like every course starts with Big O Notation which completely goes over my head (for now). But I pushed through those lessons and tried to grasp as much as I could. I plan to keep practicing finding the Big O Notation while solving problems.

Resources This Week

---

• JavaScript Algorithms and Data Structures Masterclass by Colt Steele
  • This is my main learning resource this week. I bought it a little over a year ago when I first started preparing for technical interviews, so I figured why not use it now. It’s been a good course so far, but he does ramble a lot; speeding the video up helps.
• JavaScript Algorithms and Data Structures by FreeCodingCamp
  • Used this interactive course to refresh my basic JavaScript skills. They have lots of great resources.
• Google
  • For looking up methods I can’t remember how to use…or its existence.

What Have I Learned

---

The first two sections of Colt’s Masterclass are Big O Notation and Analyzing Performance of Arrays and Objects where he introduced and explained Big O Notation, and it’s relationship to showing the performance rates of arrays and objects. Here is what I got from them:

Big O Notation – O(1)

• If a function is O(1) it will have a constant runtime no matter how large the data sets passed in are.
• These are the best performance wise.

Big O Notation – O(n)

• If a function is O(n) it’s runtime is based on the size of the data sets.
• Larger data sets = slower runtime

Step 1: Understanding the problem

If you’re in an interview ask questions to clarify anything about the question. You can repeat the question in your own words. Check what the expected input and output should be. For example, will the input only be an array of letters or can it contain numbers; will the output need to be a Boolean or a new array. See if you need to check for any edge cases.

Step 2: Concrete Examples

Get examples of inputs and outputs. Input = [1,2,3] Output = [1, 4, 9]

Step 3: Break It Down

Now it’s time to figure out the steps needed to go from your input to the expected output. You can pseudo code or stub out code you think you may need. If you haven’t been thinking out loud you should be it’s good practice for when you are interviewing. They want to know what and how you’re thinking of solving the problem and may offer up some hints if you’re going in the wrong direction.

Step 4: Solve or Simplify

If you pseudo coded, then it’s time to solve the problem with real code. Start with the easiest way you can solve the problem. Then simplify it. If you stubbed code out, then make sure the solution works before you simplify.

Step 5: Look Back and Refactor

Once you solve the problem be able to talk about your journey to the solution, and if or how you would refactor it.

---

In the next article, I’ll be going over how I used these steps and a pattern (Colt called ‘frequency counter pattern’) to approach and solve an algorithm problem. Hope this was helpful to you as it was for me. Let’s connect if you’re looking for someone to practice with or just to chit chat. While you wait learn about my software engineering journey. Happy coding!