But sometimes it would be nice if there were a visualization showing the algorithms behind these problems.

In this tutorial, we will build out a visualization showing a couple of approaches to a popular LeetCode problem called Two Sum. We will use vanilla HTML, CSS, and JavaScript to build this project out.

Table of Contents

• Prerequisites
• Project Setup
• How to Solve LeetCode's Two Sum Problem
  • Description
  • Brute Force Approach
  • Brute Force JavaScript Solution and Time Complexity
  • Map Approach and Solution
  • Time Complexity for the Map Solution
• Overview for the Two Sum Visualization
• Adding the Brute Force Visualization
  • Creating the const and let Variables
  • Creating the getClassName Function
  • Creating the bruteForceApproach Function
• How to Disable the bruteForceSolutionBtn When the Animation is in Progress
• Adding the Map Solution Visualization
  • Creating the const Variables
  • Creating the optimalApproach Async Function
• How to Reset the Table Output for the Map Solution
• Final Solution Code and Live Example
• Conclusion

Prerequisites

This tutorial assumes that you have basic knowledge of HTML, CSS and JavaScript. If you haven't gone through a beginner course in any of those languages, then I would suggest starting with these resources:

• freeCodeCamp's Responsive Web Design Certification
• freeCodeCamp's JavaScript Algorithms and Data Structures Certification

This tutorial also assumes that you have some basic knowledge of how to work with a code editor or IDE. If not, then I would suggest looking into these resources:

• Visual Studio Code Crash Course
• How to Use CodePen
• How to Use Replit

Project Setup

You are free to build out this project in either your local code editor of choice, or through an online IDE or editor like CodePen, CodeSandbox, or Replit.

This project will consist of three files: index.html, index.js, and styles.css. Since this project is going to mainly focus on JavaScript, I have supplied all of the HTML and CSS in this GitHub repo here.

You are free to fork and clone the repository, or you can copy the code found in the HTML and CSS files and add it to your project.

Once you get your project environment setup, then you should start the local server and see this result on the screen:

Visualization styles for Leetcode's Two Sum problem

How to Solve LeetCode's Two Sum problem

Before we can build out the visualization for this problem, we need to first understand and solve the problem.

Description

For this problem, you will be given a list of numbers in any order and a target number. The goal is to find the pair of numbers that adds up to the target and return an array of indices for that pair of numbers.

In this example, we have the following list and target number:

[2,7,11,15]
target: 9

The numbers 2 and 7 equal 9 so we would return [0,1] because that represents the indices for where the pair of numbers can be found in the array.

For this problem, you can assume there will be at least two numbers or more in the array and there will only be one possible solution.

So for example you can not have this input here which produces no solution because there are no two numbers in that list that add up to the target.

[1,2,3,4,5]
target: 55

You will also not get an input with multiple solutions. The following input has two answers of [0,1] and [1,2] which goes against the rules of this problem.

[3,3,3]
target: 6

Brute Force Approach

The more intuitive approach would be to start at the beginning of the list of numbers and compare each possible pair of numbers until we find the pair that adds up to the target.

Let's take a look at this example here:

[11, 15, 2, 7]
target:9

We can start with the first number in the list (11) and check each possible pair and see if it adds up to the target number (9).

11 + 15 = 9? NO
11 + 2 = 9? NO
11 + 7 = 9? NO

Since none of those pairs equal the target (9), then we move to the second number in the list (15) and check all possible pairs. There is no need to check 11+15 because we already checked that earlier.

15 + 2 = 9? NO
15 + 7 = 9? NO

Since none of those pairs equal the target (9), then we move to the third number in the list (2) and check all possible pairs.

2 + 7 = 9? YES!!!

Now, we have found the pair that adds up to the target we would return [2,3] because that represents the indices for where the pair of numbers can be found in the array.

Brute Force JavaScript Solution and Time Complexity

This solution uses a nested for loop which would be an O(n²) time complexity. The outer loop is used to get the current number in the list and the inner loop is used to check if the sum of the current number and other numbers in the list add up to the target.

/**
 * @param {number[]} nums
 * @param {number} target
 * @return {number[]}
 */

var twoSum = function (nums, target) {
  if (nums.length === 2) return [0, 1];

  for (let i = 0; i < nums.length; i++) {
    const currentNum = nums[i];
    for (let j = i + 1; j < nums.length; j++) {
      if (currentNum + nums[j] === target) return [i, j];
    }
  }
};

Note: I have added an additional check in my solution to check if the input array has only two numbers. In that case, we immediately return [0,1] because those are the only possible indices for that test case.

 if (nums.length === 2) return [0, 1];

So far, our input arrays have been very small. But if we had an input array of 100, 500, or 1000+ numbers, then it could take a while to find the pair that adds up to the target.

In the next section, we are going to take a look at a solution that utilizes JavaScript's Map object and runs in linear time O(n).

Map Approach and Solution

In the brute force approach, we started at the beginning of the array and compared all possible pairs of numbers until we found the pair that added up to the target. But in this approach we can use JavaScript's Map object and one for loop to find that pair.

JavaScript's Map object is a collection of key-value pairs that allows for quick lookups and has built in methods like set(), get() and has().

Let's work with the same example from earlier:

[11, 15, 2, 7]
target:9

We can start looping through the array and look at the current number in the list which would be nums[i]. We also want to create a new map object which will be empty to start.

const map = new Map();

for(let i=0; i<nums.length; i++){

}

Inside our loop, we need to calculate the difference which will be the target minus the current number.

    const map = new Map();

    for(let i=0; i<nums.length; i++){
        const difference = target - nums[i]
    }

Since we know there can only be two numbers that add up to the target, we can check if the difference is in the map. If so, we have found the pair and can return the indices. Otherwise, we can add that current number to the map along with its index.

    const map = new Map();

    for(let i=0; i < nums.length; i++) {
        const difference = target - nums[i]

        if(map.has(difference)) {
            return [map.get(difference), i]
        } else {
            map.set(nums[i], i)
        }
    }

In the following code, the has() method is used to check if the following key is in the map object. This method will return a boolean of true or false.

map.has(difference)

The get() method is used to return that element from the map.

 if(map.has(difference)) {
   return [map.get(difference), i]
 }

The set() method will add or update an entry in the map with a key and value.

else {
  map.set(nums[i], i)
}

Here is the complete code for this approach:

/**
 * @param {number[]} nums
 * @param {number} target
 * @return {number[]}
 */
var twoSum = function(nums, target) {
    if(nums.length === 2) return [0,1]

    const map = new Map();

    for (let i = 0; i < nums.length; i++) {
        const difference = target - nums[i]

        if (map.has(difference)) {
            return [map.get(difference), i]
        } else {
            map.set(nums[i], i)
        }
    }

};

Time Complexity for the Map Solution

This solution would be a linear time complexity O(n). Since we are only using one loop instead of two, we have improved on the time complexity and no longer running in quadratic time O(n²) like we were earlier.

In the next few sections, we are going to start to build out the visualizations for each of these approaches.

Overview for the Two Sum Visualization

The goal of this project is to create visualizations for both the map and brute force solutions.

For the brute force solution, we will show what is it like to walk through each pair of numbers until we find the pair that adds up to the target.

Brute Force approach visualization

For the map solution, we will show the map being built out and checking for the pair that adds up to the target.

Map solution visualization

Adding the Brute Force Visualization

Creating the const and let Variables

We first need to create const variables and assign them the result of accessing the HTML elements responsible for displaying the brute force solution button and output.

const bruteForceSolutionBtn = document.getElementById("brute-force-visual-btn");
const bruteForceNumbersOutput = document.querySelector(
  "#brute-force-output > .numbers-array"
);
const bruteForceTextOutput = document.querySelector(
  "#brute-force-output > .result-text"
);

The next step is to create const variables for the test case array and target that will be used for both visualizations.

const testCaseArray = [11, 15, 2, 7];
const target = 9;

Then, we need to create the let variables that will represent the current number we are looking at in the outer loop and the compliment number we are looking at in the inner loop.

let currentNum;
let currentCompliment;

Creating the getClassName Function

In our visualization we want to show the user the current pair of numbers we are checking by applying different colored borders around them. The current number will have a green border around it and the current compliment number will have a blue border around it.

In order to dynamically update these styles over time, we need to create a function that will be responsible for adding the appropriate classes to the current number and it compliment.

First, start by creating a new getClassName function that takes in a num parameter.

const getClassName = (num) => {

};

Inside that function, create a switch statement that has the num for the expression we are checking for.

const getClassName = (num) => {
  switch (num) {

  }
};

The first case should check for currentNum and return a string for the current-num class.

const getClassName = (num) => {
  switch (num) {
    case currentNum:
      return "class='current-num'";
  }
};

The second case should check for the currentCompliment and return a string for the compliment-num class.

const getClassName = (num) => {
  switch (num) {
    case currentNum:
      return "class='current-num'";
    case currentCompliment:
      return "class='compliment-num'";
  }
};

For the default case, it should return an empty string because we are not going to apply any classes for that element.

const getClassName = (num) => {
  switch (num) {
    case currentNum:
      return "class='current-num'";
    case currentCompliment:
      return "class='compliment-num'";
    default:
      return "";
  }
};

Creating the bruteForceApproach Function

This function will be responsible for executing the brute force solution and displaying the visualization on the page.

We first need to create the bruteForceApproach function which will be an async function.

const bruteForceApproach = async () => {

};

Then, we need to add the outer loop for our test case array.

const bruteForceApproach = async () => {
  for (let i = 0; i < testCaseArray.length; ++i) {

  }
};

Inside the for loop, update the currentNum to assign it the value of the current number we are looking at in the test case array.

const bruteForceApproach = async () => {
  for (let i = 0; i < testCaseArray.length; ++i) {
    currentNum = testCaseArray[i];
  }
};

Next, create the inner for loop.

const bruteForceApproach = async () => {
  for (let i = 0; i < testCaseArray.length; ++i) {
    currentNum = testCaseArray[i];
    for (let j = i + 1; j < testCaseArray.length; ++j) {

    }
  }
};

Inside the inner for loop, update the currentCompliment number and assign it the value of testCaseArray[j]. This is meant to represent each number to the right of the current number.

const bruteForceApproach = async () => {
  for (let i = 0; i < testCaseArray.length; ++i) {
    currentNum = testCaseArray[i];
    for (let j = i + 1; j < testCaseArray.length; ++j) {
      currentCompliment = testCaseArray[j];
    }
  }
};

Next, we need to add a setTimeout which will delay the visual changes made to the markup by one second. This is what is going to help create the animated effect of showing the different pairs of numbers.

const bruteForceApproach = async () => {
  for (let i = 0; i < testCaseArray.length; ++i) {
    currentNum = testCaseArray[i];
    for (let j = i + 1; j < testCaseArray.length; ++j) {
      currentCompliment = testCaseArray[j];
      await new Promise((resolve) => setTimeout(resolve, 1000));
    }
  }
};

Then we need to update the HTML for the output. Start by assigning the test case array to bruteForceNumbersOutput.innerHTML.

const bruteForceApproach = async () => {
  for (let i = 0; i < testCaseArray.length; ++i) {
    currentNum = testCaseArray[i];
    for (let j = i + 1; j < testCaseArray.length; ++j) {
      currentCompliment = testCaseArray[j];
      await new Promise((resolve) => setTimeout(resolve, 1000));

      bruteForceNumbersOutput.innerHTML = testCaseArray;
    }
  }
};

Then, we want to use the map method on the array, to create a new array of span elements which represents each number in the array along with the styles. We also need to chain the join method on that to remove the commas that the map method adds when the new array is created.

const bruteForceApproach = async () => {
  for (let i = 0; i < testCaseArray.length; ++i) {
    currentNum = testCaseArray[i];
    for (let j = i + 1; j < testCaseArray.length; ++j) {
      currentCompliment = testCaseArray[j];
      await new Promise((resolve) => setTimeout(resolve, 1000));

      bruteForceNumbersOutput.innerHTML = testCaseArray
        .map(
          (num, index) =>
            `
            <span ${getClassName(num)}>
            ${testCaseArray[index]}
            </span>
          `
        )
        .join("");
    }
  }
};

If we don't find a pair that adds up to the target, then we want to display a message to the user. Update the text content for the bruteForceTextOutput and assign it the following message:

const bruteForceApproach = async () => {
  for (let i = 0; i < testCaseArray.length; ++i) {
    currentNum = testCaseArray[i];
    for (let j = i + 1; j < testCaseArray.length; ++j) {
      currentCompliment = testCaseArray[j];
      await new Promise((resolve) => setTimeout(resolve, 1000));

      bruteForceNumbersOutput.innerHTML = testCaseArray
        .map(
          (num, index) =>
            `
            <span ${getClassName(num)}>
            ${testCaseArray[index]}
            </span>
          `
        )
        .join("");

      bruteForceTextOutput.textContent = `Does the sum of ${currentNum} + ${currentCompliment} equal ${target}? NO!`;
    }
  }
};

The last piece is to add a condition that checks if we found the pair of numbers that adds up to the target. If so, then we can display that final indices array and return from the function.

  if (currentNum + currentCompliment === target) {
      bruteForceTextOutput.textContent = `Final indices: [${i}, ${j}]`;
      return;
  }

To test out the brute force visualization, we will need to add an event listener to the bruteForceSolutionBtn. The event listener should listen for a "click" event and should reference the bruteForceApproach function.

bruteForceSolutionBtn.addEventListener("click", bruteForceApproach);

This should be your complete code so far:

const bruteForceSolutionBtn = document.getElementById("brute-force-visual-btn");
const bruteForceNumbersOutput = document.querySelector(
  "#brute-force-output > .numbers-array"
);
const bruteForceTextOutput = document.querySelector(
  "#brute-force-output > .result-text"
);
const testCaseArray = [11, 15, 2, 7];
const target = 9;
let currentNum;
let currentCompliment;

const getClassName = (num) => {
  switch (num) {
    case currentNum:
      return "class='current-num'";
    case currentCompliment:
      return "class='compliment-num'";
    default:
      return "";
  }
};

const bruteForceApproach = async () => {
  for (let i = 0; i < testCaseArray.length; ++i) {
    currentNum = testCaseArray[i];
    for (let j = i + 1; j < testCaseArray.length; ++j) {
      currentCompliment = testCaseArray[j];
      await new Promise((resolve) => setTimeout(resolve, 1000));

      bruteForceNumbersOutput.innerHTML = testCaseArray
        .map(
          (num, index) =>
            `
            <span ${getClassName(num)}>
            ${testCaseArray[index]}
            </span>
          `
        )
        .join("");

      bruteForceTextOutput.textContent = `Does the sum of ${currentNum} + ${currentCompliment} equal ${target}? NO!`;

      if (currentNum + currentCompliment === target) {
        bruteForceTextOutput.textContent = `Final indices: [${i}, ${j}]`;
        return;
      }
    }
  }
};

bruteForceSolutionBtn.addEventListener("click", bruteForceApproach);

Try out your visualization by clicking on the "Show Visualization" button for the Brute force approach.

Result of clicking the "show visualization" button for brute force approach

How to Disable the bruteForceSolutionBtn When the Animation is in Progress

If you try to click on the bruteForceSolutionBtn multiple times in a row, you will see glitches in the animation. To fix that, we should disable the button when the animation is running and then re-enable it when the animation is complete.

Inside the bruteForceApproach function, set the disabled attribute for the bruteForceSolutionBtn.

const bruteForceApproach = async () => {
  bruteForceSolutionBtn.setAttribute("disabled", "");

Inside the if statement, remove the disabled attribute for the bruteForceSolutionBtn.

   if (currentNum + currentCompliment === target) {
        bruteForceTextOutput.textContent = `Final indices: [${i}, ${j}]`;
        bruteForceSolutionBtn.removeAttribute("disabled");
        return;
   }

Here is the complete code with the fix:

const bruteForceSolutionBtn = document.getElementById("brute-force-visual-btn");
const bruteForceNumbersOutput = document.querySelector(
  "#brute-force-output > .numbers-array"
);
const bruteForceTextOutput = document.querySelector(
  "#brute-force-output > .result-text"
);
const testCaseArray = [11, 15, 2, 7];
const target = 9;
let currentNum;
let currentCompliment;

const getClassName = (num) => {
  switch (num) {
    case currentNum:
      return "class='current-num'";
    case currentCompliment:
      return "class='compliment-num'";
    default:
      return "";
  }
};

const bruteForceApproach = async () => {
  bruteForceSolutionBtn.setAttribute("disabled", "");

  for (let i = 0; i < testCaseArray.length; ++i) {
    currentNum = testCaseArray[i];
    for (let j = i + 1; j < testCaseArray.length; ++j) {
      currentCompliment = testCaseArray[j];
      await new Promise((resolve) => setTimeout(resolve, 1000));

      bruteForceNumbersOutput.innerHTML = testCaseArray
        .map(
          (num, index) =>
            `
            <span ${getClassName(num)}>
            ${testCaseArray[index]}
            </span>
          `
        )
        .join("");

      bruteForceTextOutput.textContent = `Does the sum of ${currentNum} + ${currentCompliment} equal ${target}? NO!`;

      if (currentNum + currentCompliment === target) {
        bruteForceTextOutput.textContent = `Final indices: [${i}, ${j}]`;
        bruteForceSolutionBtn.removeAttribute("disabled");
        return;
      }
    }
  }
};

bruteForceSolutionBtn.addEventListener("click", bruteForceApproach);

Try out the visualization again, and now you should see that the button is disabled when the animation is running.

Image showing how button is disabled when animation is showing

Adding the Map Solution Visualization

Creating the const Variables

We are going to create some new const variables which represent the optimal solution button element, output, and table elements for the animation.

const optimalSolutionBtn = document.getElementById("optimal-visual-btn");
const currentValueOutput = document.getElementById("current-value-output");
const finalOptimalSolutionResult = document.getElementById(
  "final-optimal-result"
);
const table = document.getElementById("table-output");
const tableBodyOutput = document.getElementById("map-table-body");

Here is the complete list of variable declarations for both visualizations:

const bruteForceSolutionBtn = document.getElementById("brute-force-visual-btn");
const bruteForceNumbersOutput = document.querySelector(
  "#brute-force-output > .numbers-array"
);
const bruteForceTextOutput = document.querySelector(
  "#brute-force-output > .result-text"
);
const optimalSolutionBtn = document.getElementById("optimal-visual-btn");
const currentValueOutput = document.getElementById("current-value-output");
const finalOptimalSolutionResult = document.getElementById(
  "final-optimal-result"
);
const table = document.getElementById("table-output");
const tableBodyOutput = document.getElementById("map-table-body");

const testCaseArray = [11, 15, 2, 7];
const target = 9;
let currentNum;
let currentCompliment;

Creating the optimalApproach Async Function

The first step is to create the new optimalApproach function which will be an async function. You can add this below your bruteForceApproach function.

const optimalApproach = async () => {

};

Just like the bruteForceApproach function, we want to disable the button when the animation starts to prevent users from clicking it multiple times and breaking the animation.

const optimalApproach = async () => {
  optimalSolutionBtn.setAttribute("disabled", "");
};

When the page first loads, the table is hidden by default. We want to show the table element when the animation starts.

const optimalApproach = async () => {
  optimalSolutionBtn.setAttribute("disabled", "");
  table.style.display = "block";
};

Each time we run this animation, we want to display messages to the user on if we have found the correct pair or not. At the beginning of the animation, we want to clear the previous output.

const optimalApproach = async () => {
  optimalSolutionBtn.setAttribute("disabled", "");
  table.style.display = "block";
  currentValueOutput.innerHTML = "";
};

Then, we need to create an empty map object which will eventually be updated over time in the for loop.

const optimalApproach = async () => {
  optimalSolutionBtn.setAttribute("disabled", "");
  table.style.display = "block";
  currentValueOutput.innerHTML = "";
  const map = new Map();
};

Next, we need to create a for loop which will be responsible for looping through each number in the array and updating the animation overtime.

const optimalApproach = async () => {
  optimalSolutionBtn.setAttribute("disabled", "");
  table.style.display = "block";
  currentValueOutput.innerHTML = "";
  const map = new Map();

  for (let i = 0; i < testCaseArray.length; ++i) {

  }
};

Inside the loop, we need to add the expression for calculating the difference.

const optimalApproach = async () => {
  optimalSolutionBtn.setAttribute("disabled", "");
  table.style.display = "block";
  currentValueOutput.innerHTML = "";
  const map = new Map();

  for (let i = 0; i < testCaseArray.length; ++i) {
    const difference = target - testCaseArray[i];
  }
};

Then, we need to add a setTimeout which will delay the changes by 2 seconds in the HTML markup and help with the animation effect.

const optimalApproach = async () => {
  optimalSolutionBtn.setAttribute("disabled", "");
  table.style.display = "block";
  currentValueOutput.innerHTML = "";
  const map = new Map();

  for (let i = 0; i < testCaseArray.length; ++i) {
    const difference = target - testCaseArray[i];

    await new Promise((resolve) => setTimeout(resolve, 2000));
  }
};

We then need to add an if statement to check if the map has the difference value.

const optimalApproach = async () => {
  optimalSolutionBtn.setAttribute("disabled", "");
  table.style.display = "block";
  currentValueOutput.innerHTML = "";
  const map = new Map();

  for (let i = 0; i < testCaseArray.length; ++i) {
    const difference = target - testCaseArray[i];

    await new Promise((resolve) => setTimeout(resolve, 2000));

    if (map.has(difference)) {

    }
  }
};

Inside the if statement, we need to update the text content to show the final indices array result on the screen. We will use the get method to get the index value from the map.

 if (map.has(difference)) {
      finalOptimalSolutionResult.textContent = `Final indices: [${map.get(
        difference
      )}, ${i}]`;
 }

We also need to update the output for displaying a message that shows we have found the pair of numbers that adds up to the target.

  if (map.has(difference)) {
      finalOptimalSolutionResult.textContent = `Final indices: [${map.get(
        difference
      )}, ${i}]`;
      currentValueOutput.innerHTML = `
      <p>Difference(${difference}) = target(${target}) - current number(${testCaseArray[i]})</p>
      <p>Is the difference(${difference}) in our map? YES, we found that pair of numbers that add up to the target.</p>
    `;
  }

We also need to remove the disabled attribute from the optimalSolutionBtn and return from the function.

  if (map.has(difference)) {
      finalOptimalSolutionResult.textContent = `Final indices: [${map.get(
        difference
      )}, ${i}]`;
      currentValueOutput.innerHTML = `
      <p>Difference(${difference}) = target(${target}) - current number(${testCaseArray[i]})</p>
      <p>Is the difference(${difference}) in our map? YES, we found that pair of numbers that add up to the target.</p>
    `;
      optimalSolutionBtn.removeAttribute("disabled");
      return;
  }

If the pair has not been found, then we need to add an else clause.

  if (map.has(difference)) {
      finalOptimalSolutionResult.textContent = `Final indices: [${map.get(
        difference
      )}, ${i}]`;
      currentValueOutput.innerHTML = `
      <p>Difference(${difference}) = target(${target}) - current number(${testCaseArray[i]})</p>
      <p>Is the difference(${difference}) in our map? YES, we found that pair of numbers that add up to the target.</p>
    `;
      optimalSolutionBtn.removeAttribute("disabled");
      return;
  } else {

  }

Inside the else clause, we need to update the message to show that we have not found the pair and that the current number testCaseArray[i] is going to be added to the map along with its index value.

else {
      currentValueOutput.innerHTML = `
        <p>Difference(${difference}) = target(${target}) - current number(${testCaseArray[i]})</p>
        <p>Is the difference(${difference}) in our map? No.</p>
        <p>Add the current number ${testCaseArray[i]} to our map.</p>
      `;
}

We then need to update the table output with the current number and its index value.

else {
      currentValueOutput.innerHTML = `
        <p>Difference(${difference}) = target(${target}) - current number(${testCaseArray[i]})</p>
        <p>Is the difference(${difference}) in our map? No.</p>
        <p>Add the current number ${testCaseArray[i]} to our map.</p>
      `;
      tableBodyOutput.innerHTML += `
      <tr>
        <td>${testCaseArray[i]}</td>
        <td>${i}</td>
      </tr>
    `;
}

Lastly, use the set method to set the current number and index value in the map.

else {
      currentValueOutput.innerHTML = `
        <p>Difference(${difference}) = target(${target}) - current number(${testCaseArray[i]})</p>
        <p>Is the difference(${difference}) in our map? No.</p>
        <p>Add the current number ${testCaseArray[i]} to our map.</p>
      `;
      tableBodyOutput.innerHTML += `
      <tr>
        <td>${testCaseArray[i]}</td>
        <td>${i}</td>
      </tr>
    `;
      map.set(testCaseArray[i], i);
}

Here is the complete code for your optimalApproach function.

const optimalApproach = async () => {
  optimalSolutionBtn.setAttribute("disabled", "");
  table.style.display = "block";
  currentValueOutput.innerHTML = "";
  const map = new Map();

  for (let i = 0; i < testCaseArray.length; ++i) {
    const difference = target - testCaseArray[i];

    await new Promise((resolve) => setTimeout(resolve, 2000));

    if (map.has(difference)) {
      finalOptimalSolutionResult.textContent = `Final indices: [${map.get(
        difference
      )}, ${i}]`;
      currentValueOutput.innerHTML = `
      <p>Difference(${difference}) = target(${target}) - current number(${testCaseArray[i]})</p>
      <p>Is the difference(${difference}) in our map? YES, we found that pair of numbers that add up to the target.</p>
    `;
      optimalSolutionBtn.removeAttribute("disabled");
      return;
    } else {
      currentValueOutput.innerHTML = `
        <p>Difference(${difference}) = target(${target}) - current number(${testCaseArray[i]})</p>
        <p>Is the difference(${difference}) in our map? No.</p>
        <p>Add the current number ${testCaseArray[i]} to our map.</p>
      `;
      tableBodyOutput.innerHTML += `
      <tr>
        <td>${testCaseArray[i]}</td>
        <td>${i}</td>
      </tr>
    `;
      map.set(testCaseArray[i], i);
    }
  }
};

To test out this visualization, add an event listener to the optimalSolutionBtn and pass in the "click" event and optimalApproach function reference.

optimalSolutionBtn.addEventListener("click", optimalApproach);

When you click on the "Show Visualization" button for the map solution, you should see the animation, as shown below:

Visualization for map solution

How to Reset the Table Output for the Map Solution

If you try to run the animation multiple times, then you will see that the table shows the results from the previous run.

Table showing results from the previous run

To fix this, we can reset the table before each run of the animation. Start by creating a resetTable function above your optimalApproach function.

const resetTable = () => {

};

const optimalApproach = async () => {
    .........

Inside that function, clear out the table and final text results.

const resetTable = () => {
  tableBodyOutput.innerHTML = "";
  finalOptimalSolutionResult.textContent = "";
};

Call the resetTable function inside your optimalApproach function in order to see the results of resetting the table.

const optimalApproach = async () => {
  resetTable();
  optimalSolutionBtn.setAttribute("disabled", "");
    ...........

Test out your animation again, and now you should see that the table results reset before each new animation run.

Final Solution Code and Live Example

Here is the complete JavaScript solution code for both visualizations:

const bruteForceSolutionBtn = document.getElementById("brute-force-visual-btn");
const bruteForceNumbersOutput = document.querySelector(
  "#brute-force-output > .numbers-array"
);
const bruteForceTextOutput = document.querySelector(
  "#brute-force-output > .result-text"
);
const optimalSolutionBtn = document.getElementById("optimal-visual-btn");
const currentValueOutput = document.getElementById("current-value-output");
const finalOptimalSolutionResult = document.getElementById(
  "final-optimal-result"
);
const table = document.getElementById("table-output");
const tableBodyOutput = document.getElementById("map-table-body");

const testCaseArray = [11, 15, 2, 7];
const target = 9;
let currentNum;
let currentCompliment;

const getClassName = (num) => {
  switch (num) {
    case currentNum:
      return "class='current-num'";
    case currentCompliment:
      return "class='compliment-num'";
    default:
      return "";
  }
};

const bruteForceApproach = async () => {
  bruteForceSolutionBtn.setAttribute("disabled", "");

  for (let i = 0; i < testCaseArray.length; ++i) {
    currentNum = testCaseArray[i];
    for (let j = i + 1; j < testCaseArray.length; ++j) {
      currentCompliment = testCaseArray[j];
      await new Promise((resolve) => setTimeout(resolve, 1000));

      bruteForceNumbersOutput.innerHTML = testCaseArray
        .map(
          (num, index) =>
            `
              <span ${getClassName(num)}>
              ${testCaseArray[index]}
              </span>
            `
        )
        .join("");

      bruteForceTextOutput.textContent = `Does the sum of ${currentNum} + ${currentCompliment} equal ${target}? NO!`;

      if (currentNum + currentCompliment === target) {
        bruteForceTextOutput.textContent = `Final indices: [${i}, ${j}]`;
        bruteForceSolutionBtn.removeAttribute("disabled");
        return;
      }
    }
  }
};

const resetTable = () => {
  tableBodyOutput.innerHTML = "";
  finalOptimalSolutionResult.textContent = "";
};

const optimalApproach = async () => {
  resetTable();
  optimalSolutionBtn.setAttribute("disabled", "");
  table.style.display = "block";
  currentValueOutput.innerHTML = "";
  const map = new Map();

  for (let i = 0; i < testCaseArray.length; ++i) {
    const difference = target - testCaseArray[i];

    await new Promise((resolve) => setTimeout(resolve, 2000));

    if (map.has(difference)) {
      finalOptimalSolutionResult.textContent = `Final indices: [${map.get(
        difference
      )}, ${i}]`;
      currentValueOutput.innerHTML = `
      <p>Difference(${difference}) = target(${target}) - current number(${testCaseArray[i]})</p>
      <p>Is the difference(${difference}) in our map? YES, we found that pair of numbers that add up to the target.</p>
    `;
      optimalSolutionBtn.removeAttribute("disabled");
      return;
    } else {
      currentValueOutput.innerHTML = `
        <p>Difference(${difference}) = target(${target}) - current number(${testCaseArray[i]})</p>
        <p>Is the difference(${difference}) in our map? No.</p>
        <p>Add the current number ${testCaseArray[i]} to our map.</p>
      `;
      tableBodyOutput.innerHTML += `
        <tr>
          <td>${testCaseArray[i]}</td>
          <td>${i}</td>
        </tr>
      `;
      map.set(testCaseArray[i], i);
    }
  }
};

bruteForceSolutionBtn.addEventListener("click", bruteForceApproach);
optimalSolutionBtn.addEventListener("click", optimalApproach);

Here is a link again to the final live result on CodePen.

Conclusion

I hope you enjoyed that project and learned a little bit more about how the Two Sum problem works.

I encourage you to play around with the project and maybe add some new features on your own like testing out different numbers or asking for user inputs for the numbers array and targets. 👍🏾

In this article, I'll go over some of the most commonly asked questions that come up in interviews about AWS Lambda.

Note that this is not an exhaustive list – but you can use this guide as a reference to refresh your knowledge and get pointers for further study.

Most of the questions will be based on your experience or on certain scenarios. The questions are in the headings and you'll find the notes for the rationale behind asking the questions just below them.

Explain your last project involving AWS Lambda

The interviewer wants to know about your real-life experience using AWS Lambda. Don't bluff here, as the interviewer may ask further questions based on the answers to this question.

You might have built a serverless API, systems involving microservices, image/video conversion, log analysis, and many more. Just explain your project in detail and tell about the business benefits of that project so that the interviewer knows you're seeing the big picture.

What services have you integrated with AWS Lambda?

This is an extension of the previous question. This is not a laundry list of all event sources that can connect to AWS Lambda. Only tell about the services that you've really used.

You may have used S3, SNS, SQS, Kinesis, DynamoDB, SES, or others. Not all projects will be completely serverless.

If you've used any non-serverless component along with AWS Lambda, mention those too. For example, you might've used AWS Lambda with RDS. If you've used such a configuration, you can explain about that along with your reasoning.

Explain the concept of cold and warm starts in AWS Lambda

There are 2 reasons for asking this question. They want to know the runtimes that you've used, and they want to know if you know the other runtimes that could cause a cold start.

Lambda services receive a request to run a lambda function. The service prepares the execution environment by downloading the handler function code and by allocating memory along with other configuration.

Even though you're not billed for this execution environment preparation time, you'll have to face the delay in invoking your lambda function. This delay is called a "cold start".

The cold start timing is less significant for TypeScript and Python runtime environments, whereas it's a bit higher for Java or C# runtime environments.

To improve performance, the lambda service will keep the execution environment for some time. When you receive the request for the same lambda function again during this period, your handler can start executing immediately. This type of invocation is called a "warm start".

Image source

What's the difference between synchronous and asynchronous invocation in AWS Lambda?

Even though this seems to be straightforward question, this has many implications for your design and error handling.

In synchronous invocation, the caller will wait for the execution to complete. But in asynchronous invocation, the caller will put the event in an internal queue which will later be processed in the lambda function.

Image source

An important point to note here is that you can't dictate the type of invocation and it depends on the service that you use with AWS Lambda.

For example, if you're building serverless APIs using API Gateway, it'll be a synchronous invocation. But if you're using S3, it'll be an asynchronous invocation.

How do you implement error handling and retry logic in Lambda?

Any component in event driven system that may fail will fail. So interviewer wants to know how you've handled the error and how you retried in your previous projects. Below are some examples. Always explain with concrete examples.

This depends on the service that you're using with AWS Lambda. Let's discuss this with some examples.

If you're building a serverless API, it is better to return that error to the calling client (could be a front end app in this case). Then you let your front end logic decide what to display to the user based on the type of the error.

If you're using Lambda with SQS, it is better to use a Dead Letter Queue so that you know what messages have failed to process. For this same reason, many of the systems that use SNS may use SQS, too.

In the below code, we're using a dead letter queue. If any message fails to process after a certain number of times (as specified by maxReceiveCount), it's sent to the dead letter queue. This behaviour is specific to lambda when used along with queues.

const queue = new sqs.Queue(this, 'AwsLambdaSqsQueue', {
      visibilityTimeout: cdk.Duration.seconds(300),
      receiveMessageWaitTime: cdk.Duration.seconds(20),
      deadLetterQueue: {
        queue: new sqs.Queue(this, 'AwsLambdaDlq'),
        maxReceiveCount: 5,
      },
    });

When lambda is invoked with any other services, you can configure the number of retries with a maximum value of 2. This means that you can have maximum of 2 retries apart from the initial invocation. For example, you want to trigger based on the S3 object upload and your lambda will try at most 3 times.

Explain your workflows for development and deployment of AWS Lambda functions

Talk about the frameworks that you've used. The interviewer may expect you to talk about testing lambda functions as well.

You can explain which framework(s) you've used to develop and deploy lambda functions. You can also talk about any IaC (Infrastructure as Code) tool that you've used.

Below is non-exhaustive list of the most commonly used frameworks:

• Serverless
• AWS CDK
• AWS SAM
• CloudFormation
• Pulumi

If you've used Terraform, you can talk about that as well.

Can Lambda be invoked when you get an email to a particular support email address? If yes, design that system. If not, explain why.

Yes, you can. You can create receipt rule set and add a rule which triggers the lambda function.

You should store the email to S3 and trigger the lambda after that so that you can have the copy of the email for any further reference.

You can refer to this article on how to receive emails from a contact form.

Image source

Can one lambda function call another lambda function?

The interviewer wants to know whether you know this anti-pattern.

You can do this, but it is not recommended. If you want to design a workflow which involves multiple lambda functions, you can use step functions.

Image source

You can read more about step functions here.

Another standard approach is to emit an event and trigger a lambda based on the event. You can use SQS, SNS, or EventBridge as intermediary for these events.

Can you execute queries on an RDS instance (in a private subnet) using Lambda?

Yes, you can execute the query in RDS using AWS Lambda. For that you can have your lambda inside the same VPC.

There may be some performance implications if you use AWS Lambda directly with RDS because of the database connection creation time. To avoid those, you can use an RDS Proxy.

Image source

Here's a detailed step by step guide that shows you how to do that.

AWS Lambda provides many benefits. What are the cons of using AWS Lambda?

The interviewer wants to know about your thought process. Don't say AWS Lambda solves all the problems :-)

Yeah, Lambda provides many benefits such as cost and scalability without any need to maintain the servers. But it's not the answer to everything – like any service, it has its own problems (and you should be able to discuss them):

• Debugging: If you're using serverless architectures using Lambda, you might have to rely on logging to find the root cause of the issue. This is because your application will be distributed across many services/ lambda functions.
• Testing: You can mock AWS services in your local testing. But it is better to have a separate environment in AWS to test your lambdas. This makes testing a bit complex.
• Background jobs: Lambda has a timeout limit of 15 minutes. If you want any particular task to take more than 15 minutes, you might have to move to Fargate or some other solution.
• Cost: If you're running a high traffic application which processes the requests 24/7, using lambda can be expensive. It is better to use Fargate, EC2 or other services, if you have constant high traffic.

How do you manage concurrency and scaling in AWS Lambda?

Bonus points if you talk about the issues that you've faced in these situations.

Concurrency is the ability to execute multiple lambda functions at the same time. Scaling is the process of increasing the number of copies of your lambda function to handle the incoming requests.

You can control concurrency by setting the value of reserved concurrency so that only the mentioned number of lambda functions will be invoked.

Below is the high level diagram of how lambda scales in accordance with number of messages in the queue.

Image source

Note: There is some weird behavior if you try to throttle AWS Lambda when used with SQS standard queue. You can use a FIFO queue to solve that issue.

How do you pass environment variables to AWS Lambda?

The interviewer might want to know how you pass sensitive information, for example.

There are different ways to pass environment variables to AWS Lambda, and it depends on the type of value is getting passed.

Non-sensitive data: If you want to pass any non-sensitive information, you can pass the values directly to your lambda function environment variables. But these values would be visible in the AWS console in the Lambda service.

In the below code example, we're passing the name of the DynamoDB table directly as environment variable, as it is not sensitive data:

   const readDDBLambdaFn = new NodejsFunction(this, 'readDDBLambdaFn', {
      entry: path.join(__dirname, '../src/lambdas', 'read-ddb.ts'),
      ...nodeJsFunctionProps,
      functionName: 'readDDBLambdaFn',
      environment: {
        tableName: table.tableName,
      },
    });

Sensitive data: If you want to pass sensitive data such as passwords and API keys, you can use either a Secret Manager or Parameter store. But, you need to make sure you provide necessary roles to Lambda for accessing and decrypting secrets from the respective services.

In the below code snippet, we're NOT passing the actual secret. Instead, we're just passing the ARN (Amazon Resource Name) of the secret.

const rdsLambdaFn = new NodejsFunction(this, 'rdsLambdaFn', {
      entry: path.join(__dirname, '../src/lambdas', 'rds-lambda.ts'),
      ...nodeJsFunctionProps,
      functionName: 'rdsLambdaFn',
      environment: {
        DB_ENDPOINT_ADDRESS: dbInstance.dbInstanceEndpointAddress,
        DB_NAME: databaseName,
        DB_SECRET_ARN: dbInstance.secret?.secretFullArn || '',
      },
      vpc,
      vpcSubnets: vpc.selectSubnets({
        subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS,
      }),
    });

Then, in lambda you can get the actual secret dynamically within the lambda function as shown below:

export const handler = async (event: any, context: any): Promise<any> => {
    const host = process.env.DB_ENDPOINT_ADDRESS || '';
    const database = process.env.DB_NAME || '';
    const dbSecretArn = process.env.DB_SECRET_ARN || '';
    const secretManager = new AWS.SecretsManager({
      region: 'us-east-1',
    });
    const secretParams: AWS.SecretsManager.GetSecretValueRequest = {
      SecretId: dbSecretArn,
    };
    const dbSecret = await secretManager.getSecretValue(secretParams).promise();
    const secretString = dbSecret.SecretString || '';

    const { password } = JSON.parse(secretString);

}

I've written a detailed tutorial here on the same topic.

Say you have a Windows-dependent executable sometool.exe. You can upload it into an S3 bucket. Can you execute this binary with some parameters using AWS Lambda?

This is more of a question to make sure you understand the AWS Lambda execution environment – specifically the operating system it uses.

No, you would not be able to do that as AWS Lambda uses Linux as its operating system. Linux would not be able to execute a Windows-dependent binary.

How do you re-use code across AWS Lambda functions?

There are 2 ways to re-use code across many AWS Lambda functions:

• Use Lambda Layers: You can store your code or logic in lambda layers, which you can re-use across different lambda functions.

Below is some high level code for creating and consuming lambda layers using aws cdk:

    const logicLayer = new lambda.LayerVersion(this, 'logic-layer', {
      compatibleRuntimes: [
        lambda.Runtime.NODEJS_14_X,
        lambda.Runtime.NODEJS_16_X,
      ],
      layerVersionName: 'business-logic-layer',
      code: lambda.Code.fromAsset('src/layers/business-logic'),
      description: 'Business logic layer',
    });


    const lambdaWithLayer = new NodejsFunction(this, 'lambdaWithLayer', {
      entry: path.join(__dirname, '../src/lambdas', 'lambda.ts'),
      ...nodeJsFnProps,
      functionName: 'lambdaWithLayer',
      handler: 'handler',
      layers: [logicLayer, utilsLayer],
    });

• Use monorepo: You can use mono repo and dynamically build packages at deploy time.

What happens to your lambda functions if you delete a Lambda Layer?

In this question, the interviewer wants to see how well you understand lambda layers.

Existing lambda functions which use that deleted layer will continue to work – as lambda layers are merged with lambda functions at deployment time.

But you can't create a new lambda function using that deleted lambda layer.

You can learn more about Lambda layers here and I've written a guide on the same topic here.

Can you increase the size of a deployment package if you use Lambda Layers?

No, you can't increase the size of the deployment package if you use Lambda Layers. The maximum deployment size of 50 MB zipped includes both the size of the lambda function and its associated lambda layers.

If you have a large codebase and want to increase the deployment, you can run containers in AWS Lambda.

Can I take my existing dockerized web application and run it using Lambda?

Nope. You can't take any Express, Springboot, or .NET Core application (or any other application for that matter) as they are and put them inside lambda.

But that being said, there are a few libraries which allow you to put applications that use these web frameworks into AWS Lambda. Internally, those libraries convert those web applications into AWS lambda-compatible APIs. You can see one such example here.

By using these frameworks, the size of your lambda functions will be bigger and will result in longer start up times.

Remember that even when using containers with Lambda, the existing runtime API of Lambda remains the same. Lambda will still:

• be a single function
• be invoked by an event or manually
• have a timeout of 15 minutes.

As you can see in the below code, there will be no change to the lambda API. The advantage of using Docker is that you would be able to use large packages without worrying about size.

import { Context, APIGatewayProxyResult, APIGatewayEvent } from 'aws-lambda';

export const handler = async (
  event: APIGatewayEvent,
  context: Context
): Promise<APIGatewayProxyResult> => {
  console.log(`Event: ${JSON.stringify(event, null, 2)}`);
  console.log(`Context: ${JSON.stringify(context, null, 2)}`);
  return {
    statusCode: 200,
    body: JSON.stringify({
      message: 'Running this handler from docker',
    }),
  };
};

And, this is how you use it:

 const repo = ecr.Repository.fromRepositoryName(
      this,
      'dockerLambda',
      'docker-lambda'
    );

    const dockerLambda = new lambda.DockerImageFunction(
      this,
      'DockerLambdaFunction',
      {
        code: lambda.DockerImageCode.fromEcr(repo),
      }
    );

I wrote a step-by-step tutorial on running Docker containers for your application in aws lambda here.

How do you share large files between lambda functions?

You can use the Elastic File System (EFS) to share large files between different functions.

You can create an access point in the created EFS with the appropriate permissions and use that access point in your mount path in your lambda.

Any files written on that mount path will be accessible to all other lambda functions provided they have the mount path with appropriate permissions.

Below is the high level logical diagram on how to use AWS Lambda with Elastic File System (EFS):

Image source

You can read about this here (bit old). I wrote a more recent practical step-by-step guide here on EFS with Lambda functions.

Conclusion

I hope this article helped you to prepare for interviews involving AWS Lambda.

Thanks for reading to this point. I write about aws and serverless technologies at https://www.cloudtechsimplified.com. If you're interested, you can subscribe to my blog.

A front-end technical interview is an opportunity for a potential employer to assess your skills and knowledge in web development.

The interviewer will ask you questions about your experience and skills in HTML, CSS, and JavaScript. They'll also likely ask you some framework specific questions about React, Angular, Vue, or whatever framework they use.

They may also give you a coding challenge to test your abilities in a particular domain.

Today, we are going to look at the most common problems asked in a front-end technical interview round, focusing on React and JavaScript.

What Interviewers Are Looking For

When interviewing for a front-end web development position, be prepared to discuss your skills and experience with various programming languages, tools, and frameworks.

Interviewers will also want to see that you have a strong understanding of the latest trends and technologies in web development.

Be prepared to talk about your past projects and how you approached solving various challenges.

Be sure to showcase your problem-solving skills by discussing how you tackled various challenges during your development process.

Finally, don’t forget to highlight your strengths.

Most Commonly Asked Questions in a Front-End Technical Interview

Front-end technical interview problems are pretty straightforward and common. If you have been actively coding for at least 6 months, you will be familiar with most of the concepts that are asked about.

Once you practice the right questions with a time based approach, you should be able to clear the interviews.

Let's look at the most common questions asked.

Map, ForEach, Filter and Reduce

The most commonly asked questions (generally at the start of the interviews) are about array methods. The interviewer wants to asses how comfortable you are with array manipulation.

The .map() method

The .map() methods iterates over an array, computes whatever logic you write inside the map body, and returns a NEW array.

let arr = [
  { id: 1, age: 12, name: 'Manu' },
  { id: 2, age: 24, name: 'Quincy' },
  { id: 3, age: 22, name: 'Abbey' },
]

let names = arr.map((el) => el.name)
console.log(names)
// Output: [ 'Manu', 'Quincy', 'Abbey' ]

The .forEach() method

ForEach is similar to .map() but it DOES NOT return an array.

let arr = [
  { id: 1, age: 12, name: 'Manu' },
  { id: 2, age: 24, name: 'Quincy' },
  { id: 3, age: 22, name: 'Abbey' },
]

arr.forEach((el) => el.age+= 10);
console.log(arr);

// Output: 22 32 44

The .filter() method

The filter method, as the name suggests, helps in filtering out the values inside of an array based on a Boolean condition.

If the boolean condition is true, the result will be returned and added in the final array. If not, it will be skipped. Filter also returns an array, just like the .map() method.

let arr = [
  { id: 1, age: 12, name: 'Manu' },
  { id: 2, age: 24, name: 'Quincy' },
  { id: 3, age: 22, name: 'Abbey' },
]

let tooYoung = arr.filter((el) => el.age <= 14);
console.log(tooYoung);

// Output: [ { id: 1, age: 12, name: 'Manu' } ]

The .reduce() method

In simple terms, the .reduce() method takes into account a previous value , current value and an accumulator.

The return type of the .reduce() method is always a single value. It is useful when you want to process all the values of the array and want to derive some accumulated result.

// Calculates the total age of all the three persons.
let arr = [
  { id: 1, age: 12, name: 'Manu' },
  { id: 2, age: 24, name: 'Quincy' },
  { id: 3, age: 22, name: 'Abbey' },
]

let totalAge = arr.reduce((acc, currentObj) => acc + currentObj.age, 0)
console.log(totalAge)

// Output: 57

Here, the currentObj is the object that is being iterated over. Also, the acc value stores the result and is outputted finally into the totalAge array.

How to Implement Polyfills

Another important interview question is How to implement polyfills of the map and filter array methods.

A polyfill is a code snippet (in terms of JavaScript web architecture) used for modern world functionalities on older browsers that do not implement it natively.

Simply put, a polyfill is a custom implementation of native JavaScript functions. Sort of a create your own .map() or .filter() method.

How to use the .map() polyfill

let data = [1, 2, 3, 4, 5];

Array.prototype.myMap = function (cb) {
  let arr = [];
  for (let i = 0; i < this.length; i++) {
    arr.push(cb(this[i], i, this));
  }
  return arr;
};
const mapLog = data.myMap((el) => el * 2);
console.log(mapLog);

the myMap method takes in a callback that gets executed inside the myMap body. We basically have a native for loop inside the myMap body, which iterates over the this.length. This is nothing but the length of the array through which the myMap function is called.

Since the syntax of map() is arr.map(currentElement, index, array), and the myMap() function takes into account exactly that.

Also since map() returns a new array, we create an empty array and push the results into it. In the end we return it.

How to use the .filter() polyfill

let data = [1, 2, 3, 4, 5];

Array.prototype.myFilter = function (cb) {
  let arr = [];
  for (let i = 0; i < this.length; i++) {
    if (cb(this[i], i, this)) {
      arr.push(this[i]);
    }
  }
  return arr;
};
const filterLog = data.myFilter((el) => el < 4);
console.log(filterLog);

.filter() is very similar to .map() in terms of implementation. But since filter filters out the results based on a boolean value, we have an additional if() condition to filter out results and conditionally push inside the array.

What is Debouncing?

This is a famous interview question with a lot of practical real world usage and implementations.

Debouncing is a method of preventing a function from being invoked too often, and instead waiting a certain amount of time until it was last called before invoking it.

Think of Amazon in this case. Whenever you type anything in the search bar, when you stop for AT LEAST 0.5 seconds, then the results are fetched. This is exactly what debouncing is.

In order to implement debouncing, let's take an example: Generating a username for a user based on the user input.

import "./styles.css";
let inputEle = document.getElementById("inputElement");
let username = document.getElementById("username");

let generateUsername = (e) => {
  username.innerHTML = e.target.value.split(" ").join("-");
};
let debounce = function (cb, delay) {
  let timer;
  return function () {
    let context = this;
    clearTimeout(timer);
    timer = setTimeout(() => {
      cb.apply(context, arguments);
    }, delay);
  };
};

inputEle.addEventListener("keyup", debounce(generateUsername, 300));

Here, we are trying to create a custom username based on the user input. Now if the user starts typing, we don't want to immediately create it, but actually wait for 300 milliseconds before creating the username. We are trying to mimic an API call here, so assume the user types anything and it has to make an API call to the backend and fetch a response.

The debounce() function takes in two values, cb and delay . cb is the callback function that gets executed when the timer runs out.

We use setTimeout() to create a timeout timer, which means the function inside the setTimeout body will be executed after a certain amount of time.

The apply method is used to call the callback function with the object that it was initially called with, applying the arguments and context to it.

What are Closures?

According to the mdn docs for closures,

A closure is the combination of a function bundled together (enclosed) with references to its surrounding state (the lexical environment). In other words, a closure gives you access to an outer function's scope from an inner function. In JavaScript, closures are created every time a function is created, at function creation time.

To simplify this, let's take an example and understand how closures work.

function start() {
  var name = "Manu"; // name is a local variable created by start()
  function displayName() {
    // displayName() is the inner function, a `closure`
    alert(name); // use variable declared in the parent function
  }
  displayName();
}
start(); // "Manu" alert box is displayed

Here, a closure is formed between the start() and the displayName() function. The displayName() function has access to the name variable present in the start() function.

In simple terms, the inner function will know its surroundings (the lexical environment).

I have written a whole blog on how to clear JavaScript interviews. Have a look at that if you want to know more about in depth JavaScript interview process.

React Hooks

The most popular questions asked in a front-end coding interview when it comes to React hooks are:

1. useState()
2. useReducer()
3. useEffect()
4. useRef()
5. Custom Hooks and their implementation.

How the useState() hook works

To manage a state inside of your component, the useState() hook is your go-to hook.

Let's take an example and understand:

import { useState } from "react";
import "./styles.css";

export default function App() {
  const [title, setTitle] = useState("freeCodeCamp");
  const handleChange = () => {
    setTitle("FCC");
  };
  return (
    <div className="App">
      <h1>{title} useState</h1>
      <button onClick={handleChange}>Change Title</button>
    </div>
  );
}

The useState() methods gives us two values, the state variable and a function to change that state variable.

In the above code snippet, we are creating a title state to store the title of the page. The initial state is passed as freeCodeCamp.

On button click, we can use the setTitle() method to change the state variable to FCC.

useState() method is your go-to resource for state management in a functional component.

How the useReducer() hook works

In simple terms, useReducer() is the cool way of managing state in your application. It is more structured and helps you maintain complex state in your application.

Let's take an example to understand the useReducer hook:

import "./styles.css";
import { useReducer } from "react";

const initialState = { title: "freeCodeCamp", count: 0 };

function reducer(state, action) {
  switch (action.type) {
    case "change-title":
      return { ...state, title: "FCC" };
    case "increment-counter":
      return { ...state, count: state.count + 1 };
    default:
      throw new Error();
  }
}

export default function App() {
  const [state, dispatch] = useReducer(reducer, initialState);
  return (
    <>
      <div className="App">
        <h1>{state.title} CodeSandbox</h1>
        <button onClick={() => dispatch({ type: "change-title" })}>
          Change Title
        </button>
        <button onClick={() => dispatch({ type: "increment-counter" })}>
          Increment Counter
        </button>
      </div>
      <p style={{ textAlign: "center" }}>{state.count}</p>.
    </>
  );
}

The useReducer() hook takes two parameters, the reducer function and an initialState value.

The reducer function is a switch-case based implementation that returns the final state value that useReduer() internally uses to supply back to the component.

The values returned from the useReducer() function are state and dispatch. The state is the actual state value that can be used inside of the component. In our case, the state has two values: title and count. This title and count can be manipulated using the dispatch() method which is returned by the useReducer() method.

In the above case, to change the title, we have written a case of change-title inside the reducer function. This can be triggered with the help of the dispatch({ type: "change-title" }) function. This will trigger the change title function and it will change the state of the title attribute.

Similarly, the same happens for the count part that is there in the application.

Like I said earlier, it is a cool way of implementing state inside your application. 😉

How the useEffect() hook works

Think of it this way: if you want to have a side effect to a state variable that changes, you can use the useEffect() hook to trigger it.

For example, let's say if the input value of your input box changes, and you want to call an API after it has changed. You can write the logic of the API handle in the useEffect() block.

import React, {useState, useEffect} from 'react';

export const App = () => {
    const [value, setValue] = useState('');
    useEffect(() => {
      console.log('value changed: ', value);
    }, [value])
    return <div>
            <input type="text" name="username" value={value} onChange={(e) => setValue(e.target.value)} />
        </div>
}

Here, we have an input box that has a state value of value attached to it. This value will change when the user tries to input anything.

Once the value has been updated and has been rendered, the useEffect() block will kick in and the console statement will be triggered, outputting the latest state value which is there.

Here, one good use case of the useEffect() can be to implement API calls. Let's assume you want to call an API with the input field value. The useEffect function block will be the best way to do it.

Another part of this is the dependency array which is the second argument to the useEffect() hook. In our case, we mentioned [value] as the second argument.

This basically means that EVERY TIME THE value CHANGES, the function inside the useEffect gets triggered. If you don't pass anything in the dependency array, the function block gets triggered once.

How the useRef() hook works

The useRef hook gives us the ability to mutate the DOM (but this is not the only implication of useRef).

According to the docs:

useRef returns a mutable ref object whose .current property is initialized to the passed argument (initialValue). The returned object will persist for the full lifetime of the component.

In simple terms, we are going to useRef if we want to persist the value of something for the entire component lifecycle. The basic implementation of useRef comes with DOM elements. Let's take an example:

function TextInputWithFocusButton() {
  const inputEl = useRef(null);
  const onButtonClick = () => {
    // `current` points to the mounted text input element
    inputEl.current.focus();
  };
  return (
    <>
      <input ref={inputEl} type="text" />
      <button onClick={onButtonClick}>Focus the input</button>
    </>
  );
}

Here, we are assigning a ref property to the input block. This will be associated with the inputEl reference that we created.

Now this input element can be manipulated however we want. We can modify the style attribute and make it beautiful, we can take the value property to see what is being help by the input element as the value, and so on.

In the above example, when we click the button, the input is focused and we can immediately start typing. We can do this with the help of inputEl.current.focus() – essentially the focus() method present on the current object.

What are custom hooks?

One of the most commonly asked questions that I've seen in front-end interview rounds is to create a custom hook for keyboard events.

We saw many different hooks, but the interviewer might ask you to create a hook of your own. This might be challenging for some but with some practice, it becomes much easier.

Let's understand what a Hook is:

The basic usage of a custom hook is to extract a function's logic into its own component.

Imaging what will happen if you have to listen for an enter press inside of each of your components. Instead of writing the logic for listening again and again, we can extract the logic into a component of its own and use it wherever we want (just like we use useState() or useEffect()).

There are a few conditions for a function to be called a Hook:

1. It should always start with the use keyword.
2. We can decide what it takes as arguments, and what, if anything, it should return.

// Custom Hook: useAvailable
function useAvailabe(resource) {
  const [isAvailable, setIsAvailable] = useState(null);

  // ...

  return isAvailable;
}

// Usage:
  const isAvailable = useAvailable(cpu);

Here, no matter how many times we call useState and useEffects inside the custom hook, they will be completely independent from the function where we use the custom hook.

Let's take an example of creating a custom hook for storing local storage values.

How to create a custom hook – useLocalStorage example

The useLocalStorage custom hook is a way to persist data into the local storage. Get and set values inside the local storage using key and value pairs so that whenever the user comes back to your web app, they see the same result they used earlier.

The below implementation is of a simple select tag value that, once changed, persists the data into local storage.

useLocalStorage.js

// Use Local Storage Custom Hook
import { useState } from 'react';

function useLocalStorage(key, initialValue) {
  const [storedValue, setStoredValue] = useState(() => {
    if (typeof window === 'undefined') {
      return initialValue;
    }
    try {
      const item = window.localStorage.getItem(key);
      return item ? JSON.parse(item) : initialValue;
    } catch (error) {
      console.log(error);
      return initialValue;
    }
  });
  const setValue = (value) => {
    try {
      const valueToStore =
        value instanceof Function ? value(storedValue) : value;
      setStoredValue(valueToStore);
      if (typeof window !== 'undefined') {
        window.localStorage.setItem(key, JSON.stringify(valueToStore));
      }
    } catch (error) {
      console.log(error);
    }
  };
  return [storedValue, setValue] as const;
}

export default useLocalStorage;

App.js

import * as React from 'react';
import './style.css';
import useLocalStorage from './useLocalStorate';

export default function App() {
  const [storedValue, setStoredValue] = useLocalStorage(
    'select-value',
    'light'
  );

  return (
    <div>
      <select
        className="select"
        value={storedValue}
        onChange={(e) => setStoredValue(e.target.value)}
      >
        <option value="dark">Dark</option>
        <option value="light">Light</option>
      </select>
      <p className="desc">
        Value from local storage: <span>{storedValue}</span>
      </p>
    </div>
  );
}

Here, the useLocalStorage hook takes in two parameters, the local storage key name to store, and a default value that has to be there.

The hook returns two values: the local storage value of the key that you're using and a way to change that key value by giving us a setter method. In this case, the setStoredValue method.

In the useLocalStorage.js file, we are trying to first GET the local storage value with that key using localStorage.getItem() method. If that exists, we are setting the value. If found, we JSON.parse() the value and return it. Otherwise, initialValue which was provided is set as the default value.

The setLocalStorage() function takes into account whether the passed value is a function or a simple variable value. Also it takes care of setting the value of local storage using localStorage.setItem() function.

How to Stand Out as a Developer by Creating Side Projects

The thing that has always worked for me and helped me stand out is my side projects that I've built.

In my opinion, you don't have to build 10 basic cookie cutter side projects. Instead, try building one or two really good projects where you get to implement all the concepts of React/HTML/CSS/JavaScript and everything that you've been learning.

Assume the interviewer has 14 interviews in a week and has to review the résumés of 14 candidates. They'll be more likely interested in your profile because you have created a link shortener website that charges $1 after every 1000 link visits instead of an Amazon / Netflix clone.

Again, there's nothing wrong with creating clones and practicing your skills. But it's always good to have at least 1 unique project that helps you stand out from the crowd.

Also, creating side projects will help you upskill as a developer. It is not likely possible to know everything beforehand when creating a project from scratch. Along the way, you'll have to learn many different skills and get good at that.

Practice, Practice, Practice.

There's a famous saying that goes like this:

and this is true to a great extent.

I myself have failed 100s of times before landing my first job. It's the constant feedback and iterations that you have to make in order to get what you want.

In our case, getting a front-end job becomes easy when:

• You have in depth knowledge of your skills – React in this case (along with HTML, CSS, and JS).
• You have a set of projects to showcase, making you stand out.
• You're willing to put in the time and the effort to learn more and challenge yourself.
• You read the freeCodeCamp blog regularly and practice questions there (😉)

Conclusion

There are a lot of questions to practice for a machine-coding round. The interviewer can ask different sets of questions to test your skills.

You can use Algochurn to practice the most popular JavaScript interview questions, React Interview Questions, and algorithmic questions asked in a front-end technical interview round along with their solutions and approaches.

If you have any questions, please reach out to me via Twitter(@mannupaaji) and/or my website(manuarora.in)

Good luck and Happy Coding! 👑🫡

David Goggins is an ultramarathon runner, a public speaker, a retired navy SEAL, and the author of the book 'Can't Hurt Me: Master Your Mind and Defy the Odds'. He's one of my role models because of his physical strength and mental resilience.

You might say: "Wait a second! We get it. This person is obviously the epitome of success. But he has non-technical skills. So why is he relevant to JavaScript coding interviews?"

Well, if you're ready, let's explore this together.

Rocky Balboa As a Mentor

In response to a question, David says, 'The Rocky Movie changed my life." In that pep talk, he refers to this scene (min 1.30-1.42) where the fictional character, Rocky - despite being beaten up badly by his opponent in the final boxing round - refuses to give up no matter what.

David describes that particular moment as the time when Rocky - initially depicted as an underdog by the screenwriter - overcomes all the odds and strikes awe in his rival.

Illustration Source

Let's admit it. Being a good programmer is not that easy. And especially if you are at the beginning of your career, technical job interviews can be seriously daunting. In short, it might be nice to reach David's (and Rocky's) mindset.

With that kind of drive and confidence, you're much less likely to consider giving up regardless of the types of challenges you face in your wonderful yet difficult journey of getting a developer job.

Why Coding Interviews Are Difficult

During coding interviews, you are expected to fix coding problems with some theoretical knowledge. But the caveat is you must do that in real time, which sometimes scares new developers off.

There are several types of coding interviews. But the most challenging one is probably a whiteboard interview. In these types of interviews, you have to code in front of a future employer / a senior software developer.

[Illustration by HackerRank](https://www.hackerrank.com/blog/virtual-whiteboarding-for-system-design-interviews/"><nr-sentence class="nr-s20" id="nr-s20" page="0)

These interviews can be extra stressful because you are typically not allowed to have a computer to google any unknown concepts or to get some code snippets from the internet. You are only given a marker to solve the question on a whiteboard as the name suggests.

Do Interviews Reflect What You'll Do in Your Job?

Not necessarily. So why are they holding these scary coding interviews? Well, the reason is to test your problem solving skills in general. At times, finding the correct answer may not even be that important.

What matters is how you reach that conclusion / solution and which algorithms you prefer to use along the way. In other words, your ability to function well under stress is being tested by tech companies.

_[Image Source](https://www.reddit.com/r/ProgrammerHumor/comments/l6wnvt/interview_vsjob/"><nr-sentence class="nr-s30" id="nr-s30" page="0)

Let's face it. You'll come across lots of stressful situations in your future job, and how you deal with certain issues is especially crucial. Therefore, your future employer naturally wants to witness firsthand whether you are the right fit for the job.

What is the Purpose of This Tutorial?

In this post, I'll walk you through some popular JavaScript interview concepts through examples. I'll also do my best to show you what recruiters / interviewers might actually be looking for in a candidate while they code in front of them.

To simply put, we'll examine some models and try to solve the related puzzles together.

By the end of this tutorial, you'll hopefully have an idea about a number of important array methods. But most importantly, you'll unlock how to approach some coding challenges in the best way possible.

What Exactly is the Memory Palace Method?

Before we start, just be aware that in the sample data down below, I've used some late celebrities' names intentionally so that all those details can be catchy in the long run.

An ancient technique called the Memory Palace clearly says that the weirder the details, the easier it is to remember them – and a made-up story / creating context is even more effective.

If you try to visualise the related situation vividly and associate the given programming concepts with some bizarre details in your mind, you might feel less stressed and confused when you see a similar problem next time. This is because it might be easier for you to create specific links and as such remember things easily. This is how our brains work.

Well, even the fictional figure 'Sherlock Holmes', the smartest guy on the planet, benefits from this method when solving complicated crimes – so why shouldn't we?

[Illustration by Savanahcat](https://www.deviantart.com/savanahcat/art/Mind-Palace-387601041"><nr-sentence class="nr-s43" id="nr-s43" page="0)

How to Approach Coding Problems

In our imaginary interview, you'll see that four extraordinary musicians from the past are listed as passengers on a flight. We have their food choices and the number of connecting flights they need to take after their incredible performances on stage in different parts of the world.

Let's say just for the sake of argument our phenomenal figures (Freddie Mercury, Amy Winehouse, Kurt Cobain, and Michael Jackson) are about to fly from different destinations to Los Angeles just to be able to dine out together at a swanky restaurant, as they enjoy each other's company so much.

After all, this is our own private memory palace, so we can absolutely do whatever we want to do in our minds. Remember unusual details will stick better. That's why I'm trying to add more to spice things up.

This method explicitly suggests describing every single detail with some vivid adjectives so that you can associate them with the things you plan to learn in the long run.

Scientists say short term memory and long term memory function very differently. To put it simply, we need a way to put all those core concepts (not necessarily the syntax) about programming in our long term memory. That's why it can be nice to benefit from the memory palace method in our journey.

[Image Source](https://www.nme.com/news/music/producer-goes-viral-for-mixing-nirvana-and-michael-jackson-songs-with-drill-beats-2747204"><nr-sentence class="nr-s56" id="nr-s56" page="0)

Plus, I feel like you get to picture this unusual scenario with a smile on your face. Well, wouldn't it be great if these awesome souls could have seen that they are now helping us / the programming community as the guests of a freeCodeCamp article?

Sample Interview Questions

Let's get back to the real life now though. Remember you're still in the interview and as you see below, three questions in a row are waiting for you.

// Main Question: Get the passengers' names using the data provided 
// Bonus Part (a)- Return vegetarians/vegans
// Bonus Part (b)- Sort passengers by the number of connected flights in descending order

The Data

To solve the puzzles, you're expected to use the data inside the following array of objects in practical ways.

You'll certainly need to come up with the right algorithms and try to find the most effective solution that can satisfy the interviewer.

const passengers = [
  {
    id: 1,
    passengerName: "Freddie Mercury",
    isVegetarianOrVegan: false,
    connectedFlights: 2,
  },
  {
    id: 2,
    passengerName: "Amy Winehouse",
    isVegetarianOrVegan: true,
    connectedFlights: 4,
  },
    {
    id: 3,
    passengerName: "Kurt Cobain",
    isVegetarianOrVegan: true,
    connectedFlights: 3,
  },
     {
    id: 3,
    passengerName: "Michael Jackson",
    isVegetarianOrVegan: true,
    connectedFlights: 1,
  },
];

The above questions are in fact not that hard. But, how we'll handle them is a great opportunity to compare alternative solutions for a single problem. At the end of the day, quality is what counts for recruiters / interviewers.

Interview Question 1: How to Get Passengers' Names

Let's get the passengers' names as requested. The first solution is through a 'for loop' method. So we first need to use an empty array to push the passengers' names right inside it at the end of the loop.

Below, [i] represents the current passenger and we simply loop through the 'passengers' array to access the names of the passengers. Then, we need to lock them up in our empty array / passengerNames.

const passengerNames = [];
for (let i = 0; i < passengers.length; i++) {
    passengerNames.push(passengers[i].passengerName)
}
console.log("passengers", passengerNames);

RESULT - using 'for loop'

Alright, we solved the puzzle, but is it enough? Or might the interviewers expect you to come up with a better solution?

Alternative Solution #1:

We can reach the desired result by using the 'forEach' function as well. This solution is even a bit better than the previous one because there is no index expression in this one.

const passengerNames = [];
passengers.forEach((passenger) => {
    passengerNames.push(passenger.passengerName);
})

RESULT - using 'forEach'

To benefit from 'forEach', we need a callback function. With this arrangement, we are able to reach every passenger in the list. However, just like in the previous solution, we first need an empty array to push the items / passengers' names.

Even though the result is the same, this piece of code is shorter. Writing neater codes is what is – in fact – expected from you.

In other words, not only the solution matters, but also how you reach it is being evaluated by the recruiters. For this reason, it is a good idea to plan your action rather than writing the first idea in your mind on the whiteboard.

Alternative Solution 2:

Here comes the best solution. We can also utilise the 'map' function to tackle the same problem. Let's see how.

const passengerNames = passengers.map((passenger) => passenger.passengerName);

RESULT - using 'map'

The map function also loops through the array and returns a new array for every item in the list. With this set-up, we simply return a single element, not an object.

The result will again be the same in the console, but your code will even be better than the first and second one because this time, we don't need to create an empty array before the actual task.

Here is the food for thought on this topic. Those who say 'less is more' have a point when it comes to writing codes.

Interview Question 2: How to Get Vegetarian/Vegan Singers

Let's now take a look at the next challenge. The new task asks us to obtain only the vegetarian / vegan singers from the passengers' list by also keeping the first argument in the main question section.

How to Solve With a 'For Loop'

Again, we can use the same old 'for loop' for this one as well. All we need to do is to check whether there are any vegetarian / vegan singers in our passenger list through an 'if' statement inside our existing function.

const passengerNames = [];
for (let i = 0; i < passengers.length; i++) {
    if(passengers[i].isVegetarianOrVegan) {
    passengerNames.push(passengers[i].passengerName)
    }
}
console.log(passengerNames);

RESULT - using 'for loop'

We do that with the isVegetarianOrVegan property in our object. Basically, what we say is this: if the relevant statement is true (if there are any vegan / vegetarian passengers in the list), just push those items into our new array. The result will give us three singers' names as those are listed as 'vegetarian or vegan' in the data part.

How to Solve with 'forEach'

As a matter of fact, the 'forEach' function handles the problem similarly. But once again, it has too many lines of codes as you see below, so it isn't the ideal version.

const passengerNames = [];
passengers.forEach((passenger) => {
      if (passenger.isVegetarianOrVegan)
        passengerNames.push(passenger.passengerName);
});

console.log(passengerNames);

RESULT / 'forEach'

How to Solve with 'Filter' & 'Map'

To come up with the best option, this time, we will use two different methods. The 'filter' and the 'map' functions will – in a way – collaborate to create better logic when solving the given problem. Let's examine the following code snippet closely now.

const passengerNames = passengers.filter((passenger) => passenger.isVegetarianOrVegan).map((passenger) => passenger.passengerName);

console.log(passengerNames);

RESULT / 'filter' + 'map'

With the filter method, we only get the vegetarian / vegan passengers from our array in the first place. If it finds some non-vegetarian / vegan passengers (like our beloved 'Freddie'), it will get rid of them automatically.

Briefly, the first part of the equation, the 'filter' method will simply work through 'yes' or 'no' model.

Then, the 'map' function will come in, eventually giving us a brand new array showing the vegetarian / vegan passengers only.

This final solution will prove your future employer that you genuinely know what you're doing and you are really taking the right steps to be a hotshot developer.

Interview Question #3: How to Sort Passengers by Connecting Flights

The last section asks us to sort the list of our super cool passengers by the number of the connecting flights they'll take to eventually reach LA. Let's see who has more and as such, will be pretty exhausted.

Spoiler alert! Amy with four connecting flights in total might be a bit sleepy in the get-together at that fancy restaurant. But there is no doubt that she will somehow rock where ever she goes.

Image Source

Anyway, what we need for this task is to know how the 'sort' function operates.

Primarily, it compares items one by one and returns something as a result. In our case, it will be the number of connected flights. But how does it make that comparison? What is the logic behind that?

_[Source Code: MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/GlobalObjects/Array/sort"><nr-sentence class="nr-s149" id="nr-s149" page="0)

The above lines of code are pretty clear in general. Thanks to the 'sort' function, we list those months in alphabetical order.

Well, here comes the big question. How does the code / system know that 'a' is the first letter of the alphabet and as such, the list starts with the 'd' letter (December)?

The reason is that the 'sort function' lists things in ascending order by default. But can't we change this setting? Perhaps, we need to list items in descending order. Of course, we can.

Let's see how. To achieve what we want, we may utilise 'a' and 'b' letters as parameters leading to different directions.

_[Source Code: MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/GlobalObjects/Array/sort"><nr-sentence class="nr-s160" id="nr-s160" page="0)

Simultaneously, we can benefit from the assistance of three numbers: -1,+1, 0 as seen above. When sorting items in descending or ascending order or finding the equal values, they can be quite handy.

Tricky Bit of the 'Sort' Function

In the following example, the list is sorted in ascending order. Why is it like that? Here is the reason. When we return those 'a' and 'b' parameters, we use this order: 'a - b' . That gives us ascending values by default.

_[Source Code: MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/GlobalObjects/Array/sort"><nr-sentence class="nr-s169" id="nr-s169" page="0)

However, if we swap them and say 'b - a', the list will be seen in descending order this time. That's the tricky bit when it comes to the 'sort' function.

In the above example, the first version (regular function) and the second one (arrow function) are in essence the same, but just be aware that arrow functions came with ES6.

Although arrow functions help developers to write less code, you cannot use them everywhere. (Read this to find out when to use them.)

Testing Our New Knowledge

Shall we now analyse the situation of our passengers through our new perspective? We know that the last task asks us to sort the number of flights in descending order. But the following set-up does the opposite.

It can only give us the list in ascending order. Why? It's simply because of the pre-defined order (passenger1.connectedFlights - passenger2.connectedFlights) as in the case of a - b example.

 const numberOfFlights = passengers.sort(
  (passenger1, passenger2) =>
    passenger1.connectedFlights -  passenger2.connectedFlights 
); 
console.log(numberOfFlights);

Once we swap the order (passenger2.connectedFlights - passenger1.connectedFlights) as you see in the following code snippet, our problem will be solved and the list will come in descending order.

 const numberOfFlights = passengers.sort(
  (passenger1, passenger2) =>
    passenger2.connectedFlights -  passenger1.connectedFlights 
); 
console.log(numberOfFlights);

RESULT - Descending Order by the Number of Connected Flights / Michael is the luckiest :-)

Can We Also Use 'for loop' or 'forEach'?

Well, yes and no. Both would be low-level solutions for this question.

We should keep in mind that the sort function mutates an array. This is a kind of side effect which changes the original array and that might be a problem if we use 'for loop' or 'forEach' as a solution.

There are of course ways to avoid mutation in the sort function, but in our example, it will lead to more lines of codes, which is not practical at all.

Wrapping Up

We've started the article with David Goggins, the symbol of resilience and grit, so let's end it with his inspiring presence and ideas.

If you happen to read this modern day hero's book or listen to one of those famous podcast episodes (For example, this one) where he was a guest speaker, you'll immediately understand that he wasn't born that way. Rather, his secret lies in the fact that he never gives up, against all odds.

Coding interviews are tough, but if you keep going after your goals by visualising the scene of success in your mind over and over again, it will - sooner or later - be yours.

Image Source

Many thanks for reading this post. If you've liked this article, one of the best ways to support me is to share it. Should you have any questions or comments, you can always contact me via LinkedIn. I'll be more than happy to help you out with your queries.

Happy coding!

“Knowledge is power.” – Francis Bacon

• How I taught myself new skills

• How did I know that learning to code at 37 was not “too late”

• How I prepared for big tech coding interviews

• How I analyzed and minimized the risk of career change

• How I worked out that software engineering was “right” for me

• What languages I focused on

• Whether being a FANG/FAMGA software engineer is right for everybody (hint: tempting to think so but I saw plenty of evidence of it not being right for some people’s goals)

Note: I think “FAANG/FAMGA” is limiting, and prefer to refer to “big tech”since there are many highly prestigious companies other than the usual 4-5 everyone obsesses about.

Why I Wrote This Article

Each of those questions I listed above deserve their own article, even though I know our contemporary culture prefers “tweet-sized tips”. However, meaningful skills can’t be internalized from a few hundred characters.

So today I am going to share with you my answer to one of those questions – the approach I adopted when:

1. I made that first jump in careers from lawyer to coder at 38, and

2. How I prepared for big tech interviews at the ripe ol’ age of 39, with less than 2 years of coding behind me.

If you want me to write on any of the other questions I always get, please let me know! I’m going to put my contact details in this post somewhere, and the only way to find it will be to go through the article. 😊 That is also to encourage you to carefully read this article rather than skimming for a “quick tip”.

Uncovering the Real Goal

I hold the following opinions: getting coding interviews is harder than learning to code. Doing well at the interviews is often just as hard as getting the interviews. Behavioral interviews are hard if you don’t have solid experience – but your competition does.

When I made the switch I had zero coding background. Later, when I set my sights on Big Tech, I knew I’d be competing with PhDs, people who’d been coding since their teens (often 20+ years), and folks who'd achieved a lot more technically than I had in my one brief year’s experience as a developer.

And I had the added challenge of applying for big tech from outside the United States.

So I had to develop a plan that went well beyond just “learning to code”.

First, let me explain why I concluded that “learning to code” is the easy part, even though I’d tried and failed to learn to code 4 times, between 2012 and 2018.

This insight came to me in late 2018, when my startup was struggling. I had lost tens of thousands of dollars building my startup. I had no income for over 2 years.

And I decided to pull out over $40K from my mortgage. Why? I got into a top-rated bootcamp in San Francisco.

I left my family behind, and relocated to the US. I was meant to be there for over 14 weeks, but I withdrew from this top-rated bootcamp in week 1, and returned to Australia.

I had been super excited about the adventure (and scared from all the debt). But I developed grave doubts about the bootcamp strategy. I noticed that my instructors and the program were designed to help people "learn to code" rather than "becoming a coder".

From my experience on the hiring side in 3 other industries and 4 countries, I knew this was a mistake.

Learning to code is just a form of “literacy”. And literacy is not skill.

I was living proof: each of the 4 times I focused on “learning to code” I succeeded in a narrow sense. Whether it was HTML or Java or writing a simple Android app from a book, I always succeeded at learning how to read and write the basics. But I had no idea how to actually build anything useful. I was completely hopeless at applying my knowledge – I had no real “skill”.

In this century we don't get hired for what we know. We get hired for skill.

I quickly saw several reasons why a coding bootcamp was the wrong strategy for me.

This expensive bootcamp would likely give me some basic skills, the kind that may even get me an “entry level” job. But I could see things were going to be rushed, standardized, and focused on "getting out the other end".

I didn't want to "tick a box". I wanted skill. Competence. Confidence.

Moreover, bootcamps seemed to prepare everyone for entry level "junior developer" jobs.

I was 37 and I didn’t want to settle for an “entry-level job” mindset. Plus I don't believe anyone with 3 + years of experience is "junior" even if they're a total newbie in the field.

Then I discovered that several instructors and teaching assistants at the bootcamp were former students who hadn’t yet found jobs. They had never changed careers – many had never had a "career" as such. The job-search counselors had never even been on the interviewing side in tech.

How was I going to learn to do something from people who’d never done what I needed to do?

And then there was geography. Students based in San Francisco had advantages, whereas people coming from other parts of the US did not find work that easily and ran out of money in the long months after graduating and before getting their first job. Heck, I was based in Australia...how was this going to work for me?

I looked at my explicit goal. It was not to "learn to code" – it was to build a career that fulfilled me.

Plus, when researching bootcamps, I could see a path to learning “part time”. That seemed like a much more sustainable strategy to me because I could find a job and learn at night and on weekends. After over 2 years of no income, I needed to have cashflow in order to keep fear at bay, and focus on becoming a professional coder.

As the legendary businessman Harvey Firestone said:

“Having a surplus is the greatest aid to business judgment that I know.”

Having income while studying would give me the confidence to make better judgments. Better judgments are important for a career that is fulfilling in the long term.

I had no doubt that I would "learn to code" if I did 3-4 months in the bootcamp.

But would I learn enough for a good team to pay me money for my skills? I no longer believed bootcamps and online coding websites would help me achieve that.

Learning to code would not get me far. I had to be good enough to beat my competitors who had coding degrees, prior experience and networks. I wanted a career in code.

So I left the bootcamp, wrote off about $9,000 and returned to Australia. Sure, I had gained rudimentary coding literacy to pass the entrance test for the bootcamp. But I was very far from competent.

This analysis may be hard to understand if you’re new to the workplace. Another way to truly understand it is to notice that many of us play music, but aren’t in a band. As my mentor said:

"Michael Jordan didn’t want to learn to play basketball. He wanted to be in the NBA. Huge difference."

How to Use Your Advantages & Disadvantages

That one insight made all the difference. Within 8 months, in 2019, I got all 4 developer jobs I applied for. I simply followed the program I’d developed with the help of my (non-technical!) coach.

Don't be misled though. I had unexpected advantages. I benefited from 2 major advantages that initially appeared to be disadvantages.

This was not my first career change, and for almost a decade, I had been on the hiring side in previous careers. Today I’ve been on the hiring side in engineering too, and the patterns are very similar.

My biggest advantage was that I was no longer thinking about the job market challenge as a candidate. I was thinking about this from the perspective of the hiring manager. That had a significant impact on my plan because I had experience of how hiring managers think – their constraints, priorities, values, business needs, dislikes, red flags...

My experience (age?) helped me understand what impact I could deliver to a team and organization, and to identify the right people that I could learn from, who could help me with ideas, guidance, suggestions and referrals. What was a disadvantage was now an advantage – a career changer's advantage.

On the point of advantages, I want to call out something important.

The easiest thing in the world is to dismiss others for having “killer” advantages. It's easy to shrug and say "Of course – that’s why they succeeded". It’s easy to not notice that everyone has very compelling and serious disadvantages.

For me, my “disadvantages” were:

• Geography – I don’t live in the US or one of the other tech hubs

• No formal computer science qualifications

• Zero technical background

• A mortgage and financial responsibilities

• My “age” – learning new skills when you’re pushing 40 is harder than when you’re 25

• Cultural and social expectations, judgment, negativity

• Recruiters and bosses being younger than I was and uncertain of how to deal with me

• Compared to other candidates, people viewed my change as very, very “risky”

• I was going to earn less in engineering than I would as a lawyer

Every day I hear from people who let any one of these things stop them. While I cannot comment on whether or not they’re real reasons, I can say that if we argue for our limitations, we get to keep them.

Clinging on to our disadvantages does not help us overcome them.

With the help of my coach and a ton of mindset/psychology training, I was able to dig into my disadvantages and convert a few of them (not many!) into major advantages. And that’s when I realized that my experience with how interviewing, recruitment, and resourcing works would help me a lot in formulating a strategy.

Priority one: career change

When learning to code and intentionally setting the goal of becoming a professional coder, I found that I kept switching to short-term thinking and obsessing about my first role.

I wanted my first role to be glorious, to prove all my critics wrong, to pay me a gazillion dollars and save me from having to deal with self doubt and struggle for the rest of my life.

But I had to train myself to view things differently. My first role must be one that makes me learn and grow, and set me up for future success no matter what happened. It needed to pay fair market rates, but I was happy to take a slightly lower salary if the team was fantastic and the growth/learning was solid. It did not need to be my dream job.

I was very explicit in the tradeoffs I’d make:

• Team matters more than brand

• Team matters more than money

• Brand matters more than money (as it would set me up for future opportunities)

• Money matters more than stock (this was for my first dev role, as this would make my continued learning plan sustainable, even though stock may give me more financial upside)

• But, learning mattered more than brand or money – as learning more would save me time which is better than saving me money

• I would not trade off between team and learning. I needed both (but I was more likely to get reliable signals on the team than I would on the actual learning/growth I’d get on the job)

“Nailing it” or being comfortable was not a priority. My priority was to successfully change careers.

Accepting a rubbish coding job (and there are plenty of them…) would not be a “successful” career change for me. But equally I didn’t have to get into big tech (ever) for my career change to be “successful”. This was very personal – success to me meant loving the work I do and learning a lot doing it. Period.

How I Made a Customized Plan

After analyzing my advantages and "convertible" disadvantages, the next thing I needed to develop was a customized plan. I needed one that was tailored to me, that I could believe in.

I needed a plan that took into account my specific context, which includes my temperament, experience, beliefs, values, goals and skills.

Note that I’ve still not talked about the technical interviews, the algorithms and data structures, and so on. When developing my plan, I had to focus on all the many pieces that had nothing to do with my coding skills or technical capability.

It would also need to account for my psychological “runway” – how much time was I prepared to invest in this career change, before I’d give up, lose hope, or change my mind? I could not answer that without understanding how long it was going to take me to learn the minimum required skills.

To understand that, I needed to research and analyze what the minimum set of engineering skills that the market would value were.

And to understand that, I needed to analyze the dozens of engineering domains in the market, and which ones would suit my temperament, interest/passion and advantages. And from that analysis I’d need to pick the domains that I would focus on and exclude all others.

I'd have to find the overlap between my interests, my ability and what the market valued.

Again, my experience on the hiring side of the market gave me some (small but important) advantages. I knew that pure technical skill would not be enough – that’s just the starting point. the “invitation to the dance”.

I also knew that good teams don’t just hire for raw technical skill, they hire for essential non-technical attributes as well. What those traits are depend on the technical domain, the team culture, the current composition of the team, and so on.

Yes, you're right. A custom plan is extremely multi-dimensional, and getting things right is only moderately helpful, whereas getting things wrong can result in a giant loss of direction and waste of time.

Since I was almost halfway through my career, I was determined not to repeat past mistakes. I was going to be:

• Highly specific in my goals.

• Highly intentional in my choices and actions.

• Focused on what I wanted, paying no attention to the things I did not want.

• Willing to change myself, my habits and negative beliefs, so that I could change the world around me.

• Ready to focus on building a rewarding and fulfilling career rather than just “getting the next job”.

• Ready to focus on delivering value for my future team rather than a “what’s in it for me” mindset.

• Willing to play the long game – think in 5-10-25 year horizons rather than the next few weeks.

I must confess, doing these things consistently was much harder than I anticipated. I slipped up a lot, especially on the first three. But since I had my custom plan written down, I let that be my guide and the sole source of truth for what I needed to do.

My plan required me to focus on fundamental programming skills, and then narrow it down to the segment that I felt matched my long-term goals and skills. For me, this was web development. This meant completely and ruthlessly avoiding all the “shiny new things” and doing things like Python or Java.

And tutorials and endless videos were not going to make me beat the competition. I calculated that the minimum set of skills I’d need to develop for my city would require 900-1100 hours of focused coding, practicing the right things in the right sequence.

Preparing the plan took several weeks. I kept refining and strengthening it and didn’t rush it artificially. I am very inspired by Abraham Lincoln (another lawyer who changed careers!) and he once said “Give me six hours to chop down a tree and I will spend the first four sharpening the axe”.

I was so tempted to dive right into my plan and get “busy” but I’d learned that being busy was so not the same as being effective. Once the plan felt as complete as it could be with the information I had at my disposal, I turned to executing on that plan, with total focus.

This meant a lot of sacrifice, and many, many days of self doubt, battling the temptation to switch, and learning to manage my energy. I developed some amazing habits during this time, but they were only obvious to me in hindsight. During those 6 months of work, I was constantly assailed by uncertainty, fear and occasional loss of hope.

Later on, I adapted this planning process to create a plan for Big Tech and especially for Google. That plan took another 500-600 hours of intentional study that was completely different from my plan to become a developer. More on that later.

Early Results, and then…Google SWE

Another lesson I’d learned from 4 years of trial, error, and failure was that I was very likely to change plans midway, switch resources, courses or focus.

This is a much more serious problem than we realize because every time we switch focus or plans we throw out the hard work we’ve done, go back to square 1 and…start…all…over…again.

Imagine if you were driving from A to B and kept taking U-turns and going back and restarting. You’d never get anywhere.

But I’d made myself a promise (it’s easier to keep a single promise than to keep a bunch of them!): I was going to complete my plan and then decide whether I would keep going. This time I wasn’t going to stop until I completed my plan.

I didn’t have to like doing it. I just had to like the possibilities that lay at the end of doing it.

My plan had a specific time when I would start interviewing even if I didn’t feel ready for interviews. But to get to that stage I had to get good at generating interview opportunities.

Again, my past experience in other careers helped me. I applied all my learnings over 18 years and secured 4 interviews within a few weeks, and got all 4 offers even though there were plenty of candidates with more experience, skill, and qualifications than I had.

It wasn’t because I was better at coding. I don’t see how that could be, given that I’d only been in the game for a few months.

I believe I got all 4 offers because during the interview process I demonstrated that I was a better candidate for the hiring manager. This approach was critical in how I presented myself.

Getting the offers is great, but I had an unexpected problem. Since my plan required me to be highly intentional about the kind of work I’d pursue, all 4 roles I’d applied for were the ones I really believed would be a fantastic start to my new career. How was I going to choose?

Yes it’s a great problem to have, but that doesn’t make the decision easy!

To resolve this problem intelligently, I learned to ask myself a very important question:

Do I know this or do I simply think this?

Very often we make decisions based on assumptions and beliefs that are completely untested, and we mistake our opinions or fantasies for reality. What we actually know is way less than what we believe without truly knowing.

Being intentional required me to focus on what I know rather than what I wished, or merely thought. I had to either find evidence to back my thoughts, or disregard thoughts for what I knew.

That framework developed my analytical powers and helped me choose the right first role in early 2019. I turned 39 around that time.

Till today I continue to use this know vs think framework in my personal decision making as well as in my engineering decision making. I find it to be an excellent framework for analyzing tradeoffs in complex decisions.

Looking back, I learned a TON about sticking to my plan, revisiting my goals, self-awareness and practicing being intentional.

A few months into my new role, I noticed that a lot of lawyers were starting to reach out and ask me how I did this. Curiously, many of them were people who insisted I was making a huge mistake and that wanting to learn to code at this stage was immature and foolhardy.

Now they wanted to “learn to code”. And that made me think.

What else have others said is “not possible”? Do they know that or do they just think that?

And my goals hadn’t changed. For me learning, growth, and team were still more important than brand or money. But I was almost 40 and I also wanted to explore life in a way that I’d never had the courage to do in the first half of my career.

So I decided to set myself a stretch goal: I was going to find out what being a software engineer at Big Tech was like. I’d worked in huge companies before and I knew that it isn’t for everyone – that’s the reason I went into startup and smaller companies in the first place.

But wouldn’t I learn and grow SO much by being surrounded by some of the “best” people in their field, from engineering to product and sales? Did I know this? Or did I just think it?

I did the research and found that on average people were happy in Big Tech. But I also found that most people were not as intentional as I was. So I confined my research to people who were very intentional about their careers. And they (almost universally) said they grew a lot from Big Tech, even if they decided to leave. Leaving Big Tech was also intentional, in pursuit of their end goals.

So I decided to try for big tech (including 3 of the FAMGA companies) and several others, in Silicon Valley, New York, and Seattle. I was still based in Australia, so this was a massive challenge.

I re-designed my plan. Several of the steps were the same but the coding curriculum would have to be massively overhauled. I also needed to find out how US big tech recruitment is done, and be worthy of a referral.

About 7 months later, I started generating interviews. I worked very hard to prove myself worthy of referrals for those 7 months, and people offered to give me referrals based on my efforts and proven commitment.

I got referred to Meta (it was called Facebook then) but I didn't get the interview as my skills were not the right match. This was a massive learning for me as I thought I’d been careful to only apply for roles where my skills matched – and I was wrong.

That was when I realized that sometimes the position description is written in ways that mean one thing for the hiring company but means very different things outside that company. This is because different organizations use the same words to mean different things. Both the hiring side and the candidate side can be unaware of this!

All these learnings added up. Within 3 months I got offers from 2 big tech companies, and missed out on a third at the final interview because I just didn’t know how to write a filesystem from scratch (I didn’t understand much about the Linux world at all!).

And then I got an offer from Google.

Again, I was faced with a very difficult decision. Google is a cultural force that is very hard to be objective about. But I really wanted to stay true to my goals, my plan, and my intentions.

Trying to separate what I knew from what I thought was EXTREMELY hard when it came to Google. But I was absolutely sure about one thing: the team I’d interviewed with were amazing people.

And this is where I believe luck matters. No matter what people say about skills, brains, smarts and all that stuff, luck and "magic" have a role in life.

My interviewers from Google were friendly, kind, cheerful and highly focused engineers. They were not looking to prove I sucked. They wanted to help me prove I was good. They answered my questions with enthusiasm, and I felt like collaborators from the first minute.

Is this a Google thing? Maybe. But later, when training to be a technical interviewer at Google, I witnessed a very wide variety of interviewer/hiring manager styles and beliefs. I saw candidates with great skill losing their nerve, struggle to communicate their process, and so on. And I came to appreciate the role of chance in all this.

So yes – I was lucky that I had the kind of interviewers I did, and that on interview day I happened to know how to work through the code.

This is also where my ultra-focused preparation on type of work and relevant skills paid off. There are a very large number of engineering roles at Big Tech that I would never have been suited to (like the one at Meta). Even with my prior experience in other careers, I had no idea how HUGE the engineering world is, and how many flavors and types there are, and how hard it is to tell them apart.

By forcing myself to be highly intentional and not randomly and blindly applying for big tech engineering roles, I improved my chances in small but important ways. I dug deep into each role and researched them carefully by speaking to friends in the industry (again – my age and experience was an asset because I had built relationships over 15+ years never expecting that they’d be so useful later on!).

For each offer I got, I had researched the role deeply, and prepared for the technical interviews well. On interview day the stars were aligned, and things worked out. Though I don’t think I “nailed” my interviews, I did well enough to communicate that I was a suitable candidate for the team’s needs.

Which leads me to the question: How did I prepare for the Big Tech interviews?

How to Prepare for Big Tech Interviews

Answer: In two phases that took me over 500 hours to execute.

Phase 1: Learn the Realities and Competitive Landscape

If I wanted to tackle Big Tech, from another country, with less than a year of industry experience, and 15+ years in an unrelated career, with no Computer Science degree, I needed to have a very clear view of the realities, especially the competitive landscape.

This means there was room for informed hope, but no room for dreamy-eyed, pie-in-the-sky magical and wishful thinking.

Hard truths (see my initial YouTube Videos on this here). Hard realities. Hard work.

I had to fully internalize and appreciate the following:

• Coding is just the starting point. Not the ending point. Learning to code was the first step of many, one small piece of a much larger puzzle. In other words, it is necessary, but not sufficient to get a coding job (and especially at big tech).

• My biggest enemy would be my own mind. It would either let the negativity of others get me down, or it would turn against me and undermine my own confidence. I had to build the habits that would help me have a resilient mindset. I focused on recovering from setbacks rather than avoiding them.

• My competitors would likely not be career changers. Or if they were, they’d be from closely related fields like computer engineering, mechanical engineering, or electronics engineering. The vast majority would have technical qualifications, maybe even PhDs (this turned out to be true!), and several years of industry experience.

• As an outlier and a “wildcard”, the hardest part would be getting the interviews. Learning algorithms and data structures would be easier. And “cracking the coding interview” (whatever that means…) would be easier too. Why? Code is deterministic – identical code generally produces identical results. But life is not deterministic, and getting interviews is highly subjective. In the job market, identical actions do not produce identical results.

• I needed to shape myself into the kind of person seasoned engineers would want to work with

• I assumed most of my competitors would have at least 3 -5 years of experience. I couldn't catch up with them, let alone overtake them. Instead, I needed to outperform them on non-technical skills and compare favorably (if not outperform them) on the technical stuff.

• I had to communicate better than the others. If I didn’t know something, I’d need to say so and then communicate how I’d solve it if given the right time and opportunity. I also had to communicate to show interviewers that I understood their business needs and wasn’t just focusing on my selfish dreams.

• Which means I had to really work on understanding what the hiring team valued, was looking for, wanted, and needed.

• I could not control my competitors (their skill, their performance, how much they knew, and so on), or what my interviewer was thinking, wanting, what they valued, or whether they liked career changers or not. I could not control most things. I could only optimize my effort, my focus, my psychology, and how much learning I extract out of each experience, good or bad. I could only control my choices and actions. So focusing on anything outside that would be a waste of precious energy.

• I had to accept the role of luck. Jordan, Tendulkar, Federer – they’ve all had bad days. I would too. Or maybe I'd do great, but on the day someone else would do better. Or someone else would just be a better fit for what the team needed. No harm, no foul. I’ve made those hard decisions on the interviewing side countless times myself, so I know how these things work.

• If I was successful at more than 1 offer I would need to pre-think and pre-agree with myself about what signals and factors I would use to decide (I’d learned from my experience of choosing between my first 4 offers!).
  If you’re wondering how I knew how to do all this…I didn’t. Not all at once. What you’re reading is a summary in hindsight. But I had to work most of this out in “real time” based on “first principles thinking”. And I worked with my mentor to tighten them up as I went along. It took a lot of time and I was so impatient to “start coding”. But …I knew what advice Abraham Lincoln would give me…

Phase 2: How I Chose My Learning Resources

I know everyone thinks there is a secret “magic bullet” out there. Some blog, video, resource, tutorial, podcast, PDF cheatsheet…_something…_that will unlock the entire “secret” and make us instantly learn things.

Nope.

I’ll bang on about this till the day I die – information is a commodity.

Learning is hard, but it’s made much harder because there is too much free information.

We all fall into the trap of thinking there is some missing piece of information. There isn’t.

Why? Because no matter where you live, what language you speak, what color your eyes, skin, or hair are, what gender you identify with – all resources are going to teach you things that “work”. They’re all “the same” at a very fundamental level.

They have to be, because that’s how computers work.

If you and I write an identical function in JavaScript or Python or Java, we are going to get identical results. That’s how computers work – they’re deterministic algorithms.

But life (and interviewing) is most decidedly not deterministic. Identical effort, grades, skill, intelligence will not produce identical results.

Again, I had to teach myself to learn. I had to teach myself to shift my attention away from resources/blogs/websites/courses and put my attention on building solid mental models, identifying relevant skills, drilling down on concepts rather than code implementations, applying what I already knew in new ways, reasoning, problem solving, and communicating my reasoning while I reasoned.

Now you’re going to be surprised by the resources I used for my Google and other Big Tech interviews.

Yes, I used Leetcode, Algoexpert, InterviewCake and Jenny’s CS Lectures and perhaps a few others. But I didn’t complete a single one of them.

This wasn’t because I switched or lost focus. I was being intentional. I realized that they all teach the same thing, but with slightly different styles and content. So I used these resources to learn concepts and mixed and matched all these resources based on my analyses of interview patterns.

My reasoning was simple. Having been on the hiring side, I know that every year the quality of candidates (at good companies) improves. I personally think that focusing on the company is a huge mistake – we should focus on the team, people and kind of work.

But the world works a certain way, and because of that, everyone rushes to the big companies. This increases competition which makes it harder for hiring managers to assess candidates.

The only way for hiring managers to deal with this is to raise the bar, making it harder for candidates. The overall number of candidates keeps increasing, but the “pool” of candidates that get invited to the interview stays within a narrow range – usually 2 -10 people. Regardless of how many hundreds apply that’s about the number that will even get a chance to interview.

Therefore, the number of candidates that don’t hear back or meet with rejection increases, especially in bull markets.

If the competition is increasing and the resources on the internet are also increasing, but the shortlisted number stays more or less constant, then “learning more” cannot be the solution. Everyone is “learning more”, so relative to the competition there is no change.

I also realized that Big Tech would have lists of interview questions (this is “efficient” as interviewing is very time consuming, and so it makes sense to save time by having a question bank that interviewers could use). Naturally, they would not use these questions if they were “leaked” – that would defeat the interview process.

So, logically, hiring managers will not ask questions that are available on Leetcode or Algoexpert or other sites. This produces a kind of “arms race” – the more questions are made publicly available, the more questions in the question bank are changed. That results in more innovation and variance in questions and hiring strategies.

This left me only one choice. I had to learn to solve problems using mental models and by classifying them. Chances are I was never going to be asked to sort a Linked List or to implement Dijkstra’s shortest path algorithm. Instead, I would need to know how to apply these sorts of algorithms to “real world”, practical problems.

Often real world problems don’t look, sound, or smell like the practice questions we study. Practice questions and competitive coding questions tend to be “neatly” packaged up with clear constraints.

But as an interviewer, I wanted to know how the candidate thinks, reasons, analyses, interprets information, and collaborates. Solving the problem is a bonus. Often they have the right solution but run out of time – but ask great questions and clearly know how to tackle the problem. These candidates can still get the offer.

Later, as an engineer at Google, I could always tell if someone knew how to solve something even if they were unable to solve it in time. Equally, it’s immediately obvious when a candidate does not know how to solve something (and that's OK – we are all learning).

By adopting my approach of understanding problem types and solutions rather than specific code implementation, I could focus on learning to reason rather than learning to write specific algorithms.

This approach meant that I completed less than 40% of Algoexpert (and back then it had half the questions it has now). I also did maybe 50-60 questions from Leetcode and most of them weren’t the “hard” ones.

I figured that “hard” questions would probably show up in 45 minute interviews about 20% of the time which means 80% of the time they’d be easy or medium questions. So it made sense to optimize for the 80% given I was still relatively new to engineering and the hard problems would get in the way of understanding easy and medium ones.

I used these resources to recognise patterns rather than just “complete” and get a certification. That’s why I didn’t complete any of them. And no, I didn’t use “Cracking the coding interview” either.

Along the way I also started a systematic process of understanding system design questions. I documented system design preparation in a long form blog on the essential concepts for system design interview questions.

I also decided to focus on one language: JavaScript. It wasn’t the best for interviewing (seasoned engineers discourage it on Quora and elsewhere) but I didn’t see how it mattered. The purpose of the interview was not to test my choice of languages – it was to test my ability to think abstractly and solve complex computer science-y problems.

The language is just a tool (another core belief I hold). In fact, using an untyped language like JS would give me opportunities to talk about its limitations or strengths, which is an opportunity to demonstrate that I understand the tradeoffs in language choices. That way, I could showcase broader knowledge and insight without actually having to implement it all in code.

But a lot of the resources I learned from used Java or C++. These languages are the dominant languages at Google. So being forced to read these languages and understand the principles forced me to not focus too much on “spitting out the code” and more on reasoning through the code so that I could write it.

That was my entire plan. Practice, Pattern Recognition, Mental Models/First Principle Thinking, System Design, doing fewer things really well, and focusing on getting interviews rather than just learning more code.

How to Stand Out During Interviews

As I mentioned, we all have advantages and disadvantages. And we all think our disadvantages are special and huge and our advantages are common, unremarkable, and probably not of much use.

This is not true. Logically, if we all think our disadvantages are severe, then we should all succumb to them. Yet some people overcome them. Only to find that others had it even worse and overcame those.

It’s way better to focus on what we can do well. For me, I truly believed that I could add a lot of value to the team. I don’t care about being the smartest or the best. But I care about being an outstanding learner, and maintaining my growth mindset at all costs.

And so I tried to use this to stand out as best I could. I learned to ask really good questions of recruiters, interviewers, and hiring managers.

But there was a deeper reason for this. Asking good questions was my way of interviewing the company. Like I said, I didn’t want to repeat the mistakes of the first half of my career. So asking really good questions was important for me to assess whether the company was a fit for me and not just the other way around.

Since I had decided that I was going to value the team and the learning over all else, I never asked about the compensation until the recruiter raised it. It was going to be lower than what I earned as a lawyer anyway!

Instead I focused very hard on learning about the team, its dynamics, its group beliefs and values, how the manager solved problems (especially people problems), what the team was interested in, what the company division was interested in, how its balance sheet was doing, what its strategy was, what its resource allocation and budgeting looked like, and so on.

All these things were things I'd learned in other industries, as an individual contributor, as a manager, executive, founder and so on.

And all of these things also showed that I was being highly intentional. I was genuinely interested in the team, and the company, its product and its future. This wasn’t just another job I was applying for. This was active and personal…not passive and opportunistic.

And I believe that helped me stand out. Maybe not for all the roles I interviewed for, but for many of the offers I got.

When I was on the hiring side, I’d always prefer candidates who were genuinely interested in the role, the people, the product and the company. Those that showed up just “to get a job” didn’t have the kind of energy and drive we wanted.

Interview Planning and Strategy

The last aspect of my roadmap required me to deeply understand the different types of coding interview processes.

This included technical and non-technical interviews, the format of interviews, the way companies organize them, run them, plan them, staff them, evaluate them, and weigh them. But it also required me to understand my strengths and weaknesses.

When going for Big Tech in the US I was aiming for 2-3 interviews per month – a huge goal given that I was not even in the US and was in a timezone that was 17 hours ahead of the west coast.

I had to plan and structure interviews at weird hours so I could accommodate my day job as a developer and also my study time. Some interviews took 6 hours, some took 10 or more. Some were “pair programming for a day” type interviews.

All this took a ton of planning, and mental training. I had to be careful to get the right sleep, the right exercise, maintain my mindset and confidence, deliver on my day job, be there for my family, study and maintain focus on my goals.

For this, I had to be honest with myself at what I was good at. For example, I am not a morning person. But I can endure late nights. So I structured interviews, work, sleep, or even exercise accordingly.

There were some interviews that were scheduled at 2am or after, and I wouldn’t sleep before (as I really am not good at waking up on time!). So I’d do a full workout at 1am to get my energy and focus up, then interview, then sleep till 10 am, then go to work and manage my schedule accordingly.

I would also be careful to plan interviews so that I wasn’t doing two of them back to back unless they were very similar and time bound. For example, doing a take-home test and doing a timed test in the same week require different planning from doing a take-home and a live-coding interview – all while managing work and family.

To schedule the interviews appropriately I’d work closely with the recruiter and be very transparent with them. This had two advantages: I gained credibility and trust with the recruiter for being collaborative and communicative, and they also got to see that I had other opportunities going, which increased the value of my candidacy. Competition is a good thing.

Concluding Thoughts

I am sure many of you were expecting this article to give “insider” tips and a specific set of languages, and DSA questions to learn. I believe I’ve given you something much better. Rather than giving you fish, I am showing you how to fish.

Apart from the ethics of it, insider tips are of limited value, especially in Big Tech. In huge companies things can be vastly different from team to team and city to city. You need to understand the principles of recruitment and career development, rather than just the specific languages and algorithms. Assuming that all interviews are the same is a big mistake.

And as for our obsession with data structures and algorithms…managing your career is the ultimate algorithm. Your mind is the ultimate data structure. Learn how to work with both and you’ll always do well, despite the occasional failures. Powerful ideas aren’t grandiose – they’re elegantly minimal.

If you have read this article you will have noticed some of the things I linked to include multiple ways to reach me. You can also get invited to my webinars, mini-courses and newsletters if you want to go beyond just “learning to code” and learn how to build a career that is right for you.

Perhaps the most important message I can leave you with is that it is a mistake to obsess about big tech. Yes, they’re great to be part of, but if we believe they’re the only thing that is right for us we will miss out on all the other amazing opportunities.

Big Tech has glamor because of cultural trends these days. Sure, it’s nice to work for a great organization, but plenty of great organizations are not well known. Plus what is “great” for one person is pain for another.

Your number one priority is to be happy, fulfilled, and live the life that you want. This is not derived from a company. This comes from the people you spend time with (especially colleagues) and the kind of work you do. Big Tech companies have their share of bad managers, teammates, and work, just like any other company.

If you build skill, stack a great plan on top of the right mindset, and train yourself to set the right goals, you can achieve much more than you dreamed of – with or without Big Tech.

Post Script

If you would like to learn more about my journey from lawyer to software engineer, check out episode 53 of the freeCodeCamp podcast and also Episode 207 of "Lessons from a Quitter". These provide the blueprint for my career change.

If you are interested in teaching yourself to code, changing careers and becoming a professional coder, or becoming your own technical co-founder, please reach out here. You can also check out my free webinar on Career Change to Code if that is what you're dreaming of.

In the words of RealToughCandy, everyone wants a "one-stop shop" when it comes to learning.

She uses this term to describe Educative.io, but Educative.io costs $60 a month unless you choose to commit to its annual plan. So it's not a free resource, which means it's not available to everyone.

If money were not a factor, you might buy a copy of Cracking the Coding Interview, get a LeetCode Premium subscription, and sign up for access to Grokking the Coding Interview before scheduling some mock interviews.

Now, websites like LeetCode are interesting because they provide an excellent resource for free. A large percentage of LeetCode questions are free, the discussions section provides free solutions where the best code/explanations are voted to the top, and the platform itself can run hundreds of test cases in seconds.

Many people argue that LeetCode premium is not worth it, though writers like Yangshun Tay beg to differ. What interests me about LeetCode is not their premium option, but that they make so much of their service available without it.

All that being said, there are a number of quality free resources you can use to prepare for your coding interviews. Let's go through my favorites now.

Best Free Resources for Coding Interview Prep

Without further ado, here are the best free resources I have found for coding interview preparation:

freeCodeCamp articles

The 30-minute guide to rocking your next coding interview is a free article available on FreeCodeCamp. Half the value here is in curated lists of LeetCode questions to match every major topic

Here's another great (and extensive) guide that focuses on JavaScript interviews and goes through all the JS basics you'll need to know. It includes tons of code samples, and moves through the material in an approachable way.

Cracking the Coding Interview

Cracking the Coding Interview is still one of the best resources out there for interview prep, even in 2021. I have heard some people say that it is no longer sufficient, but I have had two coding interviews that were taken out of the book almost verbatim.

Unfortunately, this is not a free resource...but here is a LeetCode forum that maps every CTCI question to a LeetCode one.

The reason this is acceptable is that they are not perfect mappings. For example, the LeetCode String Compression problem is not exactly the same as its CTCI equivalent because it has an added constraint. It is actually harder than the CTCI version

If you do choose to purchase Cracking the Coding Interview, the solutions are all freely available on GitHub. They are in multiple programming languages, in case you are not a Java developer.

McDowell herself built the repository and committed the Java portion to it, so it is very unlikely the repository will removed due to copyright infringement.

BaseCS

BaseCS is a great collection of articles that explain computer science fundamentals, from hash tables to sorting algorithms, with custom illustrations, well-written analogies, and light-hearted explanations.

Best of all, every single article is free from the Medium paywall. Had they not been, Joshi probably could have pocketed hundreds, if not thousands of dollars from all her readers.

Educative.io

The Educative.io course on 14 coding patterns is not free, but a summary is available on HackerNoon and written by an Educative.io cofounder...presumably as either a gesture of goodwill, or a "free sample".

LeetCode questions sorted by programming pattern

Here is a public LeetCode post that maps all 14 coding patterns to respective lists of LeetCode problems.

InterviewNoodle – still in development

Arslan Ahmad is building a consolidated collection of interview preparation articles on Medium called InterviewNoodle. Just weeks ago, I would have written that this resource is very incomplete, but he has added so much content that I actually think he may now want to divide it into sections.

This, like Educative.io, is meant to be a “one-stop shop.” That Arslan Ahmad is the founder of Design Gurus increased my respect for him exponentially, since this means he is attempting to build a free version of an Educative course that makes him money.

Currently the Medium pages on this publication are not paywall blocked. This could be a coincidence, but for now it's a great resource.

The rest of this article will cover additional resources, though the ones above are my favorites.

Additional Coding Interview Prep Resources

An Interview Primer

If you don't know what to expect in a coding interview, the "30-minute guide" from freeCodeCamp linked above is a great "primer". Still, it is rather lengthy – even though it takes 30 minutes to just read through it, it would take much longer to actually review and go through its "General tips" section.

This might be just what you're looking for if you want to be really thorough. But what other options do you have?

"Confessions from a Big Tech Hiring Manager" is my single favorite video. It's by "Pragmatic Engineer," and is all about the interview process.

This video has useful and practical advice, but it also conveys the perfect attitude. He argues that you should think of every failed interview as a learning opportunity.

Other Interview Prep articles

"If software engineering is in demand, why is it so hard to get a software engineering job?" This is a tongue-in-cheek overview of the coding interview process.

If you read it, you should probably ignore the "string compression" story, which does not add much to the article.

The other side of the software engineer interview is a kind of sequel to the article above, summarizing and responding to Pragmatic Engineer's thoughts.

The Responses I Got From A Software Developer Candidate That Made Me Hire Him is an article that provides more insight on the interviewer's perspective, but unlike the two above it is behind Medium's paywall.

What's the Interview Process Like, In a Nutshell?

If I were asked to summarize all the resources above to you, here's what I would share:

• I would say that you typically get between 30 minutes to an hour to solve a coding question.
• You typically get a choice of programming language like C++, Python, Java, or JavaScript, but not always...in some instances you do not have a choice.
• Outside of the coding portion, they are free to ask you pretty much anything, from language-specific questions to favorite projects, but any interview with a coding portion tends to be dominated by it.

And here's some general advice to consider: you are going to be dealing with people who may be pretty tired of interviews. Smile if you can. Try to show enthusiasm. Have a conversation, and try to talk to the interviewer the way you might communicate if the two of you were pair programming, but they were more senior.

How to Start Your Interview Prep

I think that for most people starting out in this interview prep process, LeetCode is pretty hard. Here are two possible starting problems, though the best point of entry is admittedly Cracking the Coding Interview.

• FizzBuzz on LeetCode. I recommend it because it should not require any additional interview preparation, and will help you familiarize yourself with the LeetCode platform.
• Here's an article about FizzBuzz on InterviewNoodle so you can learn more what that's about.
• Jewels and Stones on LeetCode. If you are not able to solve this on your first try, then you will have to learn a technique that is useful in many coding interview problems.

Learn about hashmaps

There are many more data structures than just hashmaps, but I see these come up in coding interviews so often that I think they deserve their own section.

• Valid Anagram is another good LeetCode "starting point." It does not necessarily require a hashmap, but something that acts like a hashmap
• Here is Nick White solving Valid Anagram
• This is Alex Lee using hashmaps in Java. He does not explain the internals of how they actually work, but he provides practical advice on how to actually use them.

What to do after you cover the basics

After you get started preparing and are comfortable with the basics, I would refer back to the resources above.

The 30-Minute Guide and Cracking the Coding Interview (again, there are free LeetCode problem mappings if you do not own Cracking the Coding Interview) both cover computer science fundamentals. And 14 coding patterns goes a little bit further.

Closing Thoughts

There is a lot more work to be done when it comes to coding interview preparation resources. It is relatively easy for me to simply point to good resources in an aggregate post, but actually providing comprehensive reviews or my own resource would require an order of magnitude more effort. I haven't gotten there yet.

So for now, there is certainly a gap. The most comprehensive content, in my opinion, can be found in Cracking the Coding Interview and this Educative.io course. And that's not to mention the plethora of resources someone with a lot of money could afford, from coaches, to coding interview bootcamps, to expensive mock interviews in which the interviewers provide detailed feedback.

That the people behind Educative.io and its "coding interview patterns" course have made efforts to provide free resources, like InterviewNoodle and a HackerNoon article, count for a lot to me.

I personally don't really use sites like GeeksforGeeks or interview resources on Github that are written exclusively in markdown. It would be very useful to build a platform with detailed blog-style explanations and embedded coding platforms, but at that point you would essentially be recreating Educative.io.

Medium provides an interesting case: Some of the best writers can be found here, but they are incentivized to put things behind a paywall. Anyone, in theory, can put up articles without a paywall on Medium the way BaseCS has. But few Medium writers seem to do this anymore.

We need more high-quality articles. We need practice problem lists that are continually updated. We need great YouTube content creators, like Nick White, to continue to provide clear problem explanations.

Efforts by BaseCS were largely successful, and my one wish is that it had continued to produce content...but this was all produced by a single person with a full-time job, a podcast, a YouTube channel, and apparently no compensation from Medium.

Not everyone has the same level of access to educational coding interview resources, so I admire the people who have done everything in their power to create free alternatives.

Yangshun Tay, author of "The 30-minute guide to rocking your next coding interview", sent me a personal email a few months after this article was published and shared some more helpful resources.

• Here's a link to the main Tech Interview Handbook Website, which contains in-depth and structured guides that can really help you prep for interviews.
• Additionally, he's published Grind75 which generates study plans based on time left, which could also be of interest to your readers.

The Tech Interview Handbook currently has about 69,000 stars on GitHub, and the website is the closest thing I have seen to a free, "one-stop-shop" software engineer interview resource.

Grind75 is designed to be a better version of Blind75, a popular list Yangshun also made that received 3200 upvotes on a LeetCode discussion.

I hope these help you out! Happy prepping.

We just published a course on the freeCodeCamp.org YouTube channel that will teach you all about binary tree algorithms and prepare you to use them in coding interviews and programming projects.

Alvin Zablan from Structy developed this course. He has created many technical course, including one of the most popular Dynamic Programming courses on the internet.

In this course you will first learn about the theory behind the algorithms and then you will learn how to implement them with code. The algorithms will be taught with images and visualization to help you really understand how they work.

This type of binary tree will not be covered in the course.

Here are the topics covered in this course:

• What is a Binary Tree?
• Binary Tree Node Class
• Depth First Values
• Breadth First Values
• Tree Includes
• Tree Sum
• Tree Min Value
• Max Root to Leaf Path Sum

Watch the full course below or on the freeCodeCamp.org YouTube channel (2-hour watch).

Transcript

(autogenerated)

Binary tree is a common data structure used in software development.

It's also a frequent topic and technical coding interviews in this course, Alvin will explain binary tree algorithms and prepare you to use them in both interviews and coding projects.

Hey programmers, Hamilton from Shruthi, elk to our course on binary trees, I want to show you how you can do well on those technical interviews that have binary tree problems.

So what I have in store for this course, like usual, we'll go over both the theory pines and binary tree algorithms, as well as of course be more practical and come up with a code implement those algorithms really a one two punch.

For every section, we're going to be sure to draw out a pictures and visualize and truly understand the algorithm on the whiteboard notes are feeling comfortable with that, we'll go over to the code implementation.

So in the description and in the timestamps, you'll be able to find the corresponding exercise, you can practice every algorithm that we go over.

In terms of the prerequisites for this course, I'm going to assume that you're not new to programming.

And maybe you've dabbled in some previous data structures and algorithms.

And you're also familiar with some recursion.

But that being said, I'm going to assume you know nothing about binary trees, and even just trees in general.

with no further ado, let's jump right in.

So first order of businesses, let's actually understand what the word tree even means.

And like the programming concept, right.

So when we visualize a tree, a tree contains many nodes, typically we draw nodes as circles, right.

And these nodes can also point to other nodes.

So here I have one node.

And I could point to some other node, right, I could point to any number of nodes.

So here are the circles, I'm going to refer to them as nodes, and the lines or hours between them, I'm going to call edges, right.

So this is an example of a tree.

And trees can of course, come in many different shapes and sizes.

So here's quite a large tree.

Let's try to understand a few terms we can use during our technical interviews.

And this is something I highly recommend, right? helps if you speak the language, it does show that you have proficiency dealing with the data structure, we could store values within the nodes of our tree.

For now I'm just going to put some letters.

When it comes to your programs, you can store any type you want, you can store integers, numbers, or even other objects.

So because we have a tree, we like to use familial relationships.

In other words, I think of like a family tree, right? So if I look at node B, let's say I call them the parent.

If b is the parent, I know that children of B are just the D nodes, right? their parent and child is like a relative relationship.

Let's say I kind of changed my frame of reference.

And let's say I looked at a as the parent, well, that scenario, then B and C are the children of a.

for the case of the C node, if I think of CSM parent, it only has one child, its lone child being the F node.

So feel free to use that parent child relationship when describing the relationship among nodes within a tree.

Another terminal is a lot in the context of trees is the word root, right? So a root is going to be a node that has no parent.

So in this tree, A is the root because a has no parent, right? There are no arrows going into the a node.

On the flip side of that, if I look at the nodes in DNF, we call them leaf nodes.

A leaf node is a node that has no children, right, so d and f have no outgoing arrows.

Typically, in a binary tree, we're going to have a single root and we could have many leaves.

One thing I want to be sure to do is make sure you generalize your understanding of a leaf, right? So in this particular example, looks like every leaf is two edges away from the root, counting the number of arrows from the roots, any leaf, it could be the case that my leaves occur at different levels, right? So I removed that F node, which case C is now a leaf, right? Although a C is on like a different level than D and E, it's not the bottommost level, it is the case that it's still a leaf, right? a leaf node is just a node that has zero children.

All right.

So with all of those terms out of the way, let's hone in on the real topic here.

Right, I talked a lot about trees.

But really in this course, I want to go over the basics of binary trees.

Right? So let's look at that binary part to begin with.

That's really a dead giveaway.

We know binary has to do with the number two.

A binary tree is a tree where every node has at most two children.

Right? So currently on the screen, I have a binary tree.

If I gave a another child, let's say a third node over here of f, this would be a tree but not a binary tree.

Right? It would be like a ternary tree because I have at most three children.

So let's say I kind of remove that extra node.

Now it's back to a binary tree.

And it could be the case that a node has less than two children but still be a binary tree, right? So if I gave C, just a child of f, this is still a binary tree.

It's if I look at any node within my tree, that node will have 01 or two children, and no one has more than two children, right? So you want to be sure to remember that a node in a binary tree could have less than two children.

All right.

So I'll be the first criteria for understanding what a binary tree is right? It's probably the easiest criteria and most children per node will also want to be sure to add into our definition Have a robust understanding is to also remember that, at least for us in computer science, we think of our binary trees as having exactly one root, meaning there should be only a single node that has no parent, right? Typically when we draw, it would be like the topmost node.

So right now this is definitely so far a binary tree.

If I had some other node in this drawing, like G, right, g also has no parents, I would no longer consider this a classic binary tree, right? So watch out for that.

Let's go on to our final criteria, we also need one more ingredient.

And that's exactly one path between the root and any node, right.

So looking at my example to the left, this is indeed a binary tree that meets all three criteria.

And let's say I chose the root and any node, obviously, there's only one root, so we're definitely considering the a node, let's say I chose some random node like E, this is really a binary tree, then we're guaranteed to have only a single path that connects A to E, a path is really just a series of connected nodes I can travel through, right, so to get from the root a to the node E, I can go from A to B to E, and that would be one path.

And that's the only way to get from A to E.

That's what I mean by exactly one path.

Let's say I chose another node like F.

There is also exactly one way to get from the root to F, and that's just a CF, that would be the only path.

If I added some additional connections or edges within my tree, I can get a scenario like this, this would no longer be a binary tree.

For one, we can see that B has three children, but also does not have a unique path between the route in any node.

For example, if I chose a and the note of f, one way to get there is by going ACF.

But another way to get there would be a, b, c, f, right? And so do watch out for all three criteria when you're considering a binary tree.

Awesome.

So let's look at some smaller examples.

And this is where I think some students tend to struggle with their understanding of binary trees.

So if I took out some nodes over here, this would definitely still be a binary tree, right? Just looking at our different rules, right? Let's say the root node A only had one child would still be a binary tree, right? Because the binary tree only demands that we have at most two children, we still have one root, and we still have only one path from root to any node.

Let's say I have the smallest tree that has a node, which would be the singleton tree, this is still considered a binary tree, right has one route.

And there's not really any pass to be had here except the route to itself.

And every node does have at most two children.

Here we have zero children, right? The final edge case we want to think about is what happens when we have no nodes, right? We consider this as the empty tree.

This is a very special case.

And we should consider any empty tree as actually being a binary tree.

That's going to be very useful when we come up with some algorithms later on, right.

So a common edge case off to consider is what happens when we have an empty tree, that's a tree with zero nodes, right? Let's look at another example.

Let's say I had this structure to take a moment look at it, and see if this meets our criteria.

This would not be considered a binary tree.

So we look at your different criteria.

Looking at the first one, it does have at most two children per node, so that's okay.

But we can't identify exactly one root here.

Remember that a root node is a node that has no parent, right? If you look at every node in this picture, every node has exactly one ingoing arrow.

So that means every node has at least one parent, right? So it doesn't meet that criteria.

And furthermore, there is not exactly one path between the root and any node, because we have a cycle within the structure.

So for example, let's say I was starting at a right and I wanted to travel to see, one way to get there would be to go A, B, C, that'd be one path.

But I could also have another path or I just go around twice and go A, B, C, again, there would actually be an infinite number of paths in this scenario.

Because of that, this is definitely not a binary tree.

And there kind of many reasons for that.

If I had a different example, looking at this one, now I need criteria one and two, right, I have at most two children for every node.

But I also still have exactly one root node here I would consider z the root node.

However, there is not one path between the roots in any node and because I have that cycle.

So these rules are really worth remembering, they're really going to help you solve a much more difficult binary tree problems.

And if you remember these three rules, you can identify different problems in a binary tree framework.

In other words, the hardest problems that you'll encounter in your interviews are problems where they don't tell you straight up what data structure you're dealing with, you're just gonna have to notice the pattern.

In other words, what if I gave you some structure like this, take a moment and figure out if this is a binary tree.

If you look closely, this does meet all of the three criteria to be a binary tree.

I can just treat a as the root because it has no parent.

I can treat nodes D and F as the leaves because they have no children.

I just drew this in a pretty interesting way.

Right? If you really range things in a classical binary tree sense would look like this.

More importantly, this has the same relationships as a previous drawing, I just show it in a top down fashion, right? So no matter what do you understand these three rules for a binary tree, right? Because sometimes may not be as explicit as a nice triangular shaped drawing.

Awesome.

So we've talked a lot about the theory of how to, you know, look at and reason through some binary tree definitions.

Let's go ahead and start to talk about how we could represent binary tree programmatically.

In other words, how can we do this in some code? Well, no matter your programming language of choice, I think you're going to represent these as objects.

In other words, every node here is going to be some objects.

So it could be like an instance of a class, the properties only to store within this object would be the current value.

So I need something to store like the A of my current node.

But I also need to refer to some children.

So we'll also need some left and right pointers to the children, right, those are just going to be some properties on that object.

In a classic binary tree is very common to refer to the two children using a left and right direction.

Notice that some nodes here, like the C node, they're only going to have one child, right? c only has a node dot, right? It does not have a left.

So we're gonna have to use some empty value, like null or undefined.

To represent a child that doesn't exist, right? Especially for a node like he, he has no left and also no, right.

So here's what we'll do, let's go ahead and hop into my text editor.

And I'll show you how you could represent a binary tree programmatically.

So transition, here we are in my text editor.

Let's start by creating our node class, right.

So you'll be able to follow along any language that you choose, I'm going to do mine in JavaScript, right.

So I think the best way to present a node is just to use some class.

So hopefully familiar with some classic class syntax, let's create a node class, there's going to be a quick constructor, I think would be valuable to take in the initial value that's going to be stored within the notes, I'll take the ns a constructor argument, I can just set this dot Val to that value, and also need two more properties, one for my left, so I can say this dot left, I'm gonna initialize it to null, that means by default, a node will have no left child the same way.

By default, a node will have no right child, right? So when you use no to represent children that don't exist over here, awesome.

That's all you need to create, you know, a baseline binary tree, right, we're going to use this class a lot during the course to test our algorithms.

So I'm going to create a node and eventually wire up a tree.

Well, I'll just call my constructor few times, I'll create different nodes, I'll just store them to some variable names.

And of course, a new node to create new instance of node, and I'll store some value inside, I'm going to store some characters inside, I'll create a bunch of these different nodes, what we'll want to be sure to do is make sure that you also set their pointers properly.

So I'll give each of these some different values ABC, D, E, also do F.

And then I'll just manually for now set their pointers properly.

So what if I did syntax like this is since I'm in JavaScript, I can easily assign these pointers, I can say, A's left is going to be B.

I can say A's right? is C can also say B's left D.

and then B's right is E.

And maybe Finally I can say C's right is F.

So by doing these assignments, I'm connecting some nodes together, I should end up with a structure like this right? Have a as a root, because nothing points to a it has no parent.

But a has two children of the NC.

And then along with that, B has two children of D and E.

Finally, C just has a right child of f, this is actually the same tree that we looked at a lot during the whiteboard session, right? And that's how you can represent that same tree programmatically, right? So I always think it's valuable to also try to visualize your trees, right? Obviously, we created this tree in a very manual way, probably in the long run will create applications to just maintain and create trees dynamically during some input.

But for now, we'll start by creating all of our trees in this very kind of static way.

Right? And so with that, now that we have an understanding of how to represent a binary tree, let's go head back to the whiteboard.

And I can show us our very first algorithm.

Hey, programmers, Alvin here, right? Now I want to go over this depth first values problem.

So this will be a good review of the depth first traversal algorithm.

So what do you want to do in this problem? Well, what we want to do is take in a binary tree, and in particular, your function is going to take in the root of the binary tree.

And just recall that given the root node of a binary tree, we know that that node is going to have pointers to its left and right children, which may point to other nodes.

However, if let's say a node does not have left or right child, then its point is going to be set to No.

So that's how I represent our binary tree programmatically.

But for now, let's just stick to the visual represent of our tree.

So for a depth first traversal, we could start with the root node of a, what we'll do is we'll just add that to some collection.

And we're going to have to maintain these in a very particular order.

And then from there, according to a depth first traversal, I could go to B.

And here's where we make our really important decision, right, we can either go to C, or D, if I'm doing a depth first traversal, I need to go deeper in the tree before I move laterally.

So that means I go from B to D.

And once I bought them out at D, there's nowhere deeper, I can go from D.

And so now I move laterally to the E node.

And this pattern continues, right? I don't have anything deeper from E.

So now I go to C.

And then from C, I go to f.

So this would be a depth first traversal on this binary tree.

Notice that it goes A, B, D, E, C, F, and again, the really important characteristic is we must go deeper in the tree until we can't anymore and then we can go across the tree.

That being said, How can we actually managed to implement this algorithm.

If you're familiar with depth first, traditionally, then we know that it's going to use a data structure like a stack.

So let's get situated over here.

So we'll trace through that again.

But this time, taking a really close look at how we can use a stack to accomplish that direct order.

And so just recall that a stack is a sequential data structure where we can only add things to the top of the stack and remove things from the top of the stack.

So a really important characteristic is we can't really insert or remove elements from anywhere but the top of the stack.

So when I add things to the stack, I was added to the top like this.

When I remove things, it's also from the top like this.

Alright, so when I begin at this depth first traversal algorithm, I'm going to start with the root node of a.

And by default, I really just take that root node and I just store it on my stack.

So it's the only thing on my stack right now, I'll use these rectangles represent my different stack frames.

And really in my program, that would just mean storing the actual instance of node or some pointer to it.

Cool.

And then from there, I actually begin my main algorithm.

So the main flow of a depth first traversal, we'll check if the stack is empty.

Right now the stack is not empty, because I have at least one element.

And so what I do is I start by removing or popping the top element of my stack.

So I'm gonna remove the A, and I'll label that as my current node being explored.

And when something leaves the stack, then I can consider it being visited right now.

So I need to list out my values, because that's the whole point of this problem, right? So by now I've just visited the a node.

At this point, I can look at that nodes children now.

So I look at the a node in the tree, and I see that it has a B child on its left and a C child on its right.

And from there, I push or add those two children to my stack.

So I'm going to put c first, and I put B afterwards.

And notice if I push my right child first, followed by my left child, that makes it such that my left child is at the top of my stack, which means that I would hit them next.

And that actually ends on my first iteration of this depth first traversal.

And now I asked that same question is my stack empty, it's not.

So I removed the top of my stack, I'll call it B, my current, which means I could print it out or insert it into my values list.

Nice.

From there, I consider B's children, B has two children.

So I add them both, I push E, followed by pushing D.

That ends that iteration.

Now something interesting happens, my stack is still not empty.

So I know I removed the top, so I call D, my current, I add D to my list of values.

But if I look at these children, it actually has no children, right, and so there's nothing to add to the stack from here.

And so technically, I finished this iteration.

And now I still have stuff on my stack.

So now I pop he off the top of my stack.

Same thing as before, right, I add to my values, he has no children.

So I'm done with that iteration.

Finally FC, I removed C from the stack, and I printed out in my values.

And then at this point, I see that the C node only has one child, so I'm just going to push the children that exists so I would push the F node onto my stack.

And that's a really important thing to remember when it comes to implementing your depth first traversal you're going to have to check if your children exist before you add them to your stack.

And now on the final final iteration, we have the F node we remove it from the stack, we add it to our list of values f has no children.

And so I finish this iteration and now my stack is empty and I will just exit right once the stack is empty.

I know that I must have traveled through the entire binary tree.

So there we have it and we do get the correct output over here.

So just by using a stack and just obeying the rules of the stack, that is we got pushed to the top and removed from the top we will get the correct order.

important thing to remember is you should add your values into your like values list whenever something leaves the stack.

That being said, What can we say about the time and space complexity of this algorithm? Well, it's actually pretty straightforward.

Let's say we define n as the number of nodes in this binary tree, then we can say that the time complexity of this is O of n.

And why do I say that? Well, we're just going to add that every node eventually to our stack.

And that nodes also going to leave the stack exactly once.

So it's not like we're double visiting any of the nodes.

So I'm guaranteed to just run in O of n steps.

In a similar way, we can see that the space complexity is O of n, the only thing we stored was really the stack, which is a linear data structure.

And we know that we're not going to put ever more than n things on the stack.

So overall, we have a linear time and space solution for this depth first traversal problem.

All right, I think we have a good understanding about the approach for a depth first traversal.

Now let's go ahead to the walkthrough video.

And we'll implement this one in a few ways together.

Hey, programmers, Alvin here, right.

And I want to go over a JavaScript solution for this depth first values problem.

And so we're going to do here is really just implement that same strategy that we traced through in the approach video, pretty much to the tee.

And we'll start with the iterative version.

And that means of course, we will solve this one in two different ways, right, we're gonna solve it iteratively first, and afterwards, we'll go ahead and solve it recursively.

Alright, so let's jump right in over here.

Like we said, in the approach video, we know that the iterative version really relies on us creating a stack.

And for most of your programming languages, you can just go ahead and use your like array data structure for that.

So I'm going to use just a plain old JavaScript array, I'll go ahead and name this one stack.

And we can just use an array to represent a stack as long as we stick to two particular methods, right, I'm going to use array push, which adds to the end of an array, and also array pop, which removes from the end of the array as well.

So I'm going to consider the end of my array to represent the top of my stack.

Cool, we'll go ahead and do is initialize the stack with the root node on top of it.

Nice, then I can have my main loop for the algorithm.

So we know that we need to keep running the algorithm while there's stuff on our stack.

So I can just check while stack dot length is greater than zero.

So while I have at least one element on my stack, there is some work to be done here.

And that will step through a single iteration of this algorithm, we know that we start interation by just removing the top of our stack, in other words, stack dot pop in JavaScript, that will also return us the element that we just removed.

So I'll call that my current const current.

And that is going to be an instance of nodes, it's going to be one of these objects.

Cool.

So now that I remove this element from the top of my stack, let's say for now, I just I don't know, print it out, maybe we'll kind of debug this one as we go.

So console dot log, current dot Val, because I know that every instance of node has a dot Val prop on the inside.

And then from there, I need to add this nodes children.

So you might go ahead and guess that to do that, we could just do stacked up push, I'm going to push the left child, one out here, so node or current dot left, followed by the right child.

But we also need to make sure that these children exist, right? Look at the prompt.

There could be instances, for example, like this C node over here, this C node only has a right child, but has no left child, right.

So what I don't want to do is push C's left, because that'd be pushing no onto my stack, which would give me an error later on.

Right? So I want to only push the children if they exist.

And I need to individually check if the left exists and push it and also if the right exists and push it, I'm just going to add some guard statements for both of these.

So we'll go ahead and insert will say, all right, if the current has a left and right side, current dot left, called justice for the right hand side, cool, maybe we can inline this, if you prefer.

Alright, so I'm going to only push the children if they exist.

And that should actually be the heart of our depth first algorithm.

So we're not putting our values inside of an array like the problem asks, but we should at least be able to see the correct order of printing here, because I'm going to print a nodes value as soon as it is removed from my stack.

So I'll go ahead and actually maybe bring in maybe one literal test case, so I could just steal this little stub over here.

And this will just print out the values.

Right, so I'll test this I can hit Run, if I hit Run, it's just going to execute this file just like a script.

So it's not going to run any automatic test cases, just going to run my file as is.

So if you want to test it in this way, kind of in a manual way, you're gonna have to be sure to call your function.

I do have a console dot log on the inside.

So I'll just run Run this manually.

And when I do that should see some output here looks like node is not defined because I forgot to bring in my class definition.

So I'll do that.

give that a go.

Alright, so looking at our output, we didn't get our exact depth first traversal, like we expected, right? I got ACF, B, D, if you take a look at what we really printed out, we technically did print out a depth first print, but we favored the right hand side.

So we did a, c, f, and then B, E, D.

So let's say we really wanted the left to right version of this, and all you have to do is flip the order that you push the children, right, it should be clear by looking at these two lines, right? When I add my children looks like I push the left child, and then the right child.

If you push the left child first, and then you push the right child afterwards, that means that the right child's going to be on top for the next iteration.

So if you do it like this, this will favor the right hand side and travel through it first.

But if you did it like this, now you'd be actually iterating to the left branch first, toward the right.

So with that small change, let's just see what our print is.

And there we have a nice AB de ECF.

However, in this problem, they want us to actually return those values in an array.

So I can kind of get rid of this little Manual Test over here, I don't need this class definition anymore.

And now instead, I'll just gather up all of my values in some results array.

So I'll say, maybe result over here starts as an empty array.

And then as I pop elements from the top of my stack, instead of logging them, I'll go ahead and do result dot push, and I'll push that value into the result array.

Once I'm done with this while loop, that means my entire tree has been explored.

which case I can return, make sure I spell it right, return my results.

Cool.

So this should be a nice solution, it's actually run the test cases on this.

give that a go.

So it looks like we're doing pretty good.

But for this very last example, looks like we're getting can't read property Val of na, and that's running test case 04.

So if you actually go into the prompt, those test cases are actually laid out explicitly over here.

So I want to go to zero for now let's look at the zero for test case.

They go ahead and they pass my function, no, right kind of representing like an empty tree or an empty node.

And we can kind of trace it what happens here for our code.

Let's say that root was null.

That means when we initialize our stack, our stack literally contains like a null value.

So it's not even an instance of note just now.

So that means when I entered this while we're going to check, you know, Do I have anything in my stack, and I do because my stack length is one.

And then when I pop, the top element of my stack current is going to be no, then on this line 14 it says null dot Val.

And that's actually where our code explodes, right on line 14, right? You can't reference property Val, of null.

And so to handle this scenario, we want to make sure that we actually never allow anything No, to enter the stack.

It's kind of why we had this guard over here.

mentioned also be true for even the top level route, in case they give us the empty tree.

kind of seems like a corny, you know edge case.

But this is a pretty common one, when you actually go into your interviews, right? What happens if you have an empty input.

And so I'll just guard that explicitly, I'll go ahead and check, hey, if my route, so if my entire tree is empty.

So if route equals null, then what I'll do is just return an empty array, right? Because that means there are no values inside of it.

And that actually is the expected answer, according to this, right should return an empty array.

So let's give it a go now should be pretty good.

Nice.

And there, we have our nice iterative solution for this depth first values problem.

Alright, so here's what we'll do.

That was one solution.

Let me show you another way.

let's implement this.

And that would be our recursive flavor.

So I'll just kind of redefine it down below.

And I actually recommend practicing both versions, because they're going to serve as like the basis for which you solve a lot of different tree problems.

And so when I think about the recursive version, like all of our recursive code, I must think about the simplest case of my input, and that will act as my base case, right? So in the case of a binary tree, the simplest tree you can be given is going to be the empty tree or just a no root, right? So it's not even going to be about a node that's single node right inside of a binary tree.

It's going to be about an empty tree, right, a tree with zero nodes.

I'm going to check if my route is no, and I have an empty tree.

And I think about this base case, as if it's its own input, because it really is right and so if someone They asked me to give them back in array of all the values in the empty tree, it's still the case that this must be an empty array, right? Because there are no values, there's even any nodes and the empty tree.

And then from there, I can generate my actual recursive call, right.

And I know what I call my stuff recursively.

That means I have to reference a function and again, go ahead and invoke it.

And I'm going to call upon root dot left, as well as root dot, right? So this would, this call over here would give me back an array containing all of the values in the left subtree.

And this will give me an array of all the values in the right subtree.

And so let's say I see these into their own variables respectively, you don't have to do this part.

But I'm kind of a fan of it, especially if it's the first time implementing this.

So I'll call this my left values.

I'll call this one my right values.

And here's how I'm able to kind of quickly create recursive codes all about taking when I call is a recursive leap of faith here.

So let's say we're stepping through test 00.

And so this is our tree visual, right? So we know that our root is going to be a node.

So when I actually make this top level call, this base case does not fire.

And so I make my recursive calls, right? I know when I do depth first value, or values, rather, let me fix that depth first values of root dot left, that means I'm going to be passing in the B node, right, and here's how I have to actually pretend my code behaves, I'm just going to get back the correct result from this call, right? So if I passed in the B node into this call, what I expect back is the full array representing the depth first traversal of that subtree, starting at B, right.

So if I got correct data over here, what it would look like is just B, D, and E.

That would actually be the full depth first traversal, from this subtree, right.

And I'm kind of doing that just mentally, or I know the expectation for this algorithm, it's going to be a similar story for my right call, right? If I'm at a So A is still my route, and I passed in my right child See, to this call, what I expect back is just an array of CF, which would be the depth first traversal of that left subtree.

And now that I have, you know, my left subtree values and my right subtree values, I have to think about how to combine it all together, right? How do I work myself into that output by combining both of the results from my children, right, what I need to do is really just take myself put it in the array, followed by my left children, followed by my right children.

So I can do some nice JavaScript syntax for that whenever returning the right when I throw myself in there, so I'm going to throw in a root dot Val, that's myself.

So that'd be like the a node that I just take all the values in my left result, put them in here and just use the spread operator to unpack that array.

And I'll do the same thing for the right values of CF, right.

So dot dot, dot, spread out right values just so I return a single array, and this pattern itself does match this output, right, kind of taking the leap of faith and assuming correctness from these recursive calls over here, right, I have a, and I plug in substitute B, D, E, and then for the right, I have CF.

And even before we run this, I'm not going to, you know, assume too much JavaScript knowledge.

So maybe you're kind of new to this spread operator.

So in general, super quick aside over here, let's say had an array of some stuff.

So I'll say, peeps there and some people over here.

So we'll throw in fleabay, we'll throw in Jason, throw in Raj, throw in heavy.

And what I can do is whenever I have an array, I can just use a spread operator to kind of unpack that array.

So for example, I can say const will say new peeps.

And I'll create a new literal array.

So whenever I say square brackets, it gives me a new array literal.

And what I'll do is, I don't know, put an element at the front, we'll call it Alvin.

That'll spread out the elements of peeps, right? So just imagine I took all of the elements here and just remove the brackets.

That way I don't add any initial nesting.

And then at the end, I don't know I can add someone else.

Like, right? Well, console dot log, what new peeps looks like so I'm not gonna run the test cases, we're just gonna run this file as a script, just so we can review this spreads index.

So if I give that a go, we kind of make this bigger.

Notice that I have correctly spread things out right? Have Alvin at the front, and I have all of the things from peeps in the middle, right, followed by Brian at the end.

So you can do this.

You can also use like the concat method on arrays.

You're probably going to see me use this spread syntax a lot because I'm kind of a fan, right.

But with that in mind, let's go ahead and actually test this code.

So we'll run all the test cases.

Nice.

And this is another working solution for our depth first values.

And it should be pretty natural that we can solve this problem also recursively.

So I know that the iterative solution for this depth first traversal requires a stack data structure.

And I know whenever I write recursive code, under the hood, your programming language is actually going to track all those recursive calls, using the call stack, right? That call stack behavior gives you the same type of ordering, which is really convenient.

Cool.

All right.

So before I send you off on the next problem, I want you to actually practice both solutions for this depth first values code, it's going to be very necessary to actually master some later concepts that are coming right up.

So do spend some time on this practice makes perfect, right, and I'll catch you in the next one.

Hey, programmers, Alan here, right? Now I want to go over this breadth first values problem.

So it's really just going to be a little variation off of the depth first one we just did, of course, but it's really important that moving forward for all of our tree algorithms and other data structures, that we have both versions down pat.

So in this problem, we're going to take in a binary tree, once again, very classic binary tree structure, this time, I want to return an array or a list of all the values according to a breadth first traversal order.

So a breadth first traversal starts with the root node of a, so that's nothing new.

And then from there, I could go to B.

So right now I have my a node, and also my B node.

And here is where we diverged from our previous problem in a breadth first traversal.

And breadth just refers to like the width of something I travel across before I go deeper.

So in our breadth first traversal, I'm gonna move to C and not D for now.

So I add my C node c value to my list.

And then from here, once I finished this entire level, and there's nowhere to go across the tree anymore, now I could go downward to the next level.

Now I have D, and then E, and then F.

So they're really important distinction here is the breadth first traversal starts with ABC, whereas the depth first traversal would have started A, B, D.

That's a really, really important distinction.

And so how can we go about implementing the breadth first version of this? Well recall that the depth first used a stack data structure, well is the case that the breadth first is now going to use the queue data structure, really just the partnering version of that structure.

And so let's kind of step through that in a more programmatic way.

So I'm going to use and track my queue.

And just recall that a queue has no sense of direction to have the back of my queue and the front of my queue, things enter the back of the queue, and they leave the front of the queue.

Right.

And so no one gets a skip line either.

So this gives me a nice fair ordering, think of a queue as just like waiting in line at checkout at a grocery store or something.

So how do I begin my algorithm, I'm going to start by initializing my queue with the root node.

So I'm just gonna start with a on my queue.

And then from here, now I can begin my main algorithm.

So my main algorithm should check on every iteration is my queue empty, right now it's not because I have at least one element.

And so I remove the front element of my queue.

And so we know that a would be removed, and we label it as our current.

A node being explored when something leaves the queue and is marked as our current will say that now it's being visited.

So I would add a to the running list of my values.

Then from here, I need to look at his children.

He has two children B and C, I need to go ahead and add them into my queue.

And so let's say I added B into the queue first, followed by C.

Notice that C must enter behind B, right.

And now I finished this iteration.

At this point, I have the next iteration of my algorithm, I take the front element of my queue, and it leaves, right So b is now my current, I add B to my running list, then I look at B's children of D, I push D followed by he behind it.

At this point, I have another iteration to do right.

And it's so on so forth.

From here, see leaves the front of my queue, I add it to my list of values, and I look at sees children see only has one child.

So for that child that exists, I go ahead and add them to the back of my queue.

And it's really important that I added to the back right at this point had my next iteration.

At this point I continue, my queue is still not empty, so I still have some stuff to remove.

So D leaves in front of my queue, I add it to my list of values.

Since D has no children, there's nothing to add here.

next iteration, he leaves the front of my queue, I added to my list of values, no children, so I don't need to add anything.

And finally f leaves the front of my queue, I just add it to my list of values and again, f has no children.

So by now my queue is empty, which must mean that, hey, I must have completed the algorithm, right? There are no more nodes to explored, I explored and added every single node to my list of values.

All right, and this output actually looks correct, right, I get abcdef, just like we say.

But what about the complexity of this algorithm.

So let's take a closer look over here.

Well, we know from the get go, that n is going to be the number of nodes in this binary tree.

So that will be the term for our sides of input.

And we can say that the time complexity is simply just O of n, roughly, because we know when it comes to visiting these nodes, and you know, using our loop, we're going to add every node to the queue once, which also means that that node is going to leave the queue also wants, so it's not like we're double adding a node to the queue, right, we're not going to double visit any of these.

In a similar way, the space complexity is going to be O of n at most, because, you know, we're just going to add at most to all of the nodes into our queue.

And in general, it's probably going to be less than Oh, event space in terms of how much space we use in our queue.

An important thing I'll just mention right now that in regards to the time complexity of this one, here, we're going to say that the time complexity is O of n.

And that's if we can assume that adding something now to the queue runs in constant time.

And removing something from the queue occurs in constant time.

So depending on how you implement this, if you use actually, a built in an efficient queue data structure, you will get this O of n time complexity for our breadth first.

But if you use a less optimal, like data structure, maybe not a perfect queue, then you might have an actual worse complexity.

So again, this time complexity of O of n assumes that we have a maximally efficient queue that has o of one add and remove operations.

With that being said, I feel pretty good about coding this one up.

I'll catch you in the walkthrough video, and I'll show you a few different ways that's implement this one.

Hey, programmers, Alvin here, right now I want to walk through the JavaScript solution for this breadth first values function.

So hopefully, you just finished the depth first version, in which case, this one should be pretty much a cakewalk.

But of course, we will still go through the motions of it, because it's going to be useful to solve much harder problems later on, as you always hear me say, Alright, so to tackle this one, we'll start with our queue data structure, right? So nothing fancy in JavaScript, what I would do is just use an array and just stick to using very specific methods, right? So I'm going to create an array, I'll call it my cube.

And we're going to initialize that queue with the route on it by default.

And we'll also guard against upfront is imagine they gave us an empty tree to begin with.

So in other words, the initial route is no, which case it would be like this test 04.

And they just want us to return an empty array.

So I'm going to guard for that explicitly.

So I'll check Hey, is my route No.

And if it is, just go ahead and return an empty array like that.

Nice.

Then from here, I need to start in my main loop from algorithm.

So I iterate a while my queue is not empty, just like we spoke about in the approach video, right? So while q dot length is greater than zero, then keep on going.

Now I begin a single iteration of this algorithm by just removing the front of my queue, right? So it's really up to you which methods you use, you just need to make sure you remove from one end and add to the opposite end.

So for me, I'm going to treat index zero as if it's the front of my array, I'm going to treat the last index as if it's the back of my array, right? So if I want to remove the front and say, array dot shift, or for me right now, Q dot shift, that removes the front also returns to me, that element, so I'll call that my current note, x.

And then from here, I need to add this node children into my queue.

And that'll give me my main flow for this breadth first traversal.

Right.

So I'm going to go ahead and check, hey, if my left child exists, so if, let's say current dot left, that is not know, then what I should do is go ahead and push that into my queue.

So I'll say q dot push my current dot left, and it's just going to be symmetric for the right hand side, of course.

So if the right exists, then push the right into the queue.

Just like that.

Awesome.

And so that looks pretty good.

And then from there, I actually want to store the nodes I visit in an array for the final return just like the problem asks, so nothing too fancy.

I really want to insert some code over here about and so I'll create a result array, I'll call it values, sort of empty whenever something leaves the queue.

I'll just take that and push it into my values.

So I say values dot push.

I'll push that current Val into my queue.

And do note that, what you can't do is just take like the queue and treat it like your final return value, it must be a totally separate thing, right, I use the queue just for the sake of traveling through in a breadth first order.

And the order that you visit is actually derived from the order in which things lead the queue.

So that's why I'm doing it over here, right, as soon as something leaves a queue, that's what I considered visited.

So I added to my values list.

Nice.

And after my while it's done running, I'll go ahead and return my entire values array.

So let's give this a test.

I'm gonna run all the test cases, what we get, have a few test cases to pass.

And there we have it.

Here's a nice iterative solution for our breadth first traversal.

Just something I want to mention, by the way, let's look at the prompt.

So looking at, I don't know, like the very first example, in this kind of rendition of breadth first, what they asked us to do is really give us a breadth first traversal, that moves from left to right, so notice it goes A, B, C in terms of the resulting output, and not a CB, right, those would both be technically correct, start to a breath first.

And then you can kind of choose depending on what problem you're solving, whether you want to go left to right or right to left.

For me, because I push the left followed by the right, that means the left is going to leave the queue first, right, because remember, the queue is just like a line and checkout.

So if someone enters first, that is the left enters first, they going to be served before the right go.

And you can just flip these around.

And I'll give you the right to left universal goal.

So depending on what your problem warrants, you can always manipulate that code a little bit.

And this is actually probably like the only solution you can have.

You know, maybe aside from just some superficial changes to like the code style, this is going to be your go to and only go to solution for a breadth first traversal on a binary tree, right? A common mistake I see people try to do a lot is there is not really a straightforward way to implement a breadth first traversal recursively.

And that should make some sense, because a breadth first traversal needs a queue order right needs to use a queue.

If you write any recursive code, you know, under the hood, it's using a stack.

And so that stack versus queue is really just going to fight against you.

And you're going to have a really tough time trying to implement the correct ordering.

So always just writes the iterative version for your breadth first traversal.

Alright, so I recommend before you hop into the next video, make sure you're able to write this code on your own, because we are going to level up difficulty a little bit, but I'll catch you in the next one.

Hey programmers, Alvin here, right now I want to walk through the approach for this tree includes problem.

So the premise of this problem is I'm going to give you a binary tree, and also a target value to look for.

I just want you to tell me True or false? Is that target value found within the binary tree? So for this particular example input, the answer is obviously true or Yes, right, you could definitely find e within this binary tree for give you another target value like j, you would respond with false, right? Because that value j is nowhere to be found within the binary tree.

And really what I'm asking you to do here is we're stepping through the canonical like breadth first search and depth first search problems.

And I think I'll walk through both approaches for you right now.

So let's say I was testing or I wanted to trace through rather of the input where target was IE, how can I go about attacking this one, right? We know that in most of these problems, when they give you a binary tree as input, they're only going to give you really the root node.

But that being said, if you have access to the root node, then you know you have access to all nodes that comprise of the tree, right.

So what I can do is just perform any of my traversal algorithms.

So maybe to get going.

Now let's just do either the breadth first search or the depth first search iterative style.

So I think for this trace, I'll stick to the breadth first version, which means we're going to use a queue, right? So as we trace through this, I'm thinking about this one iteratively.

Right now, hopefully you recall from our previous problems when it comes to your breadth first traversal, you start with your root node on your queue.

And when something leaves the queue, you mark it as your current right.

And here's where I work in the new logic for this, this particular problem.

When something leaves the front of my queue, I'm going to check Hey, is that current value the same as my target value, so is a the same as E.

It's not.

So I have not found the thing I'm looking for, right? And what I can do is now consider his children.

Right? So I look at his children.

They both exist, I add them to the queue.

So I'd be to my queue that I add see to my queue.

And now I'm on to my next iteration right? The front end element B leaves a queue, and I have to check, hey, is B, my target, it's not right my target t.

So I keep running, I look at B's children.

So I take that D and added it, I take the E and also add it.

And this process just continues, see leaves front of my queue is see my target, it's not.

So keep going, I would add C's children to my queue.

So I just add F to my queue.

And this process continues.

And so d leaves the front of my queue I check is d my target, it's not, and D has no children to add, right? Recall that in our breadth first traversal, I only add the children if they exist, because I don't want to add any, like null pointers into my queue.

And so I just continue my algorithm, right, I still have stuff in my queue to check.

And finally, when he leaves the front of my queue, I check Is he my target.

And indeed it is right at this point, I've just confirmed that he is found inside of my binary tree.

So what I can do is just end my algorithm by like returning the true value, right? There's no point of actually looking through the rest of the tree, because I already figured out that, hey, my target value is indeed within the tree.

Right? One thing you might notice is, it looks like I only checked for IE once it left the front of my queue, and not when it was initially added to my queue.

Technically, you could have returned early when you added it to the queue.

But we'll kind of see when I walked through the full code for this one, it would end up with cleaner code if you just checked for your target value when something leaves your queue.

So we'll see that when we go through the code.

It's just a small implementation detail.

That being said, for this iterative breadth first strategy, what can we say about the complexity? Well, if we define n as the number of nodes, then we know that the time complexity is just O of n, it's really just a classic breadth first traversal.

So nodes are going to enter the queue once and leave the queue once that's open, right.

And again, that's considering if we use a efficient queue, right, where our queue add and remove operations run an O of one constant time.

So we have linear time.

And for the space complexity, it's also going to be O of n linear, right? Because we're just going to store our nodes within the queue.

And so we just looked at the approach for a nice iterative breadth first solution, not to this problem, but I want to show you the depth first version, and the depth first version, that would be recursive, right? So obviously, you could write the iterative debt per solution, which case you just use basically the same code we just spoke about, but just use a stack instead of the queue.

But let's try to solve this one.

recursively, right.

And the reason I think it's really important to expose yourself to recursion like this is, as we move to more complex topics, you're going to find this style of recursion.

Very, very useful, right? So we have the same input, right? Let's say My target is E, and I have the same binary tree.

And now I want to check recursively is E within this tree? And so how do we start attacking this? Well, we're going to need to think about our base cases, right? So we're gonna have really two types of base cases, we'll have like the affirmative base case, meaning Hey, we found a match.

And so whenever I counter a node, whose value is he, or whose value matches my target, then I'm gonna have that node or that recursive call, return true, right? So that's my, like, affirmative base case.

So I'm just gonna plug that return value in visually in my tree, you know that this II nodes gonna return true.

And now I'll think about my negatory base case, right? Four times where I call upon an empty node, or the null node, I should return false.

And recall from our previous lectures, we said that we're going to sometimes represent explicitly our null nodes.

So I'm going to fill those in, for example, the C node in my picture would have a left child that is null.

So I'll kind of draw that one explicitly.

And I know that a node like that is going to return false.

Because logically, I shouldn't be able to think about all of my recursive calls as if they're their own subproblems.

Right? So if someone asked me, Hey, can you find this E value within an empty tree? Right? a null node represents an empty tree? The answer to be no, I can't find the value in an empty tree, because there's nothing there.

And so from there, I'm also going to draw explicitly all of those similar null nodes, null pointers, right? So it looks something like this.

Notice that from the E node, I don't need to give it a null left and right, because I already said that that node is going to return true, right? So that's why I draw my tree like this.

And I have all of those false return values.

Cool.

So we just labeled all of the base cases, right as the leaves of our tree, and recall that a leaf is just a node with with no children, right? And from here, how do I actually combine all of these Boolean values to get the true at the very top, I know for my top level color, that is at the a node, or the a recursive call, I need to get back that value of true, right? And the logic we should use is really just to the logical OR so how does this one work.

So let's start evaluating our return values and combining them at the parent.

So this should be somewhat of a similar pattern to like the tree sum problem I showed you.

And so what you could do is focus on this D node over here, this node has values ready on its left and right has two falses.

And when it actually gets those falses returned to it, it just should do the logical OR so it's doing false or false, which evaluates to false, right? Which means that hey, in this subtree rooted in D, I cannot find the value, which makes sense.

That's why it's false.

I'll continue this process.

If I look at this B node, now this B node has values ready on its left and right.

And they're going to bubble up a little bit.

And I take the order of them so I do false or true, which evaluates to true.

And this process continues everywhere in the tree, right? So at this f node, false or false, is me false.

At the C node, false or false gives me false.

Finally, at the top level root of A, I do true or false, give me back a final true, which is indeed the correct answer.

So hopefully, you realize how similar the solution is to our previous tree some problem right in the tree, some problem, I combined my left and right, child return values by doing the arithmetic addition.

But this time around, I just need to use the Boolean operation of or right, so by just adjusting the type to Boolean, we have a very, very elegant solution that shout out George Boole.

And so with that, I think let's go ahead and implement this one in some code, and I'll show you it using the interest of flavor or using maybe a breath for us, and also the recursive version, which is my personal favorite, using this recursive tree structure.

Hey, programmers, welcome back.

Alright, and I want to go over a JavaScript solution for this tree includes problem, right? Well solve this both depth first, and also breadth first.

And I think we'll start with the iterative breadth first version.

And so this is really just going to be implementation of the classic breadth first search algorithm, I'm just gonna lay down my classic a breadth first traversal code, and then just add some conditional logic afterwards, right? So you should be familiar with it by now.

But for my breadth first traversal, I'm going to use a cube.

So I'll say const, q equals an empty array, are really an array with the route thrown on the inside.

And from there, I have my main algorithm, right, so I loop while my queue is not empty.

So while queue length is bigger than zero, and keep on going.

And on a single iteration of this traversal, what I do is Q dot shift, so remove from the front of my queue, the front of my array, remove the first element.

And I'll save that into a variable called current.

So that will be just an instance of node.

And for now all why don't I just build up my solution slowly, I'll just, I don't know, console dot log, what current dot Val is.

But once I consider this node, what I want to do is really add its children into my queue only if they exist, though, right? So in general, I'm going to write like q dot push, I'm going to add to the back of my queue, so I get a nice cue order, push the left child, so current left, likewise, the right child.

But imagine that I have an asymmetric node or just a leaf node, right? Something like C would only have a right child, so it's left would be no.

So if current is see, then I'd be pushing No, into my queue as the left, which is no good, right.

And so I need to guard here and only push the children if they exist.

So something like this, hey, if the current has that, corresponding left and right, then I can go ahead and push it.

So this is looking pretty good.

And that should actually be the main traversal part of the code.

So I'll just test this manually.

So very manually, so maybe just this call, so I'm not gonna return Booleans yet.

We'll build up to that.

But I should at least see my values printed.

If I kind of run this manual test case, I'll bring in my node class, I should see the values printed in a correct breadth first orders, that means A, B, C, D, E, F, recall that breadth first traversal travels across our tree before going lower, so I must finish a level before traveling to the next level.

So let's just run this manually as a script.

See what we get here.

A, B, C, D, E, F, nice, so I'm getting the right order of traversal.

And now I can work in I think, the conditional logic because they want us to return Booleans over here.

So pretty straightforward stuff.

We'll go ahead and check once something leaves the queue.

I can check If the current nodes value is equal to my target, then I've found the thing I'm looking for.

So just return true, right, you're done, you don't need to travel through the rest of the tree because you can return true.

But on the flip side, if my value that I'm currently at is not the target value, that I must continue looking through the rest of the tree, right.

So if I finished the entire while loop, that means I've traveled through the entire tree.

And I never found the thing I'm looking for, I should return false.

So I need a late return false over here are really common mistake people tend to make is, what you don't want to do is just do like, else return false here.

So this is going to be wrong.

Right? Because this would only check like the very first notice normally check the root, and then check if the root is not equal to the value.

If it's not, you just return false, which is not really useful, because it could be somewhere else in the tree.

So you're gonna need that late return false pattern over here.

But with that, I think we're going to pass some of the test cases, as well run the test cases by hitting that test button.

And there's probably one scenario we did not for C.

Cool, and there it is, right? Can I read property value? No, we're failing tests.

055, look at that spec.

Test five gives us a null node as a root, right? So just the empty tree, you cannot find the B character inside of the empty tree.

So return looks like false over here.

And so I can just handle that one explicitly.

I'll go ahead and check at the top.

If my route is no, right, if that's the case, then just return false.

I can't possibly find any target in an empty tree.

Right? The reason our code was failing before is if root is null, then I initialize my queue with no.

And when that thing is pop, and that null is popped, or rather shifted from the queue in the first iteration, then I check null dot Val, which is an illegal JavaScript operation.

So I'll run all these test cases now.

Nice.

And there, we have our breadth first solution for this tree includes problem.

All right, now let's work on the recursive depth first version of this, it's actually my personal favorite, because it utilizes a pattern that I think is quite elegant, and one I use a lot for much more difficult problems.

So like we said, in the approach video, if you haven't watched the approach, you definitely want to check it out.

For this recursive version, right? what I should do is check Hey, if my root is null, if I have the empty tree, basically, then just return false, right, because I can't possibly find my target and empty tree, right, that's just a given.

And from there, I know I'm going to have the general shape of some just depth first traversal code, which means you call the same function because it's recursive.

That's what recursive means.

And you pass along your route dot left and a separate call your route, right.

And when I should be sure to do is Don't forget to pass in your target, write the target that you're looking for, it never changes.

And I know that these two these two calls are going to give me back boolean data.

And I know that the Boolean I get back from like this call would represent whether or not I found the target and that subtree, right.

So this gives me the result of if I found it in the left subtree.

Or the result if I found it in the right subtree.

And I can just do the logical OR on both of these, right.

So if I find it in either subtree then return true.

So I could just write in line return true over here, right? So let's say it's in my right subtree, then this left hand side invites to false.

And this is true, in which case, this entire thing evaluates to true.

And let's say in a bad scenario, let's say it's not found in either subtree.

So this evaluates to false.

this right hand side also evaluates to false, false or false gives me false.

However, one thing I need to be sure to add is also an additional base case, after I check if my route is no, what I want to do is then also check, hey, maybe this route I'm currently at, maybe it actually has the target, right? So if route value is equal to the target, then you're also done, except you can return true.

Cool, and that was very reminiscent of our approach video.

So let's give this a shot.

You should be able to pass nice, and I love how clean this code is.

I will admit, you know, it's pretty tricky.

If you're not a fan of writing recursion, in which case, I'll totally convinced you into being a fan of recursion.

But notice how kind of clean this code is really leverages recursion.

One very important thing I want to bring up is it's really keen that I put this base case on line 26 after the null check, right? So let's say I flipped the order of these.

Let's say you did this.

I believe that would not work out always because it assumes that you even have a route Alright, so I'm feeling a test 00.

But in general, if you look at this code, let's say that route was no, right? You're gonna start by checking null dot Val, and I'll throw an error, right? Can I read property valve? No.

So you want to actually always lead with your base case that checks if your root is null, right? Because that should guard really the entirety of our code.

So this is actually the code you want.

Over here.

Alright, programmers.

So that's all I got for this tree includes solution, I want you to practice both versions, and I'll catch you in the next one.

Hey, programmers, Alvin here, right? Now I want to go over the approach for this tree sum problem.

And so in this problem, I want to take in a binary tree, just like we've been doing as of late, this time, the values within the nodes of this binary tree are going to be numbers, right, what I want you to do is compute the total sum of all the values in this tree.

So for this example, we should end up with 25.

And so hopefully, you're kind of gathering how to attack this problem, especially given you know, the algorithms I've been showing you as of late.

So if you've been studying our problems, and are there hopefully, you know, a straightforward solution to solve this one, we could of course, just use any type of traversal algorithm.

So we can use either a breadth first or a depth first traversal.

And we can just add all these values into a running sum.

And of course, we probably initialize that sum to zero, right? So the iterative breadth first or depth first solution, I think, is very straightforward, right.

And I'm not going to really step through that approach with you over here, I think you have that one down pat, especially if you've done the previous two problems.

But what I will show you here is actually how to solve this one recursively, which would be a type of depth first traversal, because we know that hey, depth first traversal relies on a stack.

And if you do something recursive, it is utilizing the underlying call stack.

So I will get a similar type of ordering.

And so when we trace through this type of solution, this recursive solution for this tree, some problem we're going to do is try to be very explicit, I think this is really helpful, especially if you struggle with recursion, right? So given this binary tree, I know that for particular nodes of my tree, like the four node, it does not have a left child, right.

And I know like programmatically, what that means is like that nodes dot left pointer points to like, no, or it's a null pointer.

And so I'm just going to draw that explicitly, sort of like this.

Again, they'll just help us really understand how our recursive code performs on this type of input.

And so if I know that I can put like an unknown load to the left of four, then it could be the case that other nodes like the leaves have to in one, they also have both left and right children that are also know.

So if I drew all of my null pointers explicitly, it would look something like this.

Cool.

And this is really something that helped me really get comfortable with recursive problems, especially those on binary trees.

And what we're doing now is, we know that when it comes to solving any problem recursively, it's about writing a base case, that is like the simplest version of our input.

And here, I'm going to argue that our base case needs to be about the null node, right? The null node basically represents no node at all, or represents the empty tree in a sense.

In other words, if someone asked me to calculate the sum of a null node or the sum of an empty tree, then to me that some would just be zero, to write elegant recursive code to try to think about your base case as a problem in itself, right? So if someone gave me an empty tree, that is a null node, I would return the total sum of zero.

And what that means is I know that all of these null nodes, they would return zero as their computed sums.

Nice.

And then from there, how can I use this information to actually build up my main solution? Right? So let's go ahead and target this for node to the left.

And what I have to do is figure out Hey, know what is this subtrees total sun, and I can compute that given the values to the left and right.

In other words, if I return those two null values returns to zero.

Now I just have to do zero plus four plus zero, which just equates to four, right? And that is actually correct in itself, right? So what green number above a node represents the total sum of that subtree.

And so it is a case that, hey, the total sum of that four node is just four.

And I would do something similar for this node over here, right? When these base cases return to their color or return to their parent, I just have to add my left and right child together along with myself.

So zero plus two plus zero, gives me to not do that same thing.

For this note 11 We're here.

And now things get interesting, right? It's a calculate the total sum rooted at this 11 subtree, I would just return these values to the top.

And now I do four plus 11 plus two, which gives me an answer of 17.

And if you do a quick spot check, right, this 17 does represent the total sum, just in this subtree, right, and we'll carry on over at this one node, we know that this is going to return just a value of one.

And now at this four node, I can compute its total sum.

And recall that this four node had a left child of zero, right? Because it has a null node.

And so when I compute the sum, I get five, which is perfect.

And finally, at the main route, now I bring up these two values.

And I compute 17 plus three plus five.

And that gives me a final answer of 25.

Which is indeed the correct answer.

Right? So that's how we should really think about our recursive algorithms for our binary trees, right? I kind of draw it out, I think about the base case, which is typically not always but typically about the null node.

And then from there, I figured out how a parents can compute its result given its children's answers.

Alright, so if we take a look at the complexity of this, it's pretty straightforward.

We'll go ahead and define n as the number of nodes in our input tree, in which case, I can see that my time complexity is just O of n, right? We know that we're going to make a recursive call just for every node of the tree.

And we're not going to call duplicate nodes, right, we're going to have just one call for every single node.

And within any single node, we're just going to do some simple arithmetic, right, we just had roughly three numbers together.

So it's not like we're going to have like a loop inside of our calls at all.

In a similar way, we'll say the space complexity is O of n, just because we have that implicit, a call stack space, because we are going to solve this one recursively.

And so we're solving this one in O of n time and space, which would be actually a maximum efficient a solution for this problem.

And so with that, I think, let's head over to the walkthrough video, and I'll show you how to code this one up.

Hey, programmers, Alvin here, right? Now I want to walk through the JavaScript solution for this tree some problem, I think this time around, and I'll jump right into the recursive version, right? So we'll start recursively.

And we'll begin with our base case, right? My base case is always about the simplest version of the input, where I just know the answer without needing any additional calculations, right? I know that the simplest tree here that I could be given is going to be the empty tree, right? I have the empty tree.

That means my root is no.

And if your root is no, you have the empty tree.

What is the sum of the empty tree? Well, kind of inherently, it's just zero.

So I'll be my base case.

Nice.

And then from there, I'll think about how I can compute my answer, given my children results.

So I need to find the results of the some of my left subtree.

And also the some of my right subtree.

So just call recursively.

So tree, some of root left, as well as tree some of root.

Right? Cool.

And I know that these two calls, they return numbers, right, representing the sum of my left subtree.

And the sum of my right subtree.

As the parent that is so rude, how can I find my total sum? Well, it just is myself.

So root out value, plus everything in my left subtree plus everything in my right subtree.

Right.

And we'll go ahead and just test this out the gate.

But this is nothing fancy, really elegant code to look at the test cases here, we do have some a diverse output.

So this code does work on trees of all different shapes and sizes.

Something that helps me you know, really believe the magic of recursion is to just analyze the assumptions here, right? So let's say that I'm stepping through tree some and my root is this three over here, right? So I checked the base case, is this three node? No, it's not.

So I must make the recursive call, right.

And I know that when I break down this code recursively, I know my route that Val is going to be like three, so I'm kind of corresponding, this comment with the thing below, right? And then when I make the recursive call on tree, some root dot left, that means I'm asking for the total sum of this subtree starting at 11.

So I'm looking at the 11 for negative two subtree.

Right, if I take the total sum of just that left subtree, it looks like it's going to be just 13.

It's now I'm saying plus 13 over here, right? If I do the same thing on the right, subtree I know that this call is for this four node, right all of its children, that should just magically return by the power of recursion that should return five, right? I'm going to assume that that recursive call just works.

So you're out the five, right? If I take the total sum of these, three plus 13 1616 plus five is 21.

That would give me the correct answer, right.

So to have some confidence in my recursive code, I just write the code.

And then I assume correctness from my recursive calls.

And I figure out how I can take those sub valleys for my children, combine it with my own value, and that should be my final answer.

So here is the recursive version of this solution, which would be some sort of a depth first traversal, technically, because it's recursive.

And if you'd like, I can also show you the iterative version.

So let's just do that.

And I always practice usually my problems doing both the recursive as well as iterative version, if it's reasonable, and is really reasonable here.

Hopefully, you're familiar with our breadth first code by now, right? So I'm just gonna start by checking, hey, if you're given some root that is already know that that's kind of an edge case, I'll just go ahead and return zero, right? Because as some of that empty subtree, or that empty tree, rather, is just zero, that can begin my main code.

So while my queue is not empty, so I'll start with a Q, who begins with the Route Route, I want to loop while my queue is not empty.

So while q dot length is bigger than zero, I'll begin a single iteration of my while loop by just shifting out the front of my queue.

So in JavaScript, for me, that's q dot shift that removes the front element, and also returns it to me.

So I'll save in current.

And then from there, now that I have this current, I know that contains the value that I actually care about.

So what I would do is go ahead and track some running sum.

So I'll say let some member say let total sum equals zero.

And as I remove something from the front of the queue, I'll take it to value and add it to my total, something that will accumulate all of the values right into a sum.

And from there, I just need to add my classic logic of checking for my children, right? If they exist.

So if I have a left, so if current dot left is not equal to know, then what I'll do is add that left child into my queue.

So q dot, push my current dot left, again, make sure you're following your cue rules, right, so shifts removed from the front, push adds to the back, it's really important that my shift and my push or my add and remove methods work on opposite sides of my queue.

Otherwise, it's not a cue, right? So that looks good to go.

I'll write something symmetric.

For the right hand side over here.

By the end of my function, I'll just go ahead and return my total sum.

Nice, this would be my go to enter diversion.

course, it's technically a breadth first, and we'll give that a test.

Nice.

And here we have that solution.

So one thing to note, I think it's pretty important to be consistent how you implement these algorithms, I swear possible.

So you'll notice that I always am a fan of a writing my like processing logic for a node.

Here I consider like the processing logic, where I add the value of my current node into my total sum.

I do that processing logic, typically when a node leaves the queue, and not when the node is added to the queue, and just ends up being less repetitive that way, for example, I've seen some people write code like this, where it's like, Alright, well, you know, I guess since I'm adding my left child into my queue, that means it exists.

So not only will I push it, but I'll add it so I'll do I don't know total sum, plus equals current dot left dot Val, right, so I'm kind of adding the child's value as soon as it's added to the queue.

And you can write something symmetric for the right hand side, you can see that because of this, I kind of have to double up all of my code, which does not make it super clean.

And I think something that is even worse than that is well now you actually never added your root value into the your, your total sum.

So you'd have to begin your total sum as root dot value at this point, I'm like, I kind of just hate this code, right? So you can run this, this would probably work.

So this code totally works, but it's not what I think is the best design for this pattern.

So I'd rather write it like this, right? consume your values when they leave your queue because you know, eventually, everything's gonna leave, right? So I'll prefer it at least like this.

Cool.

So before you go on to the next problem, recommend you practice both versions.

I know of this problem.

So do it recursively do it iteratively have them both down pat because we're going to increase the difficulty right now.

Hey, programmers, Alan here right now.

One To go over the approach for this tree min value problem.

So just like we've been doing as of late, we're going to have to take in a binary tree as input into our function.

And we want to do is figure out what the smallest value within the tree is.

That is we want to find the minimum value.

So we can totally assume that the tree is going to be non empty, right? And so given that information, looking at this particular tree example, it's pretty plain for us to see that the smallest number in the tree is just this three.

Alright, so our function just needs to return of the number three.

So it's plain to see that the answer is three.

But how can we come up with an algorithm to do this for us? Well, we should look to our tools in our binary tree toolbox.

And that would mainly just be either a breadth first or a depth first traversal.

One obvious way to solve this one is to use either a depth first or breadth first iterative piece of code that does a traversal and travels through the tree, then you just need to maintain some outer variable to track the current minimum.

And whenever you hit a node that is smaller than your current minimum, then you replace that minimum variable.

And by the end of the code, you should have the true minimum.

So the iterative version, I think, is pretty straightforward.

And I'll be sure to walk through that when we get to the code walkthrough.

But for now, in terms of our approach, visual, I think we'll step through this one recursively, right, because it ends up being pretty succinct code.

And so let's take a look at this tree.

And let's pretend that we filled in all of the null pointers, like usual, right? So these dark nodes over here represent nodes that don't exist, meaning that there are no, right.

So for example, if I look at the three node, its left child is no, but its right child is 12.

And that's going to be very useful for us to at least visualize because I should make a base case about those null nodes, right? So I know in the long run, what I want to do is figure out what the smallest value within the tree is.

And so a great default value for our null nodes would be to return infinity.

And here's the reasoning why I know that I should not really consider any of the actual null nodes.

And so if I have them return positive infinity, I know that positive infinity is definitely not going to be the minimum compared to any numbers that are actually within the tree.

So we'll start to do is just fill in all of these infinite values.

In other words, every time we call upon a null node, or a null pointer, we're going to return infinity.

So I'd fill all of these in.

Now using those infinities as our basis, we can actually construct our return values.

So looking at this for node to the left, what I have to do is consider both of its children that it received, right, and also the value within the current node.

And so what I do is I check, alright, compared between infinity for an infinity, what's the smallest value among them? Well, I know positive infinity is a very large number.

So really, the smallest number here should be four.

And so this call should return four, right? This node should return for similar story for this 15 node.

Once I have my left and right return values ready, I do a comparison with those values against myself, right? So I check, what's the minimum among infinity? 15 and infinity, the minimum is 15.

I think it's gonna interesting now that we're at evaluating this 11 node, right? Now I have some actual numbers.

And so I do this comparison, right? I compare my left subtree value, which is four and my right subtree value, which is 15.

And also myself, which is 11.

So among 411, and 15.

What's the smallest number? Well, that would just be the four, right? So this node should return four.

And if I do a quick spot check, this makes some sense, because I have this answer for above the 11 node, that's telling me that, within that subtree rooted at 11, the smallest value was four, which is totally correct.

Now we'll just go ahead and valuate the rest of this tree.

Looking at this 12 over here, I know I can't evaluate the three because I need a value on the right hand side ready.

So I must evaluate this 12.

And I just do the comparison, right? What's the minimum among infinity 12 and infinity? Well, let's just definitely 12.

Finally, at this three node, I take the minimum of infinity three and 12, the minimum there is three.

And finally at the ultimate root, I do the comparison.

And I check what's the smallest among four, or five and three? And the answer is going to be the three, right, which is exactly what we expected.

And so just by adding a little variation to our classic depth first recursion, we can totally solve this problem.

The logic we need to use to combine our child sub solutions into our main solution is to just do a comparison, right? So overall, at every point of this tree, we asked ourselves, right, given the smallest value in the left subtree and given the smallest value in the right subtree.

I compare those to myself, and return the smallest among those three.

And then when it comes to the complexity of this, it's pretty straightforward.

We'll go ahead and say that n is the number of nodes within our input tree.

And we know that we're going to have a call for every node of this tree.

So that seems to be an O of n time.

In terms of the number of recursive calls, right, and we know within any particular recursive call, it sounds like we're just going to do some conditional logic, right, just find the minimum among three things.

Since three is a constant number, I'm pretty sure that we're going to have just an overall time complexity of O of n, considering the number of calls that we make.

Now, that being said, we'll also have O of n space complexity adjust due to the call stack that we use for baseline depth first traversal.

And that seems to be an optimal solution for this problem.

Because what we'll do, we'll go ahead and code this one up, and I'll catch in the next one.

Hey, programmers, Alvin here, right now I want to go over a JavaScript solution for this tree min value problem.

And of course, we'll solve this one a few different ways.

I think I'll start by showing y'all maybe some iterative solutions.

And so we'll just do some classic depth first and also breadth first, along the way, right.

So you know, you're going to need to iterate or hit every node within your binary tree.

So just go ahead and set up either a stack or a queue.

So I'll choose to start with a stack over here.

So I'll say Kant's, stack equals empty.

And one thing I'll have to be aware of is looking at the assumptions in the problem, they tell us that we can assume that the input tree is not empty.

And so that means I won't need to add a leading if statement checking if the top level root is null.

So I can just go ahead and initialize my stack with the root node inside.

Cool.

And then from there, you need your main loop to iterate through the different nodes.

So I'm going to loop while my stack is not empty.

So all stack dot length is bigger than zero.

Cool.

So if that's the case, and there are still some nodes to visit, and begin a single iteration of this algorithm, let's say depth first, by doing stack dot pop, so I removed the top of my stack, go ahead and call that my current.

And then from there, of course, we need to check if our children exist.

And if they do, I'll add them to the top of my stack, right? So I'll write a pattern like this, I'll say if, let's say current dot left, that is not equal to No, then I can go ahead and push that existing child on the stack, right? So stack dot push, and I'll push current left retinas a few times by now should it be second nature, I'll do some same code for the right hand side.

And this is kind of my baseline of a depth first traversal, right.

But as I look at this current node and its value, I want to by the end of my loop, have access to the minimum value within the tree.

And so because I need to find the minimum value in this function, we're going to use a variable that I'll update over time, right to track the current smallest thing I've seen.

So I'll initialize this as let smallest, I'm gonna have to think about a good default value for this.

And so I'll go ahead and initialize this to actually positive infinity.

So if you're unfamiliar with some JavaScript, infinity is basically just a number that is guaranteed to be bigger than all other numbers, except for itself infinity, right? And the reason I'm choosing a big number, like positive infinity, for my default value for the smallest variable, is because when I see any actual values of my tree, I know they're guaranteed to be less than infinity.

So these numbers would replace my infinity, just gives me a good initial value, right? That's a pretty common pattern, right? If you're looking for the minimum thing, and typically your default value is positive infinity.

If you're looking for a maximal thing, then your default value might be zero or negative infinity, depending on the problem you're trying to solve.

And so with that default value, where do I actually want to replace it, right.

And I'll choose to do that right after or something leaves my stack.

That way, you only have to say it once.

If I wrote it, when I added my children into the stack, what I'm saying twice, right, which is kind of annoying.

So I'll just check, hey, if current value, so be sure to compare the actual number value, current value is less than the smallest, then I've just found a new smallest, right? So just replace that variable with current value.

Of course, by the end of our while loop, we should just return that variable, right? And we should have the true minimum.

So let's give that a shot, run these test cases.

And this is our rendition of an iterative depth first, right? Awesome.

So if you wanted to switch it up, you know, writing the breadth first is super trivial in terms of the change we make, you can just make sure you do stack dot shift, right, because that would remove the front element of your queue now and if you push then you're still adding it to the back.

And I guess you should probably rename this guy to queue.

So very minute difference.

Well, tests that just give that a go.

Cool, passes all of them.

Nice.

And one thing to note.

So Alex in JavaScript, there is no immediately when I recorded this video, there is an immediately available, like optimal queue data structure just baked in, like you can't import it through a standard library.

And so when you actually do the array dot shift method, that line itself is going to run an O of n time, right, because if you remove the front element of an array in JavaScript, it will have to actually shift all the other elements over one position.

In other words, index one becomes index zero, index two becomes index one, and so on.

And so technically, if you implemented your breadth first exactly like this, just using a regular array, and you shift out, then this would probably be technically like an O n squared solution, which isn't the fastest, but we'll be able to pass the specs, typically n squared for most problems is kind of okay.

But you can avoid it if you want to get the blazing fast solution.

But now let's actually go ahead and implement my favorite version, which would be a recursive version, right, which is technically of the depth first.

Right? So we'll say const, trimming value, chattering min value, dream and value.

And to establish this one recursively will always start with our base case, right? That's when you saw these curly guys.

So I'll start my base case, I'll say if my routes is equal to null, then that kind of means I have the empty tree, what's like the minimum value in the empty tree? While that must be infinity, right? For the same reason we chose infinity before, right? It's just a good default value, because I'm going to minimize in the long run.

Cool.

And now what I want to do is I want to make my recursive call.

So if I call treeman value on my left child, and I call it on my right child, I'll just think about what these function calls return.

Right? Although they're recursive, if these calls work, they should give me back the smallest value in the left subtree.

And the smallest value in the right subtree.

So maybe, just to be clear, I'll go ahead and save the system variables.

So I'll say const, I'll say, left.

Min.

And also this should be the right men, right? So I found the smallest in the left and the smallest in the right.

But I also need to think about myself, right? I am ru dot Val.

So I need to choose the smallest of root Val left men and Reitman, right, so you can write like a conditional.

So just some if statements If you want, I think the best way to implement this in JavaScript is just to use the math dot min function.

So JavaScript, you always have access to the global capital math object has a few useful methods on it.

One we're going to find useful right now is math dot min.

If you do that, you can pass in some arguments and an arbitrary number of arguments.

So give me the smallest between route dot Val and be sure to access the value because you need to give numbers to men, right? Smaller between route dot Val, my left men and my right man.

Cool.

And this feels somewhat similar to the approach drawn we did right where we had to choose the smallest of these three numbers.

So before we run it, maybe you're unfamiliar with math dot min, I can quickly demo that for you.

Let's say I had some numbers, we had 10, we had three, we had six, and we had negative 12.

And also 100.

And if I console log with that returns, I'll just run this file as a script.

So I'm not going to execute the tests quite yet.

So I should get negative 12.

Because that's the smallest perfect.

And now I think we're ready to go ahead and test this.

So our recursive version, there we have it.

Cool.

Alright, so there, we have our JavaScript walkthrough for this tree minvalue problem, recommend you practice all of these different solutions, and then pick a favorite, maybe just have in your back pocket.

That way, you can always solve this problem in the future, right.

So you should have no issue thinking about how to solve like a tree maxvalue problem.

And by now, you know, we're getting pretty comfortable with trees.

And typically, we're always going to fall back to either a breadth first or a depth first traversal.

But in the next few problems, we're definitely going to look at some spin offs and some variations on how we can accomplish more complex logic using these algorithms as our baseline.

So I'll catch in the next one.

Hey, programmers, Alvin here, right now want to go over this max root to leaf path, some problem, pretty wordy title, let's take a look at what this problem asks us to do.

So we're going to be taking in a binary tree as input, and we want to do is really talk about the paths within this tree in particular, root to leaf paths.

So just to review, we know that a binary tree typically for us has a single root and you can identify the root by just looking at the topmost node, that is the node with no parent, right? And then also given this tree there are three leaves, right? a leaf is a node that has no children.

So do bear in mind right a root has no parent.

A leaf node has no children, some Like 11, and three in this picture, there are neither roots nor leaves, right.

So it could be the case that a tree has many leaves, like this tree, right has three leaves.

But a tree for us typically only has a single root.

And so what we want to do is consider all three of the different root to leave paths, right, so you must start at the root, and you must terminate at a leaf.

So one of those paths would just be this one, right 511 for, what we want to do is consider its total sum.

So just summing the values within the nodes along that path.

If I do five plus 11, plus four, that would give me a total sum of 20.

So that's just one of the possibilities.

If I look at another path, let's say this path of 511 to five plus 11, plus two would give me 18.

That's another option.

The only other option is is final path from five to one, five to five plus three plus one.

That gives me a total sum of nine, right? And now among those three options, I want to choose the maximal path some right? So that would be a final answer of 20.

So in the long run, we need to come up with some code that computes the maximal path sum from the root to any leaf.

And that sounds like a pretty hard problem, right? How can we go about doing that one? Well, hopefully you notice some similar patterns, right to problems we've done previously.

So just by looking at the name of this problem, I'm reminded of a few different patterns, right? I can think of the tree some problem seems pretty related here.

And can I also think about, like that minvalue.

Problem are, we had some minimization logic, except now, I want to maximize something here.

And so probably what I'll have to do in this one is combined some of my previous knowledge to come up with a pretty novel solution, but it's okay to rely heavily on our previous experiences, right.

And so let's start with something classic, I think we're gonna solve this one recursively.

And in the grand scheme of things, typically, for tree problems, that is, a recursive code is usually your best bet when it comes to like, pathfinding things, right, and building pads and determining pads.

And so we'll take a look at what we should have our base cases be, if we're gonna frame this one recursively.

So they tell us that, all right, you need to consider paths, but not just any paths, right? You always want to end at a leaf node.

So the leaf nodes, like the ending point, belief, notice the base case.

So my base case is going to be literally about a leaf node.

And recall that that's a node with no children.

So for example, let's say we had a node as input that had no children, then what's the total sum of that leaf node? Well would just be its inner value n, right? So kind of think about your base cases as if they're their own inputs, right? As a quick aside, right, so a totally separate scenario, right? Now, let's say I gave you a tree that contains only one node, and its value was 42.

And I asked you to, alright, tell me, what's the maximum path some of this tree, this tree is very small, right? If you identify the root in this tree, it's just the 42 node, right? Because it has no parent.

And I've also asked you for the leaves, there's only one leaf here.

And it's also the 42, right? Because it has no children, right? So the single note of 42, in this example, is the root and the leaf, which means that the maximum path, some would just be 42.

Cool.

So I'm thinking about my base cases as if they're their own inputs.

Nice.

And what you'd probably recognize here is, in this scenario, we're kind of considering a base case, that is not about a null node, right, we will need at least a separate base case that checks if we have an actual leaf node.

And that's very, very inherent and given in the problem, right? They say root to leaf path.

Awesome.

So if that's the case, I'm just going to locate all of my leaf nodes in this diagram.

And I know that they're going to return the values within them.

So just plugging those in, right? And now I can start reconstructing on my higher level solutions, right? So given this 11 node, what decision does this 11 node have to make to compute its answer, right? So let's read ourselves at this 11 node.

And we have to consider our left and right values, right.

And so if i route myself at 11, the four represents my max path sum through my left subtree.

And the right hand side to now represents the max path sum through my right subtree.

Since I want to maximize here, the key is to just choose between four and two, right? I choose the bigger of them, right? So four is bigger than two, so I must use the four.

And what I do is I take that four, and I add my current value of 11 into it, and that gives me 15.

And that would actually be the answer for this subtree.

In other words, I can check for correctness right now, if I root myself at 11.

I'm returning 15 to represent this path, right? I can either do 11 plus four, which is 15.

Or I can do 11 plus two, which is 13.

Right and that 13 is smaller, so I won't prefer it here.

Cool.

So so far, it seems like we're in good shape.

Now let's take a look at another node read to evaluate.

Let's look at this.

Three node.

So it has a value on its right hand side, right? It's receiving a one from its right child, but the left child doesn't exist, right? And if you want to be a little more explicit, we know that the left child or three dot left is going to be a null pointer.

All right? So kind of plug that in here.

And here's where we should work in possibly another base case, sometimes it's very natural to course correct as we go.

And so for a null node, what should we return? Well, we know that whenever we have a null node, it should never contribute to our final answer, we can kind of just ignore it, I guess, we want to make sure that it's compatible with the rest of our internal logic.

So bear in mind in this problem, I want to take the maximum right? Recall from our previous problem, right, the min value problem, we want to take the minimum.

And so we made our null nodes return infinity, right? Because if I want to find the minimum, and my null nodes, return infinity, by default, I know that infinity is never going to win a comparison, right? Because infinity is very large.

And we just want to flip that logic over here, right? So because in the long run, I want to find the maximum, I'll make my base case for the null nodes return negative infinity, right? Because I know negative infinity is never going to win any contest where we compare things, looking for the larger of the values, right? So for this null note, I'll plug in that negative infinity.

And now I shouldn't be able to do the same business logic as before, right? So I'm rooting myself at the three node, and I can look at the results I get for my children, right.

So between my two children in my left path, I get a negative infinity, or in my right path, I get a one, and I choose the maximum between them, right? One is bigger than negative infinity.

So I should use the one, right.

And what I do with that one is, I add my current value of three to it.

So three plus one gives me four, right.

And that makes some sense, because if I look at that small subtree, rooted in three, the biggest path from root to leaf, or sub root to leaf, I would indeed be a four.

Nice, and now we have ourselves at the ultimate root over here, I do that similar comparison, right? I check the bigger of my two children, so I'm going to keep the 15.

But then I add myself to it giving 20.

Like we said before, this 20 logically represents this path of five plus 11 plus four.

Cool, so there we have it.

And if you want to take a look at the complexity of this seems nothing unusual.

So we're going to have n as the number of nodes, we're going to have O of n runtime, because we're going to have to make a call a recursive call that is for every node within the tree.

And if I think about any particular call, we're going to make a foreign node, we're just going to do a comparison, right, I just choose the bigger of my two children.

So we're not going to have any, any loops within our calls, I believe.

Cool.

So it just seems to be O of n time.

Like we always say space complexity is O of n, just due to the call stack.

Nice.

So let's go ahead and code this one up.

And it should feel like a combination of our previous tree some problems, as well as some a min value max value logic.

Hey, programmers, welcome back, Ryan, I want to go over a JavaScript solution for this max root to leaf path, some problem.

So this is going to be a pretty interesting tree problem.

And we'll jump right into the code, please make sure you watch the approach video before this.

So I think should be all primed up with the logic that we want to implement here.

Right? And so we'll start by doing this recursively.

And I'd say that's probably the best way to solve this one.

So I think it's the only way I'll show you, when I want to do is start with a base case, right? So we said we want to figure out our root to leaf paths.

So our base case should be about whether I have a leaf, right? So I'm going to go ahead and check let's say, if my root left is equal to No, right? And root, right? Is equal to No, right? That's the definition of a leaf.

So if I have the left child and I have the right child, then I should return the value stored at this node, right? So root, dot Val.

Nice.

So again, we're kind of emphasizing here is that base case catches a scenario.

If we're at like four, right, we have no children.

Nice.

And we will need another base case in the long run.

For now, let's say we left it like this, right? So we said that in the context of solving this one recursively, the decision we make at every note is I choose the bigger result from my left column A right call, and then I add myself to it, right? So I know I'm going to do this recursively so I'm going to call the same function.

And right now you should be familiar with all right, you call your function on root left, and also root right? That I think about what those calls return, right? They give me back, the max pass some through my left subtree on the max path, some through my right subtree I just want to choose the bigger results between Windows two.

So no I swear to you saw me use the math dot min function here I'll use the math dot max function.

And I know that these calls these expressions evaluates to numbers.

So I can actually just pass these guys in, in line.

So I would just move this up like that.

So when finding the max between these two results, and I'll go ahead and call that we'll say, the max, your child, right? Maybe I'll write this online, they prefer.

And then from there, I just add myself to that max child, right? So I'm going to return route dot valance myself, plus max child.

And we'll call that max child path.

And that should be it except for one thing we're forgetting.

So take a moment, see if you can read between the lines here.

And what scenario Am I missing? We did mention it in the approach video.

So can you spot what is not present here? And that's something I find I do often right? If I'm able to really come up with a nice, meaningful and consistent picture, then everything I drew in the picture should translate to some piece of code over here.

Let's give it a shot.

Expect to fail this one.

See what we get? Yeah, so we're getting an error cannot read property left have no, right, I found on the very first example.

So I'll tell you that this is caused by an asymmetric node, like this four over here, right? This four has no left child.

So imagine what would happen in this instance, right? So if we're evaluating this code, we know that our route is going to be this four node.

And this if statement on line 10, is not hit, right? Because four is not a leaf, right? Because it has a right child's right child does not know.

So instead, it's going to run until 11.

And it's going to try to execute max path, some of root dot left root that left is no.

And so when we actually evaluate that call, now we're seeing is no, and we're gonna check no dot left over here.

And that's going to break right? It's exactly the line that's broken.

And so in addition to this base case, right, when we bought him out at a leaf node, what if we just end up at a null node, so if root is null, then we said that a good value to return would be negative infinity, right? Because I'm choosing to, in the long run, do like maximal logic and want to pick the max.

So if I choose a negative infinity, that won't interfere with any of us taking a max, right? Because imagine that this thing was negative infinity.

And I would just prefer the right hand side if it was not infinity, right? Negative infinity that is.

And so with that, let's go ahead and give this a go.

Cool.

And then we have a nice solution for our max root to leaf path some problem.

So notice how short the code is, by no means do I think this is simple code, though, right? At this point, it's okay if it feels a little tough.

But you understand how we have some familiar patterns, right, I still have those two recursive calls right over here.

And we typically only vary in how we take those recursive calls or the results from them, and combine them into our higher level answer.

So keep practicing this problem and I'll catch you in the next one.

All right programmers.

That wraps up our course on the introduction to binary trees.

If you want to explore this binary tree topic, or really any other data structures and algorithms topic more deeply.

Be sure to head destructing dotnet where we have all of these topics covered through tons of problems where we have video walkthroughs and illustrations for every single problem.

I think you'll find this especially useful if you're repairing and really cramming for those technical interviews.

Thanks for watching, and I'll see you there.

I'm Lynn, a software engineer and a recent graduate from the University of Chicago. This is the third course in my Coding Interview Crash Course Series. Feel free to check out my YouTube channel, Lynn's DevLab, to stay updated on this series.

This crash course is about Graph Traversal. If you just want to dive right in, you can find the course here (and linked at the bottom of this article). If you want a little more info, read on. 😎

Introduction

We will cover two common graph traversal techniques: Depth-First Search (DFS) and Breadth-First Search (BFS).

We will first learn about how they work and how to implement them in code. Then we will see the algorithms in action by solving a LeetCode problem as well as looking at how I applied Graph Traversal when implementing an algorithm for my game, Clicky Galaxy (also my first game in Unity when I was learning Unity 😉).

Clicky Galaxy, a game I made when learning Unity

Course Outline

This course video runs for 1 hour and features:

• A high-level description of Graphs, DFS, and BFS

• DFS implementation

• BFS implementation

• How to find a path between a source and a destination node

• LeetCode Demo: 785. Is Graph Bipartite?

• Clicky Galaxy Demo and Graph Traversal in Unity C# 🚀

Graphs are a favorite interview subject among top tech companies like Google, Microsoft, and Facebook. More importantly, it's also fun and useful in practical software engineering like Game Development. Let's crunch this topic together in my course!

Definition of a Graph

We will use the following graph to show the traversal path for the two traversal algorithms.

We may represent the graph by mapping each node to its list of neighbors, as shown in this Python snippet:

graph = {
    0: [1, 4],
    1: [0, 2, 3, 4],
    2: [1, 3],
    3: [1, 2, 4],
    4: [0, 1, 3]
}

How to Use Depth-First Search

As its name suggests, DFS prioritizes depth in its search.

For a given node (say 1), after visiting one of its neighbors (say 0), instead of visiting the rest of the neighbors (nodes 2, 3, and 4) immediately, it caches those neighbors and immediately resumes its visit on 0's neighbors. Only when it has exhausted the depth will it return to those cached neighbors.

Iterative Implementation

def dfs(graph, start):
  visited, stack = set(), [start]
  while stack:
    node = stack.pop()
    if not node in visited:
        # perform some operations on the node
        # for example, we print out the node
        print('Now visiting', node)
    visited.add(node)
    for neighbor in graph[node]:
      if not neighbor in visited:
        stack.append(neighbor)
  return visited

In this template, the commented lines are where we can perform some operations on the node: for example, printing out its value, checking for equality, and so on.

We keep track of a set named visited to avoid visiting the same node multiple times where there is a cycle in the graph, like in our example graph above.

Running this code on the graph we defined above results in the output below:

Now visiting 0
Now visiting 4
Now visiting 3
Now visiting 2
Now visiting 1

How to Use Breadth-First Search

BFS prioritizes breadth in its search. For a given node, it visits all of its immediate neighbors before moving onto the neighbors' neighbors.

Iterative Implementation

def bfs(graph, start):
  visited, queue = set(), deque([start])
  while queue:
    node = queue.popleft()
    if not node in visited:
        # perform some operations on the node
        print('Now visiting', node)
    visited.add(node)
    for neighbor in graph[node]:
      if not neighbor in visited:
          queue.append(neighbor)
  return visited

Running this code on the graph we defined above results in the output below:

Now visiting 0
Now visiting 1
Now visiting 4
Now visiting 2
Now visiting 3

How to Find a Path Between a Source and a Destination

Now that we've seen how to use DFS and BFS to traverse the entire graph and print out the whole traversal history, we can make some small changes to the templates to find a path between any two nodes in the graph (if such path exists).

On a graph where each edge has the same weight, BFS is equivalent to Dijkstra's Shortest Path Algorithm. It finds the shortest path (path with the fewest number of nodes) between a source node and a destination node. This is a nice property that a path search with DFS doesn't have.

Here's how we adapt the DFS template to return a path given a src and a dst node:

def dfs_path(graph, src, dst):
  stack = [(src, [src])]
  visited = set()
  while stack:
    node, path = stack.pop()
    if node in visited:
      continue
    if node == dst:
      return path
    visited.add(node)
    for neighbor in graph[node]:
      stack.append((neighbor, path + [neighbor]))
  return None

Similarly for BFS:

def bfs_path(graph, src, dst):
  visited, queue = set(), deque([[src]])
  while queue:
    path = queue.popleft()
    node = path[-1]
    if node in visited:
      continue
    if node == dst:
      return path
    for neighbor in graph[node]:
      queue.append(path + [neighbor])
  return None

Let's Solve a LeetCode Problem!

Let's now apply what we learned about Graph Traversal to solve a problem on LeetCode, 785. Is Graph Bipartite?

According to this article, a modified BFS algorithm is all we need:

Following is a simple algorithm to find out whether a given graph is Bipartite or not using Breadth First Search (BFS).

1. Assign RED color to the source vertex (putting into set U).

2. Color all the neighbors with BLUE color (putting into set V).

3. Color all neighbor’s neighbor with RED color (putting into set U).

4. This way, assign color to all vertices such that it satisfies all the constraints of m way coloring problem where m = 2.

5. While assigning colors, if we find a neighbor which is colored with same color as current vertex, then the graph cannot be colored with 2 vertices (or graph is not Bipartite)

Plugging our template, the solution is as simple as follows. Check out my video for a line-by-line explanation.

RED = 0
BLUE = 1
from collections import deque

class Solution:
    def isBipartite(self, graph: List[List[int]]) -> bool:
        if not graph:
            return False
        queue, visited = deque([]), set()
        for v in range(len(graph)):
            if v in visited:
                continue
            queue.append(v)
            node_colors = {v: RED}
            while queue:
                node = queue.popleft()
                visited.add(node)
                my_color = node_colors[node]
                for neighbor in graph[node]:
                    if neighbor in node_colors and node_colors[neighbor] == my_color:
                        return False
                    if not neighbor in visited:
                        queue.append(neighbor)
                    node_colors[neighbor] = RED if my_color == BLUE else BLUE

        return True

Graph Traversal in Action: Clicky Galaxy, A Game by Me

One more fun demo about Graph Traversal: Clicky Galaxy 🚀, a casual match-three game I built when I was learning Unity.

In the game, you move a planet to an empty cell and score when there are three or more identical planets aligned horizontally or vertically. A planet can only move horizontally or vertically, and its movement path cannot be obstructed by other planets.

I applied Graph Traversal to check for a valid path between the planet the player clicked on and the destination cell to determine if the planet can move to that cell.

Each cell in the grid is a node and has four immediate neighbors: up, down, left, and right. As I want to find a short path between the source and the destination (if there exists one), BFS pathfinding is ideal for my use case.

Here is how my code looks like in C#. I used a helper named GetNeighbors to get the four immediate neighbors, ignoring out-of-bound ones.

List<Vector2Int> BreadthFirstSearch(Vector2Int srcIndices, Vector2Int dstIndices) {
    // identify a path from srcIndices to dstIndices, could be null
    // the path include src and dst
    HashSet<Vector2Int> visited = new HashSet<Vector2Int>();
    Queue<List<Vector2Int>> pathQueue = new Queue<List<Vector2Int>>();

    List<Vector2Int> startPath = new List<Vector2Int>();
    startPath.Add(srcIndices);
    pathQueue.Enqueue(startPath);

    while (pathQueue.Count > 0) {
        List<Vector2Int> path = pathQueue.Dequeue();
        Vector2Int node = path[path.Count - 1];
        if (visited.Contains(node)) {
            continue;
        }
        if (node == dstIndices) { // done
            return path;
        }
        visited.Add(node);
        List<Vector2Int> neighbors = GetNeighbors(node);
        foreach (Vector2Int neighbor in neighbors) {
            Sprite sprite = GetSpriteAtIndices(neighbor.x, neighbor.y);
            if (sprite == null) { // can visit this next
                List<Vector2Int> newPath = new List<Vector2Int>(path);
                newPath.Add(neighbor);
                pathQueue.Enqueue(newPath);
            }
        }
    }

    return null;
}

List<Vector2Int> GetNeighbors(Vector2Int indices) {
    // return the four immediate neighbors, left, right, up, down
    List<Vector2Int> neighbors = new List<Vector2Int>();
    if (indices.x >= 0 && indices.x < gridDimension && indices.y >= 0 && indices.y < gridDimension) {
        if (indices.y >= 1) {
            neighbors.Add(new Vector2Int(indices.x, indices.y - 1));
        }
        if (indices.y < gridDimension - 1) {
            neighbors.Add(new Vector2Int(indices.x, indices.y + 1));
        }
        if (indices.x >= 1) {
            neighbors.Add(new Vector2Int(indices.x - 1, indices.y));
        }
        if (indices.x < gridDimension - 1) {
            neighbors.Add(new Vector2Int(indices.x + 1, indices.y));
        }
    }
    return neighbors;
}

And my game came together really well with this algorithm!

Final Thoughts

In this crash course, we learned about the two Graph Traversal algorithms, DFS and BFS. We saw them in implementation first and then in action in a LeetCode problem as well as in my game.

If you enjoyed Graphs, think about how they relate to Trees. Spoiler alert! Pre-order traversal in trees is essentially DFS in graphs and level-order traversal in trees is essentially BFS in graphs. 🤫

Try figuring this out on your own or watch my crash course on Tree Traversal for a refresher. Trust me, algorithms can be fun! 😃

Resources

Watch the course here:

Access the code template on my GitHub:

Check out Clicky Galaxy on my GitHub:

Stay up-to-date with the whole crash course series:

And lastly, feel free to subscribe to my YouTube channel for more content like this :)

As a React developer, I have gone through my fair share of front-end coding interviews. Recently, I had the opportunity to experience the process from the other side – as an interviewer. Here is what I've learned.

Coding interview usually involve a multi-step process where interviewers assess everything from basic technical knowledge to culture fit. Every step of that process is important and should not be underestimated. Prepare for all of it and prepare well.

But there is one thing that is at the core of (almost) every React interview.

Inevitably, at some point, you have to build a React app.

The App Assignment

Here is a short list of real app assignments I had to complete for my own React interviews over the years:

• Support Desk app – an app to display a list of support desk employees and their contact information.
• Video app – an app where, given a YouTube video URL, it displays it on the page. Users can comment on it.
• Projects app – an app to display a list of on-going projects that users can subscribe to and follow.
• Articles app – an app to display a list of articles where users can leave nested comments for each one.

These assignments are, in many ways, very similar to each other. The reason is that they are assessing the same set of basic React skills. Which skills are those? Let's break them down.

Interview Skill #1 – How to Build UIs with React

A primary job of a React developer is to build and structure React components in a meaningful way.

The assignments above are meant to test your ability to write code in a modular and reusable way while creating abstractions at the right level.

The main goal is for your app to work well. But, as a front-end developer, you are also expected to build UIs that look good, too.

Most of the time, the assignment will come with a concrete design you'll need to follow. If that is the case, it's important to stick closely to it.

But if you believe that there is a good reason to deviate, don't hesitate to do so. Just be prepared to explain why your solution is better.

If there is no design available, the interviewer is probably interested in understanding if you can create sensible UIs on your own. Although this could be more challenging, it also gives you the opportunity to show you are able to make conscious choices when it comes to the front-end.

Tip: It is easy to assume that the expectation is that you have to build all components from scratch. Using a third party component library might feel like cheating in an interview context. But it is not!

Make sure to ask in advance what is expected. Taking advantage of component libraries like MaterialUI or ChakraUI is a huge time saver during interview assignments and will allow you to focus on more interesting parts of the app.

Interview Skill #2 – State Management in React

Another important challenge when it comes to building React apps is state management. There is a myriad of ways to go about this depending on your concrete use case and goals. Check out my article on the topic if you are curious to learn more.

Whatever approach you choose, what is important during as interview assignment is to show the interviewer that you understand and are able to reason about state management.

Your solution needs to make sense without being overly complex or convoluted. Be prepared to explain and defend your choices.

Tip: It is a good idea to match your state management solution to the one used by the company your are interviewing for.

Do they use Redux? Then don't hesitate to include Redux in your project. Are they into state machines? Then xState is your friend, and so on. Make sure to ask the interviewer in advance what they would like to see implemented in your project.

Interview Skill #3 – Data-fetching in React

As a front-end developer, normally you won't be expected to build your own back-end. But the assignment you are given will probably involve some form of data-fetching – likely either through a mock API of some kind or just a JSON file with the necessary data.

This part of the assignment is meant to test if you, as a front-end developer, know how to talk to the back-end. Can you get, display and update the data you receive from the back-end correctly? Do you understand how API requests work?

In a more advanced setting, there might be a conversation about data-fetching architecture, data state management, and front-end caching.

Tip: Make an effort to implement a semi-realistic data-fetching mechanism in your app. In you are given a JSON file, don't just directly import the data in your components. Instead, use fetch or another more advanced (preferably async) approach to get it so that you are able to demonstrate your deeper understanding.

Interview Skill #4 – Routing in React

A lot of the time, creating a React project is synonymous with a single page application. So it is possible that the assignment involves implementing a routing solution.

Here the goal is to demonstrate that you understand the basics of client-side routing and are able to structure your app around it.

Tip: Avoid creating your own client-side routing implementation, unless explicitly required. Opting for React Router or Reach Router is a perfectly acceptable choice.

How to Stand Out in a React Interview

Getting a solid grasp on the basics discussed above is a must and it's a good start to earn points during an interview assignment. But to truly stand out, you have to go a step further.

Here is how.

Understand Your Setup

Most of the time you can get away with using toolchains like Create React App (or similar) when building a React project for an interview. This will help you get started and save time.

In fact, it is important to use those tools in order to spend your time on meaningful development rather than setup.

But it's also important to understand and be able to explain the basic tooling you are using. During a React interview, expect to be asked questions about Webpack and Babel, for example.

But what can really give you an edge is if you not only understand but are able to enhance your existing setup. One idea would be to add a linter (eslint) and a formatter (prettier) to your app. This shows that you really care about code quality and consistency.

Another would be to go even further and setup pre-commit hooks (husky) that lint and format your code with each commit. Crazy, I know!

These tools take minutes to setup but can seem like an impressive extra step in the eyes on an interviewer.

Test Your Code

Very few assignments will explicitly state that tests are required. For this reason, many developers assume tests are not part of the task and completely ignore them. This is wrong!

Most of the time, an interviewer will be impressed to see that you understand the importance of testing your code. It is a very easy but powerful way to set yourself apart.

It is not necessary to have a test for every single line of code in your project. Several strategically selected tests covering the more complicated logic should do the trick just fine.

Don't Ignore Responsiveness

Here is another aspect of your React assignment that is not explicitly mentioned most of the time – responsiveness.

Even if you are given a design at the beginning of the task, almost always it will not be a responsive one. It is up to you care enough about responsiveness to figure it out on your own.

Same as testing, most developers will just ignore responsiveness. Which is good news for you – it gives you the opportunity to shine!

There is no need for the implementation to be perfect and work flawlessly on every screen and device. The mere fact that this is something you though about in your development process should be enough to score you some major points.

Improve Accessibility

Accessibility is a huge concern for most modern web products. Taking even minor steps to improve the accessibility of your project, like adding alt text to your images, for example, can leave a really good impression.

Accessibility is also another reason why you might want to choose a third-party component library when building your assignment. Most components in these libraries are accessible out of the box.

Making your project as accessible as possible can truly make you stand out in an interview. But what is more, accessibility should be (and is becoming) the norm in web development. Make sure your future employer knows you understand that.

Details Matter

Everything in your code should tell the interviewer you are a competent developer – from basics like the way you name and structure your code to minor details like commit messages.

Given that these assignments are usually done under time constraints, it is tempting to just ignore these seemingly unimportant aspects. But getting them right can meaningfully set you apart.

Hopefully this article is useful for your next React interview. Let me know how it goes!

Follow me on Twitter for more tech content.

I'm Lynn, a software engineer and a recent graduate from the University of Chicago. This is the second course in my Coding Interview Crash Course Series. Feel free to check out my YouTube channel, Lynn's DevLab, to stay updated on this series.

This crash course is about Tree Traversal. If you just want to dive right in, you can find the course here (and linked at the bottom of this article). If you want a little more info, read on. 😎

Who is the Course for and What are Tree Traversal Algorithms? 🌳

You will get the most of this course if you already know a bit about the Tree data structure. Check out these tutorials if you need a refresher.

We will cover the traversal algorithms for both Binary Trees and N-ary Trees (in which each parent node has an arbitrary number of children).

If you have heard about Binary Search Trees (BST) before, that's a special type of Binary Tree so the techniques we are going to learn here also apply.

Trees are a favorite interview subject among top tech companies like Google, Microsoft, and Facebook, so let's crunch this topic!

We will learn about four traversal techniques and solve their corresponding LeetCode problems hands-on.

The four techniques are:

• Pre-order (Depth-First Search, DFS)

• Post-order

• In-order

• Level-order (Breadth-First Search, BFS).

Course Outline

This course video runs for a total of 30 minutes and features:

• A high-level description of the four traversal techniques: pre-order, post-order, in-order, and level-order

• Recursive implementations of pre-order, post-order, and in-order (Note: this doesn't apply to level-order)

• Iterative implementations of pre-order, post-order, in-order, and level-order

• An extension of the templates from Binary Trees to N-ary Trees

Let's dive into each of the four techniques below.

Tree Traversal Demonstration Using an Example Tree

We will use the following tree to demonstrate the output from the four traversal techniques.

Note that this tree is a simple Binary Tree, not a Binary Search Tree (BST). A BST is a special type of Binary Tree, so our techniques also apply. Also, in-order traversal becomes especially interesting when we work with a BST, as we will see below.

An example Binary Tree. Note that it's not a Binary Search Tree (BST).

Given this tree, the traversal result from the four techniques are as follows:

• Pre-order: 1, 2, 4, 5, 3

• Post-order: 4, 5, 2, 3, 1

• In-order: 4, 2, 5, 1, 3

• Level-order: 1, 2, 3, 4, 5

Pre-order Traversal

Pre-order traversal is also known as Depth-First Search (DFS) if we analyze the tree as a graph and take the tree root node as our starting node in the search.

As in the example above, we go all the way down to the leftmost node before visiting any other node that is a left child of some parent node.

Pre-order traversal allows us to explore roots before leaves, and is hence ideal for tasks like copying a tree.

Post-order Traversal

Post-order traversal does the opposite of pre-order traversal, allowing us to explore leaves before roots.

In-order Traversal

In-order traversal is especially useful for flattening a tree into an array representation.

For a Binary Search Tree like below, in-order traversal outputs an array in a sorted, non-decreasing order: -4, 3, 2, 5, 18.

Binary Search Tree example

Level-order Traversal

Level-order traversal is also known as Breadth-First Search (BFS) if we consider the tree as a graph and start our search from the tree root node.

We visit every node on the current level (depth) before moving onto those on the next level. Effectively, we visit the immediate neighbor of (one step away from) our current node before visiting neighbors that are farther away.

How to Implement these Four Techniques

We will use the following definition for a node of a Binary Tree:

# Definition for a binary tree node.
# class TreeNode:
#     def __init__(self, val=0, left=None, right=None):
#         self.val = val
#         self.left = left
#         self.right = right

Recursive implementation

Recursive implementations are the most straightforward. The most important thing to remember is the order in which we concatenate the results from the two recursive calls (one on the left subtree and one on the right subtree) with the value of the current node.

def preorder(root):
    if not root:
        return []
    return [root.val] + preorder(root.left) + preorder(root.right)

def postorder(root):
    if not root:
        return []
    return postorder(root.left) + postorder(root.right) + [root.val]

def inorder(root):
    if not root:
        return []
    return inorder(root.left) + [root.val] + inorder(root.right)

Iterative implementation

Compared to recursive implementations, iterative implementations are non-trivial. Most require that we use either a stack or a queue to keep track of the nodes that we need to visit.

def preorder(self, root):
    if not root:
        return []
    ret = []
    stack = [root]
    while stack:
        node = stack.pop()
        ret.append(node.val)
        # note that we append the right child before the left child
        if node.right:
            stack.append(node.right)
        if node.left:
            stack.append(node.left)
    return ret

def postorder(self, root):
    if not root:
        return []
    from collections import deque
    ret = deque()
    stack = [root]
    while stack:
        node = stack.pop()
        ret.appendleft(node.val)
        if node.left:
            stack.append(node.left)
        if node.right:
            stack.append(node.right)
    return ret

The implementation for in-order traversal looks quite different from pre-order and post-order:

def inorder(self, root):
    if not root:
        return []
    ret = []
    stack = []
    while root is not None or stack:
        while root is not None:
            stack.append(root)
            root = root.left
        root = stack.pop()
        ret.append(root.val)
        root = root.right
    return ret

Lastly, we have level-order traversal, where we will output the result as [[nodes on the first level], [nodes on the second level], [nodes on the third level], ...].

def levelorder(self, root):
    if not root:
        return []
    ret = []
    from collections import deque
    queue = deque([root])
    while queue:
        ret_row = []
        # fixed size for current level
        for _ in range(len(queue)):
            node = queue.popleft()
            ret_row.append(node.val)
            if node.left:
                queue.append(node.left)
            if node.right:
                queue.append(node.right)
        ret.append(ret_row)
    return ret

N-ary Trees

We now extend our templates from handling Binary Trees to handling N-ary Trees. We use the following definition for the node of an N-ary Tree:

class Node:
    def __init__(self, val=None, children=[]):
        self.val = val
        self.children = children

To extend our iterative implementations to handle N-ary Trees, all we need to do is to make sure that we are appending the child nodes that we will visit in a correct order.

Recall that in pre-order traversal, we appended the right child before the left child. So when appending the children of a node of an N-ary Tree, we need to reverse the list of children.

def preorder(self, root):
    if not root:
        return []
    ret = []
    stack = [root]
    while stack:
        node = stack.pop()
        ret.append(node.val)
        # reverse the list of children
        for child in node.children[::-1]:
            stack.append(child)
    return ret

For the other traversal techniques, since we are appending the children from the left to the right, we can iterative over the list of children normally:

def postorder(self, root):
    if not root:
        return []
    from collections import deque
    ret = deque()
    stack = [root]
    while stack:
        node = stack.pop()
        ret.appendleft(node.val)
        for child in node.children:
            stack.append(child)
    return ret

def levelorder(self, root):
    if not root:
        return []
    ret = []
    from collections import deque
    queue = deque([root])
    while queue:
        ret_row = []
        # fixed size for current level
        for _ in range(len(queue)):
            node = queue.popleft()
            ret_row.append(node.val)
            for child in node.children:
                queue.append(child)
        ret.append(ret_row)
    return ret

And now we can apply our tree traversal templates to trees that have an arbitrary number of children at each node.

Conclusion

In this crash course on tree traversal, we learned four techniques: pre-order, post-order, in-order, and level-order. We discussed how they differ and what tasks they are best for.

We also implemented them both in a recursive fashion and in an iterative one. Last but not least, we extended the techniques to deal with not only Binary Trees, but N-ary Trees.

I hope now you feel more confident about tree traversal interview questions. This is also a nice segue into the topic of my next crash course on graph traversal.

With the knowledge of pre-order traversal and level-order traversal, DFS and BFS won't be completely out of the blue for you 🤓 I will even talk about how I applied graph traversal when developing an algorithm for my match-three game, Clicky Galaxy, so stay tuned!

Resources

Watch the course here:

Access the code template on my GitHub:

Check out the whole crash course series:

And lastly, feel free to subscribe to my YouTube channel for more content like this :)

I've carefully gone through over 50 resources, I've been through 10 JavaScript interviews, and I've landed a job at a unicorn startup.

And throughout this entire process, I started to see a pattern in the most frequently asked JS interview questions.

In this article, I have tried to list the concepts which will cover 80% of any good JS interview.

So, if you are prepping for your next JS interview this is the perfect cheatsheet for you to review and solidify your skills. Go through this and you'll be ready to rock. 💃

📝Prerequisites

• Basic knowledge of the web and programming
• Familiarity with HTML/CSS and JavaScript (especially ES6+ syntax)

Table Of Contents 📜

• JavaScript Basics – JS Variables and Array Methods
• Functional Programming in JavaScript – Scope, Closures, and Hoisting
• Objects in JavaScript – Prototypes and "this"
• Asynchronous JavaScript – Event Loops, Timers, and Promises
• Advanced JavaScript Concepts to Know - Async/defer, Polyfills, Debouncing, and Throttling
• Storage in JavaScript

Caveat: The focus here will largely be to cover concepts relevant to the interview and not to create a comprehensive booklet for learning the language. Treat this more like a cheatsheet.

If you want to dive in deeply and learn more JS concepts, check out freeCodeCamp's curriculum.

With that out of the way - let's go!

JavaScript Basics 👶

Let's start off with some basic concepts every JS developer needs to know.

Variables in JavaScript 📥

Variables are the building blocks of every programming language. You use them to store values. A variable can be a number, string, and many other types.

Now, JS is a loosely-typed language. You don't have to state the type of variable. You can just declare it, and JS will figure it out on its own.

Now, in JavaScript we have 3 ways to declare variables: var, let, and const.

Here are the key differences:

Let's try to understand them through examples.

We will cover scope later on. For now, let's focus on the other differences.

var a = 3
var a = 4

console.log(a) // 4 as var variables can be redeclared + updated

let b = 3
let b = 4

console.log(b) // Syntax Error as let variables cannot be redeclared

// If we just do, it will work because it can be updated
b = 4 

const c = 3
const c = 4

console.log(c) // Syntax Error as const variables cannot be redeclared or updated

const d

// Will this throw an error? Go through the table and try to find the answer.

Note: In JavaScript, putting a semi-colon after the end of statement is optional. I will be skipping it here for the sake of readability.

== vs === in JavaScript

Let's compare some variables. There are two ways you can do that.

== only checks for the value

=== checks for value + type

let a = 5 // number
let b = '5' // string

console.log(a == b) // true

console.log(a === b) // false

Arrays in JavaScript

Now that we know a bit about variables, let's move on to arrays and array-methods.

If we have declared a lot of variables, it makes sense to store them somewhere. Otherwise it will be difficult to keep track of all of them. Arrays are one way of storing a variable.

let a = 4
const b = 5
var c = 'hello'

const array = [a, b, c]

// or you can just directly do

const arr = [4,5,'hello']

But only storing variables in an array is kind of boring. We can do more stuff with this array (like accessing these variables or changing the order in which they are stored or how they are stored).

For that, JS has a lot of methods. Let's look at some of them now.

JavaScript Array Methods 🧰

The most frequently used array methods in JS are: map, filter, find, reduce, and forEach.

Let's cover map, filter, and forEach. You can explore more in this helpful article.

The map array method

map creates a new copy of the original array. We use it when we want to do something with the elements of the original array but don't want to change it.

map iterates over the original array and takes a callback function (which we'll cover later) as an argument. In the callback function, we tell it what to do with the elements.

const a = [1,2,3,4,5]

// Create a new array which multiplies every element by 2

const d = a.map(function(item){ return item*2 })

console.log(d) // [2,4,6,8,10]

The filter array method

filter creates a new array with elements that meet the given condition(s).

Let's look at an example. I have used arrow functions here. If you are a little uncomfortable with functions, you can cover the next section first and come back.

// Return the words with more than 6 letters
const words = ['react', 'script', 'interview', 'style', 'javascript']

const ans = words.filter((word) => word.length > 6)

console.log(ans) // ['interview', 'javascript']

Try to do the exercises yourself first to test your knowledge. If you come up with different or better solutions, let me know!

Generally, a follow up to this: can you do it without the array method?

let newArr = []

for (let i = 0; i < words.length; i++) {
  if (words[i].length > 6) {
    newArr.push(words[i])
  }
}
console.log(newArr)

The forEach array method

forEach is very similar to map but has two key differences:

First of all, map returns a new Array, but forEach doesn't.

// Return a new array where even numbers are multiplied by 2 
let arr = [1, 2, 3, 4, 5, 6, 7]

function consoleEven(arr) {
  let data = arr.map((num) => (num % 2 === 0 ? num * 2 : num * 1))

  console.log(data)  // [1,  4, 3, 8, 5, 12, 7]
}


// ? is the ternary operator. If the condition is true - first statement is returned otherwise the second one.


consoleEven(arr)

function consoleEven(arr) {
  let data = arr.forEach((num) => (num % 2 === 0 ? num * 2 : num * 1))
  console.log(data) // undefined
}

consoleEven(arr)

And second, you can do method chaining in map but not in forEach.

// Convert  the new array back to original

function consoleEven(arr) {
  let data = arr
    .map((num) => (num % 2 === 0 ? num * 2 : num * 1))
    .map((item) => (item % 2 === 0 ? item / 2 : item / 1))

  console.log(data)
}

consoleEven(arr)

Note: map and forEach don't mutate (change) the original array.

Functional Programming in JavaScript 🛠

We have already used functions above. Let's cover them in more detail now.

Just like how we used variables to store values, we can use functions to store a piece of code which we can reuse.

You can make function in two ways:

function a(){
 console.log('I am a normal function');
 }

const b = () => {
console.log('I am an arrow function')
}

// They are essentially the same but with a few differences which we will cover as we go along this tutorial. 

// We can pass variables as arguments

const c = (name) => {
console.log(`My name is ${name}`)
}

// `` template literal are a new addition to the language. Very useful for string formatting. Values are accessed using ${} inside them.


// We can even pass functions as arguments to a function. Will see more on this when we try to understand closures.

const greet = () =>  {
    const prefix = 'Mr'
    return (name) => {
        console.log(`${prefix} ${name}, welcome!`)
    }
}

console.log(greet()('Jack'))

Now, let's cover some important concepts related to functions.

Function Scope in JavaScript 🕵️

Scope determines from where the variables are accessible.

There are three types of scope:

• Global (declaration outside of any function)
• Function (declaration inside a function)
• Block (declaration inside a block)

Remember from before that var is globally scoped whereas let and const are block scoped. Let's understand that now.

var a = 5 // we can access this a anywhere

function adder(){
    let b = 7
    console.log(a + b)
 }

console.log(adder())

console.log(b) // Error as b is not accessible outside the function

{
const c = 10
console.log(c) // 10
}

console.log(c) // Error as c is not accessible outside the block

Closures in JavaScript (❗important) 🔒

We have already used a closure without even realizing it. In the example below, prefix is a closed-over-variable.

const greet = () =>  {
    const prefix = 'Mr'
    return (name) => {
        console.log(`${prefix} ${name}, welcome!`)
    }
}

console.log(greet()('Jack'))

This section will have a lot of fancy words, so bear with me. We will cover them one by one.

MDN says:

A function bundled together with its lexical environment forms a closure.

Okay, what is a lexical environment?

It is essentially the surrounding state – the local memory along with the lexical environment of its parent.

Whaaat? 🤯 I know it's a bit of a doozy. Let's understand it with a simple example.

function x() {
  var a = 7
  function y() {
    console.log(a)
  }
  return y
}

var z = x()
console.log(z) // [Function: y]
z()

When x is invoked, y is returned. Now, y is waiting to be executed. Kind of like a loaded gun waiting to be shot! 🔫

So, when we finally invoke z, y is invoked. Now, y has to log a so it first tries to find 🔍 it in the local memory but it's not there. It goes to its parent function. It finds a there.

Voila! There you have it - this is closure.

Even when functions are returned (in the above case y) they still remember their lexical scope (where it came from)

Totally unrelated quote for kicks 👻:

They may forget what you said - but they will never forget how you made them feel - Carl W. Buehner

I swear the rest of the article is legit 🤞 Keep reading.

Advantages of Closures in JavaScript 😎

• Currying

let add = function (x) {
  return function (y) {
    console.log(x + y)
  }
}

let addByTwo = add(2)
addByTwo(3)

• Data Hiding/Encapsulation

Suppose you want to create a counter application. Every time you call it, the count increases by 1. But you don't want to expose the variable outside the function. How to do it?

You guessed it – closures!

function Counter() {
  var count = 0
  this.incrementCount = function () {
    count++
    console.log(count)
  }
}

console.log(count) // Error: count is not defined
var adder = new Counter()
adder.incrementCount() // 1

Don't worry about this and new. We have a whole section devoted to them down below.

Disadvantages of Closures in JavaScript 😅

• Overconsumption of memory or memory leaks can happen.

For example, the closed-over-variable will not be garbage collected. This is because, even if the outer function has run, the returned inner function still has a reference to the closed-over-variable.

Note: Garbage collection basically removes unused variables from the memory automatically.

Hoisting in JavaScript 🚩

This is JavaScript's default behavior of moving declarations to the top of the program.

• var declaration is hoisted up and initialized with undefined.
• let and const declarations are hoisted up but not initialized.
• function definitions are also hoisted up and stored as they are.

Let's look at an example:

function consoleNum() {
  console.log(num)
  var num = 10
}

consoleNum() // undefined

// Why no error?

// This is how runtime sees this
{
  var num
  console.log(num)
  num = 9
}

// If instead of var -> let, it will give an error as let values are not initialized

Phew! I am done with functions here, but if you want more check out this amazing talk by Anjana Vakil on functional programming.

Objects in JavaScript 🔮

Just like arrays, objects are a way of storing data. We do so with the help of key-value pairs.

    const developer = {
        name: "Raj",
        age: 22
        }

name is the key and Raj is the value. Keys are generally the name of the properties of the object.

We can store all sorts of data like functions inside an object. You can explore more here on the MDN.

What is this in JavaScript?

Now, working with objects is different in JS than in other popular programming languages like C++. And to understand that properly, we need a good grasp of the this keyword.

Let's try to understand it step-by-step.

In a program, at times, we need a way to point at stuff. Like saying this function right here belongs to this object. this helps us get this context.

You will understand what I am saying better when we look at some examples.

For now, think of this as something which provides context. And remember this important thing: its value depends on how and where it is called.

I know, I know. A lot of this 😬. Let's go over all this slowly.

Start a new program and just log this.

console.log(this)

It will point to the window object.

Now, let's take an example with an object:

function myFunc() {
    console.log(this)     
  }

const obj = {
  bool: true,
  myFunc: myFunc,
}

obj.myFunc()

Now, this will point to the object. So what's happening here?

In the first example, we had nothing left of the . so it defaulted to the window object. But in this example, we have the object obj.

If you do:

myFunc() // window

We again get the window object. So, we can see that the value of this depends on how and where are we doing the calling.

What we just did above is called Implicit Binding. The value of this got bound to the object.

There is another way to use this. Explicit binding is when you force a function to use a certain object as its this.

Let's understand why we need explicit binding through an example.

const student_1 =  {
    name: 'Randall',
    displayName_1: function displayName() {
        console.log(this.name)
    }
}
const student_2 =  {
    name: 'Raj',
    displayName_2: function displayName() {
        console.log(this.name)
    }
}

student_1.displayName_1()
student_2.displayName_2()

We are using this properly, but can you see the problem with the above code?

We are repeating code. And one of the principles of good programming is keep your code DRY! (Don't Repeat Yourself)

So, let's get rid of displayName_2 and simply do:

student_1.displayName_1.call(student_2) // Raj

call forced displayName_1 to use the second object as its this.

There are a lot of other ways we can do this.

Try to solve the given problem yourself.

const myData = {
  name: 'Rajat',
  city: 'Delhi',
  displayStay: function () {
    console.log(this.name, 'stays in', this.city)
  },
}
myData.displayStay()

// create an object yourData and try to use displayStay
const yourData = {
 name: 'name',
 city: 'city'
}


// answer
myData.displayStay.call(yourData)

Finally, remember that I said that there are differences between arrow and regular functions.

The case of this is one of them.

For an arrow function, the value depends on the lexical scope – that is to say, the outer function where the arrow function is declared.

So, if we make the displayName() from above an arrow function, nothing will work.

Arrow functions basically inherit the parent's context which in the above case is the window.

Prototypes and Prototypal Inheritance in JavaScript 👪

Whenever we create anything (like an object or function) in JavaScript, the JS Engine automatically attaches that thing with some properties and methods.

All this comes via prototypes.

__proto__ is the object where JS is putting it all.

Let's see some examples. Fire up your consoles!

let arr = ['Rajat', 'Raj']
console.log(arr.__proto__.forEach)
console.log(arr.__proto__) // same as Array.prototype
console.log(arr.__proto__.__proto__) // same as Object.prototype
console.log(arr.__proto__.__proto__.__proto__) // null

All this is called a prototype chain.

We can do the same with objects and functions as well.

We will always find Object.prototype behind the scenes. That's why you may have heard that everything in JS is an object. 🤯

What is Prototypal Inheritance in JavaScript?

let object = {
  name: 'Rajat',
  city: 'Delhi',
  getIntro: function () {
    console.log(`${this.name}, ${this.city}`)
  },
}

let object2 = {
  name: 'Aditya',
}

Note: Don't modify prototypes this way. It's just for understanding. Here's the right way to do it.

object2.__proto__ = object

By doing this, object2 gets access to the object's properties. So, now we can do:

console.log(object2.city)

This is prototypal inheritance.

Asynchronous JavaScript ⚡

So, JS is a single-threaded language. Things happen one at a time. Only after one thing is done can we move to the next thing.

But this creates problems in the real world, especially, when we are working with browsers.

For example, when we need to fetch data from the web - often times we don't know how long will it take to get it. And whether we will be able to get the data successfully.

To help with this, asynchronous JS comes into play.

And the most important concept to understand is the event loop.

Event Loops in JavaScript ➰

Instead of providing a half-baked explanation here, I highly recommend watching this video by Philip Roberts if you haven't already:

Learn all about event loops in JS here.

Timers in JavaScript – setTimeout, setInterval, clearInterval ⏱️

I hope you watched the video. It mentioned timers. Let's talk about them more now. These are very frequently asked about in interviews.

The setTimeout() method calls a function or evaluates an expression after a specified number of milliseconds.

setInterval() does the same for specified intervals.

setTimeout(() => {
    console.log('Here - I am after 2 seconds')
}, 2000);

const timer = setInterval(() => {
    console.log('I will keep on coming back until you clear me')
}, 2000);

You use clearInterval() to stop the timer.

clearInterval(timer)

Let's go over some questions that use these concepts.

  console.log('Hello')
  setTimeout(() => {
    console.log('lovely')
  }, 0)
  console.log('reader')

  // output
  Hello
  reader
  lovely

Here's a slightly trickier one:

  for (var i = 1; i <= 5; i++) {
    setTimeout(function () {
      console.log(i)
    }, i * 1000)
  }

// output
6
6
6
6
6

And here's a short explanation of what's going on there: when setTimeout comes again into the picture, the entire loop has run and the value of i has become 6,

Now, let's say we want the outcome to be 1 2 3 4 5 – what do we do?

Instead of var ➡️ use let.

Why this will work?

var is globally scoped but let is locally scoped. So for let a new i is created for every iteration.

Promises in JavaScript (❗important) 🤝

Promises are at the heart of Asynchronous JS.

The Promise object represents the eventual completion (or failure) of an asynchronous operation and its resulting value.

A promise can be in one of these three states:

• Pending: initial state, neither fulfilled nor rejected
• Fulfilled: operation was completed successfully
• Rejected: operation failed

const promise = new Promise((resolve, reject) => {
  let value = true
  if (value) {
    resolve('hey value is true')
  } else {
    reject('there was an error, value is false')
  }
})

promise
  .then((x) => {
    console.log(x)
  })
  .catch((err) => console.log(err))

Note: resolve and reject are just conventional names. Call it pizza🍕 if you like.

Instead of then/catch, we can also use async/await:

async function asyncCall() {
  const result = await promise
  console.log(result)
}

asyncCall()

One of the advantages of promises is that they are a much cleaner syntax. Before we had promises, we could easily get stuck in callback hell 🌋

Advanced JavaScript Concepts to Know

📚 Polyfills in JavaScript

A polyfill is a piece of code (usually JavaScript on the Web) used to provide modern functionality on older browsers that do not natively support it. MDN

• Let's implement it for map:

// this - array
// this[i] - current value
Array.prototype.myMap = function (cb) {
  var arr = []
  for (var i = 0; i < this.length; i++) {
    arr.push(cb(this[i], i, this))
  }
  return arr
}

const arr = [1, 2, 3]
console.log(arr.myMap((a) => a * 2)) // [2, 4, 6]

Notice how we use this. Here, we have basically created a new array and are adding values to it.

Async and defer in JavaScript ✔️

These concepts are frequently asked about in interviews by big corporations like Amazon, Walmart, and Flipkart. 🏢

To understand async and defer, we need to have an idea of how browsers render a webpage. First, they parse the HTML and CSS. Then DOM trees are created. From these, a render tree is created. Finally, from the render tree - a layout is created and the painting happens.

For a more detailed look, check out this video.

Async and defer are boolean attributes which can be loaded along with the script tags. They are useful for loading external scripts into your web page.

Let's understand with the help of pictures.

If there are multiple scripts which are dependant on each other, use defer. Defer script are executed in the order which they are defined.

If you want to load external script which is not dependant on the execution of any other scripts, use async.

Note: The async attribute does not guarantee the order of execution of scripts.

Debouncing in JavaScript ⛹️‍♂️

Debouncing is another favorite topic of interviewers.

Let's understand it by creating a search bar.

Demo: https://codesandbox.io/s/debounce-input-field-o5gml

Create a simple input field in index.html like this:

<input type='text' id='text' />

Now, in index.js. Don't forget to add it to index.html first:

const getData = (e) => {
  console.log(e.target.value)
}
const inputField = document.getElementById('text')

const debounce = function (fn, delay) {
  let timer
  return function () {
    let context = this
    clearTimeout(timer)
    timer = setTimeout(() => {
      fn.apply(context, arguments)
    }, delay)
  }
}

inputField.addEventListener('keyup', debounce(getData, 300))

First, we have selected the input and added an event listener to it. Then we created a debounce function which takes a callback function and delay.

Now, inside the debounce function we create a timer using setTimeout. Now, this timer's job is to make sure that the next call for getData only happens after 300 ms. This is what debouncing is.

Also, we use clearTimeout to remove it. Don't want too many of them hanging out there taking up memory space!

Phew! Lots of theory. Let's do a fun challenge. You must have seen the countdown before a game starts (it goes like 10, 9, 8, .... with some delay in between). Try to write a program for it.

Here's how you'd do it:

let count = 10

for (let i = 0; i < 10; i++) {
  function timer(i) {
    setTimeout(() => {
      console.log(count)
      count--
    }, i * 500)
  }
  timer(i)
}

Were you able to solve it? Did you do it differently? Let me know your solution.

Throttling in JavaScript 🛑

Let's look at an example again. Suppose that on every window resize event we call an expensive function. Now, we want it such that the expensive function will only be executed once in the given time interval. This is what throttling is.

Create an index.html and an index.js with the following code:

const expensive = () => {
  console.log('expensive')
}

const throttle = (fn, limit) => {
  let context = this
  let flag = true
  return function () {
    if (flag) {
      fn.apply(context, arguments)
      flag = false
    }
    setTimeout(() => {
      flag = true
    }, limit)
  }
}
const func = throttle(expensive, 2000)
window.addEventListener('resize', func)

Almost the same as debouncing. The key difference is the flag variable. Only, when it's true we are invoking the callback function. And it is set to true inside the setTimeout. So the value is true only after the desired time limit.

So, what's the difference between debounce and throttling❓

Let's take the search bar 🔍 example from above. When we are debouncing the input field, we are saying to only fetch the data when the difference between two keyup events is at least 300 ms.

In the case of throttling, we make a function call only after a certain period of time.

Suppose that you are searching for an encyclopedia in the search bar. The first call is made on e and it took us 300 ms to reach p. The next call will be made then only. All the events in between will be ignored.

So, to summarize, debouncing is when the difference between two keyup events is 300 ms. And throttling is when the difference between two function calls is 300 ms. Basically, the function is called after a certain interval of time.

Storage in JavaScript 💾

Finally, a small but important topic to wrap things up.

localStorage: Data persists even after closing your session

sessionStorage: You lose your data when your session is over, like when you close the browser on the tab.

// save
localStorage.setItem('key', 'value')
// get saved data
let data = localStorage.getItem('key')
// remove saved data
localStorage.removeItem('key')
// Same for sessionStorage

And we are done! 🏁 I hope you feel more confident about your next JS interview now. I wish you all the best.

If you have any queries / suggestions / feedback, you can reach me on Twitter: https://twitter.com/rajatetc.

🗃️ Main References

• MDN Docs
• Akshay Saini
• Coding Addict
• Javascript_Interviews

In it, we will learn about an all-purpose coding template for solving backtracking problems and apply it to two LeetCode hard problems. Ready to crunch your next coding interview? Let's go!

If you just want to dive right in, you can find the course here (and linked at the bottom of this article). If you want a little more info, read on. :)

Who is the Course for and What is the Backtracking Algorithm?

This course is suitable for anyone who is preparing for coding interviews, especially those who are looking to hone their skills in solving backtracking problems.

Backtracking is a common category for questions in coding interviews. The algorithm for solving those problems usually involves recursion and building incrementally on previous states to arrive at the ultimate valid solution.

Backtracking is a favorite topic among top tech companies like Google, Microsoft, and Facebook, precisely because it requires robust reasoning and coding competence to nail those questions.

However, because of its recursive nature and complex problem definition, backtracking problems are usually a major source of confusion among devs who are preparing for coding interviews.

To address this confusion, this crash course aims to arm with you a concise, 20-line template that you can apply to the majority of backtracking problems.

Course Outline

This course runs for a total of 40 minutes and the structure is as follows:

• An 8-minute introduction to the template

• A 15-minute hands-on code-along session for LeetCode Question 51. N-Queens

• A 15-minute hands-on code-along session for LeetCode Question 37. Sudoku Solver

The All-Purpose Template

For your convenience, I've copied the template over. This is exactly the same template that I use for my coding interviews, or when I'm developing algorithms for my indie games. I even used it once in my research on a non-convex optimization problem.

def is_valid_state(state):
    # check if it is a valid solution
    return True

def get_candidates(state):
    return []

def search(state, solutions):
    if is_valid_state(state):
        solutions.append(state.copy())
        # return

    for candidate in get_candidates(state):
        state.add(candidate)
        search(state, solutions)
        state.remove(candidate)

def solve():
    solutions = []
    state = set()
    search(state, solutions)
    return solutions

The first three are all helper functions, and the last and most important one, solve, is essentially the one that a LeetCode problem is asking you to write.

Solving LeetCode Problems Hands-On

We will next apply this template to solving two LeetCode hard problems: LeetCode Question 51. N-Queens and LeetCode Question 37. Sudoku Solver.

To illustrate the flexibility of the template, see below for how we solve the N-Queens problem by doing nothing fancy other than adapting the four functions (renaming solve to solveNQueens). The complete code for either problem is available in my GitHub gist.

Watch the video course to follow along my analysis and adaptation of the template.

class Solution:
    # solveNQueens is essentially the solve function
    def solveNQueens(self, n: int) -> List[List[str]]:
        solutions = []
        state = []
        self.search(state, solutions, n)
        return solutions

    def is_valid_state(self, state, n):
        # check if it is a valid solution
        return len(state) == n

    def get_candidates(self, state, n):
        if not state:
            return range(n)

        # find the next position in the state to populate
        position = len(state)
        candidates = set(range(n))
        # prune down candidates that place the queen into attacks
        for row, col in enumerate(state):
            # discard the column index if it's occupied by a queen
            candidates.discard(col)
            dist = position - row
            # discard diagonals
            candidates.discard(col + dist)
            candidates.discard(col - dist)
        return candidates

    def search(self, state, solutions, n):
        if self.is_valid_state(state, n):
            state_string = self.state_to_string(state, n)
            solutions.append(state_string)
            return

        for candidate in self.get_candidates(state, n):
            # recurse
            state.append(candidate)
            self.search(state, solutions, n)
            state.pop()

Check out the video course here:

You can access the template as well as the solutions to the two LeetCode problems (N-Queens and Sudoku Solver) in my GitHub gist:

Final Thoughts

Remember that practice makes perfect, so do try applying this template to more backtracking problems on LeetCode. Best of luck crunching your next coding interview!

For more content like this, check out my YouTube channel:

Technical interviews are one of the most stressful parts of landing a job in tech.

You don't know what questions the interviewer is going to ask. What if you have no idea how to solve the problem in front of you? What if you freeze up and look like you don't know what you're doing?

Many aspiring programmers work themselves up into a frenzy as they try to memorize every coding interview question. You and I both know this approach is unsustainable. I'm here to tell you there's an easier way.

I recently sat down with my friend Michelle, who's a senior software engineer at Stitch Fix (a recently IPO'd company). She shared the kinds of qualities she looks for in developers that she interviews.

Honestly, the qualities might surprise you. I promise they don't include memorizing coding interview questions and solutions.

The rest of this article will unpack the qualities Michelle looks for in developer candidates. I'll translate each of these qualities into key interview behaviors. Then I'll tell you how you can implement them in your own interviews. Let's get started.

Qualities you should have going into the coding interview

When I sat down with Michelle, a part of me imagined I was getting a secret code to cracking the coding interview. I thought I'd hear the ultimate algorithm to solving every problem out there.

While we know a universal algorithm doesn't exist, she did share something even better: how to create a mental a framework for interviewing.

Success is not about memorizing every problem and solution. Rather, it's about learning how to solve problems.

As a developer, there won't be a cookie-cutter LeetCode type of answer. This is where mental frameworks are incredibly helpful. They create just enough problem solving certainty to overcome a seemingly ambiguous problem.

Here are Michelle's key components to building a killer mindset framework for your coding interview.

Be curious

One of Michelle's biggest tips for developer candidates is to be curious. Clarify the problem and ask questions. Share any thoughts you have on the problem you're facing. Interviewers aren't just looking for the right solution. They want to see how you think.

The best way you can show how you think is by asking questions. Let's say an interviewer asks you to check if a string contains any digits. You should clarify the question in your own words, something like:

"So I need to find a way to verify if a set of characters contains any numbers?"

When you say this you're giving interviewers insight into your logic. You're also showing them you're interested in the problem.

And don't be afraid to ask follow-up questions. Using the same example above, here are a few questions you can ask:

"Do the numbers I'm looking for contain decimals?"

"Do I need to sort the characters in any way before checking them?"

Be open to suggestions

One thing that is easy to forget is that interviewers want you to succeed. Most interviewers want to provide real-time feedback and suggestions to candidates. But candidates often take a non-verbal, siloed approach to the coding interview.

One way you can be more open to suggestions is by engaging your interviewer. Verbalize your logic and take them along your problem solving journey.

We'll use the same problem as above. Here are a few ways you can verbalize your logic from the get-go:

"So I'll need to establish a way to separate characters from numbers, right?"

"I'm thinking about iterating through the set of characters from end to end."

"I want a programmatic way to iterate through characters, but stop at numbers."

The more insight you can provide, the more your interviewer will feel inclined to help.

Work collaboratively

This goes hand in hand with the above. The idea that a developer works siloed and alone is a myth. You have version control and project management tools that require collaboration.

You should verbalize your approach, ask great questions, and loop your interviewer in. You'll arrive at the solution much more quickly. But you'll also show your interviewer you can effectively collaborate with other developers.

Here are a few ways you can loop your interviewer in:

"Would a for loop be too simple/complex for this solution?"

"How important is it to establish if there are floats or not?"

"Is there any type of solution you have in mind?"

Be willing to just go for it

Finally, Michelle suggested that developer candidates should just go for it. Meaning, go for the success you want to see.

One of the most common occurrences for candidates is that they freeze up. While this is understandable, no one wins in this situation. You can't show how incredible you are and the interviewer can't help you. Here's what Michelle said to "just go for it":

Even if you have to pseudocode your implementation, that’s better than being too nervous to try. Putting something on the board/coderpad will invite discussion, a chance to share your thoughts, and an opportunity to learn.

Don’t be afraid to fail! It just means you’re one step closer to succeeding. :)

"Just go for it" can mean a lot of things. That said, here are a few examples of what that can look like:

• Write pseudocode on the whiteboard, paper, or coderpad
• Note exactly where you are stuck in your logic
• Verbalize the solution you wish you could come up with

Use the Mindset Framework to Ace Your Coding Interview!

Coding interviews can be scary and there's always the fear that you'll freeze up. Part of this fear stems from not knowing which questions will show up.

The great thing is that you no longer have to memorize coding questions and solutions. Instead, build a mindset framework with the key interview behaviors you read about today.

You want to be curious and open to suggestions. You should work in collaboration with your interviewer. Be willing to go for the success you want to see. Happy interviewing!

If you want to see more of this type of content, subscribe to my newsletter at Course to Hire. I'll help you learn how to code and break into tech. Feel free to add me on LinkedIn as well.

P.S. – if you're interested in connecting with Michelle, ping me on Course to Hire or LinkedIn and I can make the intro.

I had fifteen minutes left, and I knew I was going to fail.

I had spent two months studying for my first technical interview.

I thought I was prepared, but as the interview came to a close, it hit me: I had no idea how to solve coding problems.

Of all the tutorials I had taken when I was learning to code, not one of them had included an approach to solving coding problems.

I had to find a method for problem-solving—my career as a developer depended on it.

I immediately began researching methods. And I found one. In fact, what I uncovered was an invaluable strategy. It was a time-tested four-step method that was somehow under the radar in the developer ecosystem.

In this article, I’ll go over this four-step problem-solving method that you can use to start confidently solving coding problems.

Solving coding problems is not only part of the developer job interview process—it’s what a developer does all day. After all, writing code is problem-solving.

A method for solving problems

This method is from the book How to Solve It by George Pólya. It originally came out in 1945 and has sold over one million copies.

His problem-solving method has been used and taught by many programmers, from computer science professors (see Udacity’s Intro to CS course taught by professor David Evans) to modern web development teachers like Colt Steele.

Let’s walk through solving a simple coding problem using the four-step problem-solving method. This allows us to see the method in action as we learn it. We'll use JavaScript as our language of choice. Here’s the problem:

Create a function that adds together two numbers and returns that value.

There are four steps to the problem-solving method:

1. Understand the problem.
2. Devise a plan.
3. Carry out the plan.
4. Look back.

Let’s get started with step one.

Step 1: Understand the problem.

When given a coding problem in an interview, it’s tempting to rush into coding. This is hard to avoid, especially if you have a time limit.

However, try to resist this urge. Make sure you actually understand the problem before you get started with solving it.

Read through the problem. If you’re in an interview, you could read through the problem out loud if that helps you slow down.

As you read through the problem, clarify any part of it you do not understand. If you’re in an interview, you can do this by asking your interviewer questions about the problem description. If you’re on your own, think through and/or Google parts of the question you might not understand.

This first step is vital as we often don’t take the time to fully understand the problem. When you don’t fully understand the problem, you’ll have a much harder time solving it.

To help you better understand the problem, ask yourself:

What are the inputs?

What kinds of inputs will go into this problem? In this example, the inputs are the arguments that our function will take.

Just from reading the problem description so far, we know that the inputs will be numbers. But to be more specific about what the inputs will be, we can ask:

Will the inputs always be just two numbers? What should happen if our function receives as input three numbers?

Here we could ask the interviewer for clarification, or look at the problem description further.

The coding problem might have a note saying, “You should only ever expect two inputs into the function.” If so, you know how to proceed. You can get more specific, as you’ll likely realize that you need to ask more questions on what kinds of inputs you might be receiving.

Will the inputs always be numbers? What should our function do if we receive the inputs “a” and “b”? Clarify whether or not our function will always take in numbers.

Optionally, you could write down possible inputs in a code comment to get a sense of what they’ll look like:

//inputs: 2, 4

Next, ask:

What are the outputs?

What will this function return? In this case, the output will be one number that is the result of the two number inputs. Make sure you understand what your outputs will be.

Create some examples.

Once you have a grasp of the problem and know the possible inputs and outputs, you can start working on some concrete examples.

Examples can also be used as sanity checks to test your eventual problem. Most code challenge editors that you’ll work in (whether it’s in an interview or just using a site like Codewars or HackerRank) have examples or test cases already written for you. Even so, writing out your own examples can help you cement your understanding of the problem.

Start with a simple example or two of possible inputs and outputs. Let's return to our addition function.

Let’s call our function “add.”

What’s an example input? Example input might be:

// add(2, 3)

What is the output to this? To write the example output, we can write:

// add(2, 3) ---> 5

This indicates that our function will take in an input of 2 and 3 and return 5 as its output.

Create complex examples.

By walking through more complex examples, you can take the time to look for edge cases you might need to account for.

For example, what should we do if our inputs are strings instead of numbers? What if we have as input two strings, for example, add('a', 'b')?

Your interviewer might possibly tell you to return an error message if there are any inputs that are not numbers. If so, you can add a code comment to handle this case if it helps you remember you need to do this.

// return error if inputs are not numbers.

Your interviewer might also tell you to assume that your inputs will always be numbers, in which case you don’t need to write any extra code to handle this particular input edge case.

If you don’t have an interviewer and you’re just solving this problem, the problem might say what happens when you enter invalid inputs.

For example, some problems will say, “If there are zero inputs, return undefined.” For cases like this, you can optionally write a comment.

// check if there are no inputs.

// If no inputs, return undefined.

For our purposes, we’ll assume that our inputs will always be numbers. But generally, it’s good to think about edge cases.

Computer science professor Evans says to write what developers call defensive code. Think about what could go wrong and how your code could defend against possible errors.

Before we move on to step 2, let’s summarize step 1, understand the problem:

-Read through the problem.

-What are the inputs?

-What are the outputs?

Create simple examples, then create more complex ones.

2. Devise a plan for solving the problem.

Next, devise a plan for how you’ll solve the problem. As you devise a plan, write it out in pseudocode.

Pseudocode is a plain language description of the steps in an algorithm. In other words, your pseudocode is your step-by-step plan for how to solve the problem.

Write out the steps you need to take to solve the problem. For a more complicated problem, you’d have more steps. For this problem, you could write:

// Create a sum variable.

Add the first input to the second input using the addition operator.

// Store value of both inputs into sum variable.

// Return as output the sum variable.

Now you have your step-by-step plan to solve the problem.

For more complex problems, professor Evans notes, “Consider systematically how a human solves the problem.” That is, forget about how your code might solve the problem for a moment, and think about how you would solve it as a human. This can help you see the steps more clearly.

3. Carry out the plan (Solve the problem!)

The next step in the problem-solving strategy is to solve the problem. Using your pseudocode as your guide, write out your actual code.

Professor Evans suggests focusing on a simple, mechanical solution. The easier and simpler your solution is, the more likely you can program it correctly.

Taking our pseudocode, we could now write this:

function add(a, b) {
 const sum = a + b;
 return sum;
}

Professor Evans adds, remember not to prematurely optimize. That is, you might be tempted to start saying, “Wait, I’m doing this and it’s going to be inefficient code!”

First, just get out your simple, mechanical solution.

What if you can’t solve the entire problem? What if there's a part of it you still don't know how to solve?

Colt Steele gives great advice here: If you can’t solve part of the problem, ignore that hard part that’s tripping you up. Instead, focus on everything else that you can start writing.

Temporarily ignore that difficult part of the problem you don’t quite understand and write out the other parts. Once this is done, come back to the harder part.

This allows you to get at least some of the problem finished. And often, you’ll realize how to tackle that harder part of the problem once you come back to it.

Step 4: Look back over what you've done.

Once your solution is working, take the time to reflect on it and figure out how to make improvements. This might be the time you refactor your solution into a more efficient one.

As you look at your work, here are some questions Colt Steele suggests you ask yourself to figure out how you can improve your solution:

• Can you derive the result differently? What other approaches are there that are viable?
• Can you understand it at a glance? Does it make sense?
• Can you use the result or method for some other problem?
• Can you improve the performance of your solution?
• Can you think of other ways to refactor?
• How have other people solved this problem?

One way we might refactor our problem to make our code more concise: removing our variable and using an implicit return:

function add(a, b) {
 return a + b;
}

With step 4, your problem might never feel finished. Even great developers still write code that they later look at and want to change. These are guiding questions that can help you.

If you still have time in an interview, you can go through this step and make your solution better. If you are coding on your own, take the time to go over these steps.

When I’m practicing coding on my own, I almost always look at the solutions out there that are more elegant or effective than what I’ve come up with.

Wrapping Up

In this post, we’ve gone over the four-step problem-solving strategy for solving coding problems.

Let's review them here:

• Step 1: understand the problem.
• Step 2: create a step-by-step plan for how you’ll solve it.
• Step 3: carry out the plan and write the actual code.
• Step 4: look back and possibly refactor your solution if it could be better.

Practicing this problem-solving method has immensely helped me in my technical interviews and in my job as a developer.

If you don't feel confident when it comes to solving coding problems, just remember that problem-solving is a skill that anyone can get better at with time and practice.

Good luck!

If you enjoyed this post, join my coding club, where we tackle coding challenges together every Sunday and support each other as we learn new technologies.

If you have feedback or questions on this post, feel free to Tweet me @madisonkanna.

In my last article, I shared my thoughts on how to get an interview as a software developer. This week, I will share my thoughts on how you should prepare for that interview once you get it.

Tech interviews are notoriously nerve-racking and unpredictable. But there are steps you can take to mitigate a lot of these feelings.

Phases of the interview process

Most software development interviews have a similar structure - it's kind of like the modern foundation for these interviews.

You'll typically find the following phases in your interview process:

• Phone screen
• Technical phone interview
• On-site

Let's look at each of these in a bit more depth.

What questions should I expect?

Interviews in the tech industry are far from uniform, but I like to think of that as a positive thing. This keeps things interesting and can allow you to show off your skills in a new way each time.

This includes the questions that you will most likely be asked in your interview, but don't worry. There are lots of common questions that will help you be prepared for your big day.

From my perspective, these questions can be broken down into two categories, company-specific and situational (hypothetical).

Company-specific questions

Depending on the size and type of company you are interviewing at, the way they interview might differ. I suggest you use websites such as Blind or Glassdoor to gain insight into company-specific interview topics and questions.

As an example, The Interview Guys put together a great article that discusses Amazon's top interview questions.

If you spend a little bit of time searching around on the web, you should be able to find some questions that a certain company traditionally asks. This will give you a leg up on your preparation.

Situational (hypothetical) questions

You can expect these questions to touch on your work style, recent achievements, and your technical competency. A few topics that you can expect to be asked about are:

• Tell me about a time that you had to deal with a tricky bug. How did you fix it? What was the outcome?
• Do you prefer to work by collaborating (pairing) with others or on your own?
• What do you like about the programming language you use?
• Which new features of the language do you use most and why?
• Describe your team’s typical workflow for a project. What do you like about it? What don’t you like about it?

Remember, stay positive as much as you can. Although the interviewer is genuinely interested in your responses, they are also looking for any signs of negativity or difficulty you might bring into their current team dynamic.

Try to avoid talking down about a particular piece of technology you have used in the past. Instead, spin your response in a positive way.

For example, instead of saying “I don’t like using the spread operator in JavaScript, it’s too confusing”, you can say, “I know the spread operator is a newer feature of JavaScript, I look forward to learning more about it and how to use it efficiently in my code.”

Now that you have a good idea of what some common questions are and some elements to include in your responses, let's dive into each step in the interview process. The first step is the phone screen.

First things first, "tell me about yourself"

After you apply and a company has an interest in you, the first step is usually to schedule a phone interview. This is typically a pretty relaxed conversation with a member of HR.

You can expect them to ask primarily about your job history, what you are looking for next, and most importantly, why you are applying for a position at their company.

Just because this is typically easier than the other phases of the interview process does not mean you should not prepare for it. A few questions to prepare for are:

Tell me a little bit about yourself

This is a good time to give your “elevator pitch”. This will likely be one of the first questions you are asked and usually can be a great tone-setter for the remainder of the interview.

If you tend to talk fast, take a deep breath before you answer and try to speak slowly and clearly. A few items you want to mention in your response are:

• Ethos or interests you share with the company
• What excites you about software development
• Future goals that (hopefully) this company can help fulfill (that is, technical and professional growth)

What is a recent project you worked on that you are proud of?

Like most of these questions, the interviewer is not solely curious about your technical achievements. They are also looking for cues that convey you can communicate well, are reliable, and are someone who would get along with the other members of the team.

Try to be enthusiastic and answer questions fully, without rambling too much. An effective framework for answering these types of questions is:

• Give a quick overview of what the project is and the problem it solves
• Mention the technologies you used in this project
• Communicate any metrics that demonstrate any positive impact (like time-saving metrics, open-source contributors, number of active users)

Why are you looking to leave your current company?

This might be one of the trickier questions to answer. Make sure you have a solid answer for this one prepared prior to the interview, as it can tell a lot about a candidate pretty quickly.

Here are a few things you should avoid when answering this question:

• Being negative. Turn any potentially negative factor into a positive one. For example, “I am bored and unsatisfied with the work I do here” can be said instead like, “I am looking for a new challenge that cultivates my growth as a developer and an individual”.
• Talking about current coworkers or managers – keep them out of the conversation
• Discussing compensation and benefits

I think one of the best answers you can give to this question is an honest one – you are looking for something new. That is a perfectly reasonable answer!

The only pieces I might add to this response are your interest in new challenges, enthusiasm for the company, or a piece of technology that you know this company uses.

How to prepare for the technical phone interview

Ok, you were enthusiastic, personable, and well prepared for your phone interview. The next step in this process is generally a technical phone interview.

Before your technical phone interview, it's important to make sure you know which programming language you will use.

Which programming language should I use?

Before you start preparing for the other steps of the interview process, it would be prudent to have a good idea of which programming language you will use during the interview.

When it comes to this question, I have some pretty simple advice: embrace what you are comfortable with, and stick to what you know.

It is fairly common to want to use (or learn) multiple languages in our field. But, when preparing for an interview, it is best to stick with just one.

This will help shift your focus from worrying about which language you will use, to thinking of problems you have solved with the language you are most comfortable with.

Once you know which programming language you will use, you are ready to take on the challenge of the technical phone interview.

Discussing technical achievements and high-level programming topics

In a typical technical phone interview, you'll have a conversation with a senior member of the team you would join or with the manager of that team. You can expect a lot of this conversation to be focused on two things:

• Recent problems you have experienced in your current position and the solutions you implemented for them, and
• General language familiarity (such as when would you want to use an array instead of a hash table (object)?)

To help prepare for this interview, I suggest you start to write down answers to these questions.

Personally, I have used an Excel or Google sheet document that consists of 3 columns: questions, answers, and notes. You will find that taking the action of writing your answers down will help you come up with a concise and impactful answer.

There are a lot of resources online that list common interview questions, for frontend, backend, or full-stack roles.

This might seem like a lot of work upfront, but trust me – spending the time to prepare and convert your thoughts to pen and paper will really help you mentally flesh out your answers.

Okay, you've spent ample time preparing and you impressed your interviewer! The next step you can expect is the "on-site" interview.

What is the on-site interview all about?

The final stage of the interview process is usually referred to as the on-site. This is often the most in-depth and the most important to perform well at.

One of the main questions the company would like to have a good answer for is, how does this person work? The answer to this question is usually echoed through multiple levels as well, personal, technical, and professional.

Companies seek this answer by giving the candidate various exercises, technical and interpersonal, to gauge your skills and how well you will fit in at their company.

Depending on the company this interview can include various elements, but a few that are most common are:

• Pair programming
• Take-home assignments
• Whiteboarding

Excel during your pair programming session

One of the most common methods of gauging your skills is to pair program with a member of the team you might work with.

This session is usually 20 to 30 minutes and the problem you are given is generally something you will see on the job at this company.

There are a few things to keep in mind if you have a session like this:

• Try to stay calm and remember that you are interviewing here for a reason, they like you and see promise in you.
• Communicate out loud as much as possible, even if you think you are talking too much. It’s better to over-communicate in these exercises than to sit in silence typing away at the keyboard.
• Don’t be afraid to ask questions, they’re on your side! The interviewer has probably left out critical details on purpose to test your communication skills while working with other developers.

Ultimately, try and be conscious of the fact that this company sees promise in you on a personal and technical level. Be yourself and be confident!

If the company does not have a pair programming exercise included in their process, another common exercise is to give you a project or a collection of problems to solve on your own.

Crush your take-home assignment

If the company wants to gauge your work through the lens of how you work as an individual, they might ask you to complete a take-home assignment.

These can range from completing timed exercises on HackerRank to completing a small project with written instructions from the interviewer themselves.

Regardless of the style of take-home assignment, there are a few things I think you should keep in mind to increase your chances of success:

• Ensure you are in a distraction-free area for the entire allotted time
• Put any distraction-prone devices away
• Read all instructions to the problem(s), and then read them again

If your assignment is timed and you do not think you will have enough time to finish, write comments throughout the assignment with what your next steps would be if you had more time.

To be honest, a lot of these assignments are supposed to take longer than the scheduled time to complete.

The interviewer is always primarily focused on how you communicate, not that you can write code the fastest, or solve every algorithm you see.

Conquer the whiteboard exercise

Sometimes a company would prefer to take a look at your technical skills and ability to break down complex problems in more of an abstract way. The most common way of testing a candidate this way is by having them complete a whiteboard exercise.

This method of interviewing might be the most talked about, and the most feared. If you are asked to use a whiteboard to solve a question remember this: they are (usually) far more interested in how you communicate your problem-solving process, not that you can solve the problem.

If the problem they give you seems really hard, that is not because they are trying to stump you. They want to get a feel for how you tackle a hard problem. If you don’t end up solving the problem, that does not mean you blew your chance.

If you keep these things in mind during this exercise, it will increase your chances of impressing your interviewer:

• Repeat the question back to the interviewer
• Ask clarifying question about edge cases
• Confirm optimal results of the problem
• Write your code legibly
• Communicate each step you take

If you answered the question successfully by the time the session ends, ask your interviewer if that was the solution they commonly got. If not, ask what other candidates have done or what you could have done differently. This shows that you are engaged and curious.

If you did not answer the question successfully, write comments throughout the code about where you might continue to find the solution if you had more time. Again, a lot of these sessions are not focused solely on getting the “right” answer, but to get a good idea of how you approach new problems.

Practice interviewing, without the pressure

As I mentioned earlier, interviews are tough and can be hard to prepare for. However, I am a firm believer that the best way to ensure a higher chance of success is to practice, practice, practice.

Have you ever practiced a big presentation for school in front of friends or family? You might have still been nervous but, it sure does help you feel more comfortable speaking about your topic.

Interviewing is also a presentation, and the concept of practice runs are just as important. In the 2020 world, most interviews are completed remotely, which makes performing mock interviews feel more real.

If you know someone who is currently in the software industry, I would ask them if they would be willing to set aside an hour or so a week to perform these mock interviews with you. If they currently work in a similar role that you are interviewing for, even better!

A few other options are Pramp and CodeInterview. These sites allow you to schedule an interview, and pick a primary focus (topic), language, and area of expertise (frontend, backend, and so on).

These platforms also give you more flexibility so you do not have to worry about scheduling time with someone you personally know.

Interviews are nerve-racking, but I am confident as you complete more of them your confidence and comfort level will increase.

Should I cram the day before?

As the days go by, you are feeling more confident. You are tired from preparation, but excited to show this company what you are made of. It's finally the day before the interview – what is the best use of your time?

It might be tempting for candidates to cram as many Leetcode problems or whiteboard questions as possible the day before. But I believe the best thing you can do for your mind is to rest.

Celebrate your achievement, getting interviews is not an easy task. Be nice to yourself. Relax and spend the day doing any activity that brings you joy and (ideally) relaxes you.

This might sound counterintuitive, but I think it is the best thing for you to do. You will need your brain to work well at your interview. Therefore, giving it rest the day before is exactly what it needs.

In Summary

If you are reading this because you are going to start to prepare for an interview, congrats! I hope my insights can help in your preparation and your headspace as you approach your big day.

Ultimately, remember to take a deep breath, relax, and be confident in yourself. Whoever you interview with sees promise in your skills. You got this!