Coder Legion - Recent posts tagged dsa

When DSA Solved Our AWS Scaling Problem

Fri, 30 Oct 2026 08:39:12 +0000

When DSA Solved Our AWS Scaling Problem

In the age of AI, it feels like DSA is slowly disappearing from day-to-day development.

You can ask an AI to generate a queue, configure an AWS service, or write a retry mechanism in seconds.

But there is one thing AI cannot remove from engineering:

Constraints.

And when constraints appear, DSA suddenly becomes relevant again.

At our startup, we often solve problems in a scalable way. But scalability doesn't always mean adding another AWS service. Sometimes, the solution is simply using the existing components differently.

You usually don't recognize a DSA concept in a real-world system until someone asks:

"Why are we doing it this way?"

That question led us to a surprisingly simple solution to an AWS scheduling problem.

The Problem: We Were Running Out of Schedules

Imagine we have a large number of jobs.

Each job can fail and needs to be retried on subsequent days:

Parent Job
   │
   ├── Retry 1 → +1 day
   ├── Retry 2 → +2 days
   └── Retry 3 → +3 days

Initially, this seems straightforward.

We can simply create an EventBridge schedule for every retry.

But then scale enters the picture.

We encountered a situation where, for every 6,000 jobs, we needed to create 3 separate EventBridge schedules.

That means:

6,000 jobs
   ×
3 retry schedules
   =
18,000 schedules

Now imagine increasing the workload.

What happens if we have 10,000 jobs?

10,000 jobs
    ×
3 retries
    =
30,000 schedules

And what if this keeps growing?

We eventually run into EventBridge scheduling limits.

The obvious solution might be:

"Let's add another AWS component."

But our senior asked a different question:

"Can we solve this using a sliding window?"

That was the interesting part.

First, What Is a Sliding Window?

A sliding window is a technique where we don't process the entire dataset at once.

Instead, we maintain a smaller active window and continuously move it forward.

For example, imagine these jobs:

Day 1   Day 2   Day 3   Day 4   Day 5   Day 6   Day 7
 ├───────┼───────┼───────┼───────┼───────┼───────┼───────┤
         [──────────── Window ────────────]

As time moves forward:

Before:

Day 1   Day 2   Day 3   Day 4   Day 5   Day 6   Day 7
         [──────── Window ────────]


After:

Day 1   Day 2   Day 3   Day 4   Day 5   Day 6   Day 7
                 [──────── Window ────────]

The important idea is:

We don't need to keep scheduling everything forever.

We only care about jobs relevant to the current time window.

That observation changes how we think about the EventBridge problem.

What If We Don't Schedule Every Retry?

This was the key idea.

Instead of asking:

"When should this retry happen?"

and creating an EventBridge schedule for that future date...

we ask:

"Which retries are supposed to happen today?"

That small change removes the need to schedule every future retry individually.

The Original Approach

Let's say today is August 18.

A parent job runs today.

Its retries are:

August 18
   │
   ├── Retry 1 → August 19
   ├── Retry 2 → August 20
   └── Retry 3 → August 21

The traditional approach is:

              EventBridge
                  │
       ┌──────────┼──────────┐
       ▼          ▼          ▼
    Aug 19     Aug 20     Aug 21
    Retry 1    Retry 2    Retry 3

For every parent job, we create future schedules.

This is where the number of schedules grows rapidly.

The Sliding Window Approach

Now let's change the perspective.

Instead of scheduling:

Retry 1 → tomorrow
Retry 2 → day after tomorrow
Retry 3 → three days later

we maintain a daily execution window.

Every day, we ask:

"Which existing parent jobs have a retry due today?"

Then we execute those retries.

                    TODAY
                      │
                      ▼
             ┌─────────────────┐
             │   Sliding       │
             │    Window       │
             └────────┬────────┘
                      │
        ┌─────────────┼─────────────┐
        ▼             ▼             ▼
     Retry 1       Retry 2       Retry 3
      due today     due today     due today

EventBridge no longer needs to know about every individual retry.

It only needs to trigger the parent job.

But What About Jobs From Previous Days?

This is where the idea becomes interesting.

Suppose a parent job ran 3 days ago.

Let's say:

Parent Job
August 15
   │
   ├── Retry 1 → August 16
   ├── Retry 2 → August 17
   └── Retry 3 → August 18

Today is August 18.

The third retry is due today.

Under the traditional approach, we would have created a schedule on August 15 for the retry that should execute on August 18.

But we don't need to do that anymore.

Instead, today's sliding window discovers it.

August 15        August 16        August 17        August 18
Parent Job       Retry 1          Retry 2          Retry 3
    │                │                │                │
    └────────────────┴────────────────┴────────────────┘
                                                     ▲
                                                     │
                                                   TODAY

The system simply asks:

"What retries are due on August 18?"

And finds:

Parent Job: August 15
Retry:      3
Due:        August 18

Then it executes it.

The Trick

This is the entire trick:

Don't schedule the future retries.

Instead Conceptually:

                 ┌─────────────────────┐
                 │   Daily Trigger     │
                 └──────────┬──────────┘
                            │
                            ▼
                 ┌─────────────────────┐
                 │  Current Time      │
                 │     Window         │
                 └──────────┬──────────┘
                            │
                            ▼
              ┌──────────────────────────┐
              │ Find retries due today   │
              └────────────┬─────────────┘
                           │
                 ┌─────────┴─────────┐
                 ▼                   ▼
            Retry due             Not due
                 │                   │
                 ▼                   ▼
              Execute              Ignore

Why This Scales Better

The important difference is what we are scheduling.

Number of schedules grows
with the number of jobs

Now the number of EventBridge schedules is no longer directly proportional to:

Number of Jobs × Number of Retries

Instead, EventBridge becomes the mechanism that wakes up the scheduler/processor, while the application determines which work actually needs to happen.

The Bigger Lesson

The interesting part of this problem wasn't really EventBridge.

It was recognizing that we were using EventBridge to solve a problem that didn't necessarily belong there.

We initially thought:

"We need to schedule millions of future events."

The better question was:

"Do we actually need to schedule millions of future events?"

And the answer was no.

We only needed to know:

"What needs to happen today?"

That is where a simple DSA concept like sliding window becomes a practical system-design technique.

DSA Is Not Dead

This is why I don't think DSA is disappearing from software engineering.
Sometimes the answer is a sophisticated distributed system.

And sometimes...

it's a sliding window.

The important skill isn't memorizing DSA patterns.

What if your wardrobe could teach you Sorting Algorithms?👗

Wed, 23 Sep 2026 05:05:37 +0000

You open your wardrobe.

T-shirts mixed with jeans.
Dresses hiding behind hoodies.
Everything is everywhere. 😭

You need to sort it.

But here's the catch...

There isn't just one way to organize a messy wardrobe.

And that's exactly what happens in DSA.

An unsorted array is basically a messy wardrobe.
The goal is the same: put everything in order.

But every sorting algorithm has its own strategy.

Let's meet them. 👀

1. Bubble Sort — Compare the neighbors

Imagine checking your clothes two at a time.

If the two neighboring clothes are in the wrong order:

🔄 Swap them.

Then move to the next pair.

Keep doing this until the largest item gradually reaches the end.

That's why it's called Bubble Sort—elements "bubble" toward their correct positions.

💻 Java

public class BubbleSort {

    public static void main(String[] args) {

        int[] arr = {5, 3, 8, 4, 2};

        for (int i = 0; i < arr.length - 1; i++) {

            for (int j = 0; j < arr.length - i - 1; j++) {

                if (arr[j] > arr[j + 1]) {

                    int temp = arr[j];
                    arr[j] = arr[j + 1];
                    arr[j + 1] = temp;
                }
            }
        }

        for (int num : arr) {
            System.out.print(num + " ");
        }
    }
}

Time: O(n²)
Space: O(1)

🧠 Remember:
Bubble = Compare neighbors + Swap

🎯 2. Selection Sort — Find the right one

Now you change your strategy.

Instead of repeatedly comparing neighbors, you look through the entire unsorted section.

You find the smallest item.

Then...

📍 Put it in its correct position.

Repeat.

It's like saying:

"First, I'll find the smallest shirt. Then the next smallest. Then the next..."

That's Selection Sort.

💻 Java

public class SelectionSort {

    public static void main(String[] args) {

        int[] arr = {64, 25, 12, 22, 11};

        for (int i = 0; i < arr.length - 1; i++) {

            int minIndex = i;

            for (int j = i + 1; j < arr.length; j++) {

                if (arr[j] < arr[minIndex]) {
                    minIndex = j;
                }
            }

            int temp = arr[i];
            arr[i] = arr[minIndex];
            arr[minIndex] = temp;
        }

        for (int num : arr) {
            System.out.print(num + " ");
        }
    }
}

Time: O(n²)
Space: O(1)

🧠 Remember:
Selection = Find minimum + Place it

🃏 3. Insertion Sort — Insert it where it belongs

Now imagine arranging clothes one by one.

You already have a few clothes arranged.

You pick the next one.

Look at the sorted section.

"Where does this belong?"

You make space and insert it there.

Just like arranging playing cards in your hand. 🃏

That's Insertion Sort.

💻 Java

public class InsertionSort {

    public static void main(String[] args) {

        int[] arr = {5, 3, 4, 1, 2};

        for (int i = 1; i < arr.length; i++) {

            int key = arr[i];
            int j = i - 1;

            while (j >= 0 && arr[j] > key) {

                arr[j + 1] = arr[j];
                j--;
            }

            arr[j + 1] = key;
        }

        for (int num : arr) {
            System.out.print(num + " ");
        }
    }
}

Best: O(n)
Worst: O(n²)
Space: O(1)

🧠 Remember:
Insertion = Take + Shift + Insert

✂️ 4. Merge Sort — Don't organize everything at once

You look at the wardrobe.

"There are WAY too many clothes. I'm splitting this." 😭

Divide the clothes into two sections.

Then divide those sections again.

Keep dividing until each section is tiny.

Now sort them.

Then merge the sorted sections back together.

Divide → Sort → Merge

That's Merge Sort.

💻 Java

public class MergeSort {

    static void mergeSort(int[] arr, int left, int right) {

        if (left < right) {

            int mid = left + (right - left) / 2;

            mergeSort(arr, left, mid);
            mergeSort(arr, mid + 1, right);

            merge(arr, left, mid, right);
        }
    }

    static void merge(int[] arr, int left, int mid, int right) {

        int[] temp = new int[right - left + 1];

        int i = left;
        int j = mid + 1;
        int k = 0;

        while (i <= mid && j <= right) {

            if (arr[i] <= arr[j]) {
                temp[k++] = arr[i++];
            } else {
                temp[k++] = arr[j++];
            }
        }

        while (i <= mid) {
            temp[k++] = arr[i++];
        }

        while (j <= right) {
            temp[k++] = arr[j++];
        }

        for (int x = 0; x < temp.length; x++) {
            arr[left + x] = temp[x];
        }
    }

    public static void main(String[] args) {

        int[] arr = {8, 3, 5, 4, 7, 6, 1, 2};

        mergeSort(arr, 0, arr.length - 1);

        for (int num : arr) {
            System.out.print(num + " ");
        }
    }
}

Time: O(n log n)
Space: O(n)

🧠 Remember:
Merge = Divide + Sort + Merge

⚡ 5. Quick Sort — Choose a pivot

Now you want a faster strategy.

You pick one item as your pivot.

Everything smaller goes to one side.

Everything larger goes to the other.

Now you've created smaller problems.

Repeat the same process.

That's Quick Sort.

💻 Java

public class QuickSort {

    static void quickSort(int[] arr, int low, int high) {

        if (low < high) {

            int pivotIndex = partition(arr, low, high);

            quickSort(arr, low, pivotIndex - 1);
            quickSort(arr, pivotIndex + 1, high);
        }
    }

    static int partition(int[] arr, int low, int high) {

        int pivot = arr[high];

        int i = low - 1;

        for (int j = low; j < high; j++) {

            if (arr[j] < pivot) {

                i++;

                int temp = arr[i];
                arr[i] = arr[j];
                arr[j] = temp;
            }
        }

        int temp = arr[i + 1];
        arr[i + 1] = arr[high];
        arr[high] = temp;

        return i + 1;
    }

    public static void main(String[] args) {

        int[] arr = {10, 7, 8, 9, 1, 5};

        quickSort(arr, 0, arr.length - 1);

        for (int num : arr) {
            System.out.print(num + " ");
        }
    }
}

Average: O(n log n)
Worst: O(n²)
Space: O(log n) average recursion stack

🧠 Remember:
Quick = Pivot + Partition

🌳 6. Heap Sort — Priority comes first

Now imagine you want the highest-priority clothing item to always be easy to find.

You organize the items using a special structure:

🌳 Heap

The largest element can stay at the top of a Max Heap.

Take it.

Put it in its final position.

Restore the heap.

Repeat.

That's Heap Sort.

💻 Java

public class HeapSort {

    static void heapSort(int[] arr) {

        int n = arr.length;

        // Build Max Heap
        for (int i = n / 2 - 1; i >= 0; i--) {
            heapify(arr, n, i);
        }

        // Move maximum to the end
        for (int i = n - 1; i > 0; i--) {

            int temp = arr[0];
            arr[0] = arr[i];
            arr[i] = temp;

            heapify(arr, i, 0);
        }
    }

    static void heapify(int[] arr, int n, int i) {

        int largest = i;

        int left = 2 * i + 1;
        int right = 2 * i + 2;

        if (left < n && arr[left] > arr[largest]) {
            largest = left;
        }

        if (right < n && arr[right] > arr[largest]) {
            largest = right;
        }

        if (largest != i) {

            int temp = arr[i];
            arr[i] = arr[largest];
            arr[largest] = temp;

            heapify(arr, n, largest);
        }
    }

    public static void main(String[] args) {

        int[] arr = {12, 11, 13, 5, 6, 7};

        heapSort(arr);

        for (int num : arr) {
            System.out.print(num + " ");
        }
    }
}

Time: O(n log n)
Space: O(1)

🧠 Remember:
Heap = Build heap + Extract repeatedly

🔢 7. Counting Sort — Stop comparing. Start counting.

Here's where things get interesting.

Imagine your clothes can only have sizes:

1, 2, 3, 4, 5

Instead of comparing every item...

You simply count how many times each size appears.

That's the idea behind Counting Sort.

💻 Java

public class CountingSort {

    static void countingSort(int[] arr) {

        int max = arr[0];

        for (int num : arr) {
            if (num > max) {
                max = num;
            }
        }

        int[] count = new int[max + 1];

        for (int num : arr) {
            count[num]++;
        }

        int index = 0;

        for (int i = 0; i < count.length; i++) {

            while (count[i] > 0) {

                arr[index] = i;
                index++;

                count[i]--;
            }
        }
    }

    public static void main(String[] args) {

        int[] arr = {4, 2, 2, 8, 3, 3, 1};

        countingSort(arr);

        for (int num : arr) {
            System.out.print(num + " ");
        }
    }
}

Time: O(n + k)
Space: O(k)

🧠 Remember:
Counting = Count frequencies

⚠️ Works well when the range of values is reasonably small.

📚 8. Radix Sort — One digit at a time

Now imagine numbers are your clothes.

Instead of comparing the whole number...

You organize them digit by digit.

First:

➡️ Ones digit

Then:

➡️ Tens digit

Then:

➡️ Hundreds digit

For example:

170, 45, 75, 90, 802, 24, 2, 66

The algorithm gradually builds the final ordering.

That's Radix Sort.

💻 Java

public class RadixSort {

    static void radixSort(int[] arr) {

        int max = arr[0];

        for (int num : arr) {
            if (num > max) {
                max = num;
            }
        }

        for (int exp = 1; max / exp > 0; exp *= 10) {

            countingSort(arr, exp);
        }
    }

    static void countingSort(int[] arr, int exp) {

        int n = arr.length;

        int[] output = new int[n];
        int[] count = new int[10];

        for (int num : arr) {

            int digit = (num / exp) % 10;

            count[digit]++;
        }

        for (int i = 1; i < 10; i++) {

            count[i] += count[i - 1];
        }

        for (int i = n - 1; i >= 0; i--) {

            int digit = (arr[i] / exp) % 10;

            output[count[digit] - 1] = arr[i];

            count[digit]--;
        }

        for (int i = 0; i < n; i++) {

            arr[i] = output[i];
        }
    }

    public static void main(String[] args) {

        int[] arr = {170, 45, 75, 90, 802, 24, 2, 66};

        radixSort(arr);

        for (int num : arr) {
            System.out.print(num + " ");
        }
    }
}

Time: O(d × (n + k))
Space: O(n + k)

🧠 Remember:
Radix = Digit by digit

🪣 9. Bucket Sort — Group first, sort later

One last strategy.

Instead of throwing every piece of clothing into one giant pile...

You create buckets.

🪣 Bucket 1 → small values
🪣 Bucket 2 → medium values
🪣 Bucket 3 → large values

Then sort each bucket individually.

Finally...

Combine them.

That's Bucket Sort.

💻 Java

import java.util.*;

public class BucketSort {

    static void bucketSort(float[] arr) {

        int n = arr.length;

        List<Float>[] buckets = new ArrayList[n];

        for (int i = 0; i < n; i++) {
            buckets[i] = new ArrayList<>();
        }

        for (float num : arr) {

            int index = (int) (num * n);

            buckets[index].add(num);
        }

        for (List<Float> bucket : buckets) {
            Collections.sort(bucket);
        }

        int index = 0;

        for (List<Float> bucket : buckets) {

            for (float num : bucket) {

                arr[index++] = num;
            }
        }
    }

    public static void main(String[] args) {

        float[] arr = {
            0.42f, 0.32f, 0.23f,
            0.52f, 0.25f, 0.47f, 0.51f
        };

        bucketSort(arr);

        for (float num : arr) {
            System.out.print(num + " ");
        }
    }
}

Average:O(n + k)
Worst: O(n²)

🧠 Remember:
Bucket = Distribute → Sort → Combine

🧠 So... which algorithm would YOU use?

Now look back at your messy wardrobe.

Same problem.

Different strategies.

Algorithm	Wardrobe Strategy	Main Idea
Bubble	Compare neighbors	Swap
🎯 Selection	Find the right item	Select
🃏 Insertion	Place one item at a time	Insert
✂️ Merge	Split the wardrobe	Divide & Merge
⚡ Quick	Pick a reference item	Pivot
🌳 Heap	Prioritize items	Heap
🔢 Counting	Count categories	Frequency
📚 Radix	Sort digit by digit	Digits
🪣 Bucket	Make groups first	Distribution

And here's the part I want you to remember:

Sorting isn't just about arranging numbers.

It's about learning that the same problem can have completely different solutions.

And in DSA, the real question isn't:

"Can I sort this?"

It's:

"How efficiently can I sort this?" 👀

That's where Time Complexity enters the story.

Because if your wardrobe has 10 clothes, almost anything works.

But what if it has 10 lakh clothes? 😭

Suddenly, your choice of algorithm matters.

LeetCode #198. House Robber

Wed, 16 Sep 2026 20:24:40 +0000

Problem

You are a professional robber planning to rob houses along a street. Each house has a certain amount of money stashed, the only constraint stopping you from robbing each of them is that adjacent houses have security systems connected and it will automatically contact the police if two adjacent houses were broken into on the same night.

Given an integer array nums representing the amount of money of each house, return the maximum amount of money you can rob tonight without alerting the police.

Example 1:

Input: nums = [1,2,3,1]
Output: 4
Explanation: Rob house 1 (money = 1) and then rob house 3 (money = 3).
Total amount you can rob = 1 + 3 = 4.
Example 2:

Input: nums = [2,7,9,3,1]
Output: 12
Explanation: Rob house 1 (money = 2), rob house 3 (money = 9) and rob house 5 (money = 1).
Total amount you can rob = 2 + 9 + 1 = 12.

Constraints:

1 <= nums.length <= 100
0 <= nums[i] <= 400

Discussion

The problem can be solved using dynamic programming.We create a new array dp and use it to store the maximum up to a certain index. The first index has the value stored at the first index in nums.The second one takes the maximum of the first 2 values in nums.
We then iterate through the rest of the array and store in dp,the maximum of the previous value in dp and the sum of the current value in nums and the value before the previous value in dp. We return the last value in dp once we are done traversing.

Java

class Solution {
    public int rob(int[] nums) {
         if(nums.length==0) return 0;
         if(nums.length==1)return nums[0];
         if(nums.length==2)return Math.max(nums[0],nums[1]);
         int [] loot = new int[nums.length];
          loot[0]= nums[0];
          loot[1]= Math.max(nums[1],nums[0]);
          for(int i=2;i<loot.length;i++){
            loot[i]= Math.max(nums[i]+loot[i-2],loot[i-1]);
          }
          return loot[loot.length-1];
    }
}

JavaScript

var rob = function(nums) {
  if(nums.length==0) return 0;
  if(nums.length==1)return nums[0];
  if(nums.length==2)return Math.max(nums[0],nums[1]);
  const loot = new Array(nums.length);
  loot[0]= nums[0];
  loot[1]= Math.max(nums[1],nums[0]);
  for(let i=2;i<loot.length;i++){
   let previousloot= loot[i-1];
   let currentloot= nums[i]+loot[i-2];
   loot[i]= Math.max(currentloot,previousloot);
  }
  return loot[loot.length-1];
};

public class Solution {
    public int Rob(int[] nums) {
     if(nums.Length==0) return 0;
     if(nums.Length==1)return nums[0];
     if(nums.Length==2)return Math.Max(nums[0],nums[1]);
     int [] loot = new int[nums.Length];
     loot[0]= nums[0];
     loot[1]= Math.Max(nums[1],nums[0]);
     for(int i=2;i<loot.Length;i++)loot[i]= Math.Max(nums[i]+loot[i-2],loot[i-1]);
     return loot[loot.Length-1];   
    }
}

C++

class Solution {
public:
    int rob(vector<int>& nums) {
     if(nums.size()==0) return 0;
     if(nums.size()==1)return nums.at(0);
     if(nums.size()==2)return std::max(nums.at(0),nums.at(1));
     vector<int> loot;
     loot.push_back(nums.at(0));
     loot.push_back(std::max(nums.at(1),nums.at(0)));
     for(int i=2;i<nums.size();i++){
      loot.push_back(std::max(nums.at(i)+loot.at(i-2),loot.at(i-1)));
     }
     return loot.at(loot.size()-1);  
    }
};

Sliding Window Pattern in DSA: A Beginner-Friendly Guide

Sun, 13 Sep 2026 17:09:56 +0000

When I first started solving array and string problems, Sliding Window was one of the patterns that felt confusing.

The code itself is usually short, but understanding when to move the window, what to remove, and what to add can be difficult at first.

This blog explains the Sliding Window technique from the basics with a simple example.

What is Sliding Window?

Sliding Window is a technique used to solve problems involving contiguous portions of an array or string.

Instead of repeatedly calculating the same elements, we maintain a window and move it through the input.

For example, consider:

nums = [1, 12, -5, -6, 50, 3]

If the window size is 4, our windows are:

[1, 12, -5, -6]
[12, -5, -6, 50]
[-5, -6, 50, 3]

The window moves one position at a time.

That is why it is called Sliding Window.

Why Do We Need Sliding Window?

Let's say we want to find the maximum sum of any k consecutive elements.

For:

nums = [1, 12, -5, -6, 50, 3]
k = 4

We could calculate every window from scratch:

1 + 12 + (-5) + (-6) = 2

12 + (-5) + (-6) + 50 = 51

(-5) + (-6) + 50 + 3 = 42

This works, but we are repeatedly calculating elements that were already included in the previous window.

Sliding Window avoids this unnecessary work.

The Main Idea

Look at the first window:

[1, 12, -5, -6]  50  3

Its sum is:

Now we slide the window one position to the right:

1  [12, -5, -6, 50]  3

What changed?

1 left the window.
50 entered the window.

So instead of calculating the entire sum again:

new sum = old sum - element leaving + element entering

Therefore:

new sum = 2 - 1 + 50
        = 51

This simple idea is the heart of the fixed-size Sliding Window technique.

Fixed-Size Sliding Window

The general pattern looks like this:

window = sum(nums[:k])

for i in range(k, len(nums)):
    window = window - nums[i-k] + nums[i]

The important line is:

window = window - nums[i-k] + nums[i]

It means:

Remove the element that is leaving
+
Add the element that is entering

Example: LeetCode 643

One beginner-friendly problem for learning Sliding Window is:

Maximum Average Subarray I

Given an integer array nums and an integer k, find the contiguous subarray of length k that has the maximum average.

For example:

nums = [1, 12, -5, -6, 50, 3]
k = 4

The possible windows are:

[1, 12, -5, -6]       → sum = 2
[12, -5, -6, 50]      → sum = 51
[-5, -6, 50, 3]       → sum = 42

The maximum sum is:

Therefore, the maximum average is:

51 / 4 = 12.75

Python Solution

class Solution:
    def findMaxAverage(self, nums: List[int], k: int) -> float:
        tot = sum(nums[:k])

        avg = tot / k
        maximum = avg

        for i in range(k, len(nums)):
            tot = tot - nums[i-k] + nums[i]

            avg = tot / k
            maximum = max(maximum, avg)

        return maximum

Let's understand it step by step.

Step 1: Calculate the First Window

tot = sum(nums[:k])

If:

nums = [1, 12, -5, -6, 50, 3]
k = 4

then:

nums[:k]

gives:

[1, 12, -5, -6]

So:

tot = 2

Step 2: Calculate the First Average

avg = tot / k

Therefore:

avg = 2 / 4
    = 0.5

We store this as our current maximum:

maximum = avg

Step 3: Slide the Window

Now we start from index k:

for i in range(k, len(nums)):

Since k = 4, the first value of i is 4.

The new element is:

nums[i]

which is:

nums[4] = 50

The element leaving the window is:

nums[i-k]

Since:

i = 4
k = 4

we get:

i - k = 0

Therefore:

nums[i-k] = nums[0] = 1

So:

tot = tot - nums[i-k] + nums[i]

becomes:

tot = 2 - 1 + 50
    = 51

Our window has now moved from:

[1, 12, -5, -6]

to:

[12, -5, -6, 50]

Step 4: Update the Maximum

We calculate:

avg = tot / k

Therefore:

avg = 51 / 4
    = 12.75

Then:

maximum = max(maximum, avg)

The maximum becomes:

12.75

The same process continues until we reach the end of the array.

The Pattern to Remember

For a fixed-size Sliding Window, remember these three steps:

1. Calculate the first window

window = sum(nums[:k])

2. Slide the window

window = window - nums[i-k] + nums[i]

3. Update the answer

answer = max(answer, window)

That's the basic pattern.

Time Complexity

A brute-force approach may repeatedly calculate the sum of every window.

Sliding Window allows us to update the sum in constant time for each movement.

Therefore:

Time Complexity: O(n)
Space Complexity: O(1)

where n is the number of elements in the array.

How to Recognize a Sliding Window Problem

When reading a LeetCode problem, look for words such as:

contiguous
consecutive
substring
subarray
window
exactly k elements
at most k elements
longest/shortest substring
maximum/minimum sum of consecutive elements

For example:

Find the maximum sum of k consecutive elements.

This should immediately make you think:

Fixed-size Sliding Window.

Common Mistake

One common mistake is recalculating the entire window every time.

For example:

for i in range(n-k+1):
    total = sum(nums[i:i+k])

This repeatedly calculates values that were already calculated.

Instead, calculate the first window once and then update it:

window = window - element_leaving + element_entering

Fixed vs Variable Sliding Window

There are two major types of Sliding Window.

Fixed-size window

The window size stays the same.

Example:

k = 4

[1, 2, 3, 4]
   ↓
[2, 3, 4, 5]
   ↓
[3, 4, 5, 6]

Problems such as Maximum Average Subarray I use this pattern.

Variable-size window

The window size can grow and shrink depending on a condition.

For example:

[ a b c d e ]
  ←──────→

The window may expand when the condition is valid and shrink when the condition is violated.

Variable-size Sliding Window is slightly more difficult, so it is better to learn fixed-size windows first.

Practice Roadmap

If you're new to Sliding Window, don't immediately jump into difficult problems.

A good progression is:

LeetCode 643 — Maximum Average Subarray I
LeetCode 1456 — Maximum Number of Vowels in a Substring of Given Length
LeetCode 1343 — Number of Sub-arrays of Size K and Average Greater than or Equal to Threshold
LeetCode 1876 — Substrings of Size Three with Distinct Characters
LeetCode 209 — Minimum Size Subarray Sum
LeetCode 3 — Longest Substring Without Repeating Characters
LeetCode 1004 — Max Consecutive Ones III
LeetCode 424 — Longest Repeating Character Replacement

The first four help build the fixed-size pattern.

The later problems introduce variable-size windows, which require a deeper understanding of when to expand and shrink the window.

Final Takeaway

Sliding Window is not a completely different way of thinking about arrays.

It is mainly about reusing information from the previous window instead of calculating everything again.

The most important idea is:

Remove what leaves.
Add what enters.
Move the window.
Update the answer.

Once this becomes familiar, many array and string problems that initially look complicated become much easier to recognize.

Start small, understand the pattern, and then increase the difficulty.

Learn Trapping Rain Water, Top K Frequent and Selection Sort with Step-by-Step Visualization 👀👀

Fri, 11 Sep 2026 17:01:15 +0000

Hoi hoi!

I’m @nyaomaru, a frontend engineer who has been obsessed with ramen lately. 😸🍜

Have you used DSA View View already? 👀👀

https://dev.to/nyaomaru/i-built-a-tool-to-visualize-dsa-letearn-together-dsa-view-view--djo

DSA View View allows you to understand DSA by visualizing how your implementation actually runs.

In the previous articles, we looked at problems like:

Two Sum
Binary Search
Bubble Sort
Valid Parentheses
Reverse Linked List
Maximum Depth of Binary Tree
Number of Islands
Invert Binary Tree
Course Schedule

https://dev.to/nyaomaru/is-learning-dsa-boring-lets-use-dsaew-view-two-sum-binary-search-and-bubble-sort-374o

https://dev.to/nyaomaru/learn-valid-parentheses-reverse-lin-list-and-tree-max-depth-with-step-by-step-visualization-in-3o09

https://dev.to/nyaomaru/learn-number-of-islands-invert-binatree-and-course-schedule-with-step-by-step-visualization-in-5947

This time, let's try three more problems:

Trapping Rain Water
Top K Frequent Elements
Selection Sort

These three problems introduce some very useful ways of thinking

Shrink a problem from both sides
Count first, then organize by frequency
Repeatedly select the next value

Once again, the implementations are not necessarily huge.

But there are several changing values that we need to keep in our heads.

So instead of only reading the final code,

Let's view what actually happens. 👀👀

🌧️ Trapping Rain Water

Let's start with Trapping Rain Water.

Suppose we have these heights

[0, 1, 0, 2, 1, 0, 1, 3]

If we draw them as walls, it looks roughly like this.

              █
      █       █
  █   █ █   █ █
-----------------
0 1 0 2 1 0 1 3

Rain falls from above.

Some water escapes.

But some water becomes trapped between taller walls.

For example

      █~~~~~~~█
  █~~~█~~~~~~~█
-----------------

So the question is

How much water can be trapped?

At first, I found this problem quite confusing. 😿

Because the amount of water above one position depends on walls somewhere else.

So what information do we actually need?

How Much Water Fits Above One Position?

Imagine this position

left wall     right wall
    █             █
    █      x      █
    █      █      █

The water level cannot be higher than the shorter side.

So the maximum possible water level is

Math.min(leftMax, rightMax);

Then we subtract the current height.

Conceptually:

water = min(leftMax, rightMax) - currentHeight

That's the basic idea.

But do we really need to calculate both sides again for every position?

No.

We can use two pointers.

Two Pointers

Here is the implementation.

function trap(height: number[]): number {
  let left = 0;
  let right = height.length - 1;

  let leftMax = 0;
  let rightMax = 0;

  let water = 0;

  while (left <= right) {
    if (height[left] <= height[right]) {
      if (height[left] >= leftMax) {
        leftMax = height[left];
      } else {
        water += leftMax - height[left];
      }

      left++;
    } else {
      if (height[right] >= rightMax) {
        rightMax = height[right];
      } else {
        water += rightMax - height[right];
      }

      right--;
    }
  }

  return water;
}

There are several important values.

left
right
leftMax
rightMax
water

This is exactly the kind of code where I understand every variable individually,

but then lose track of all of them together. 😹

Let's follow a smaller example.

[2, 0, 1, 3]

Start From Both Ends

At first

left = 0
right = 3

[2, 0, 1, 3]
 ↑        ↑
left    right

The heights are:

height[left]  = 2
height[right] = 3

Since

2 <= 3

we process the left side.

There is a wall with height 2.

leftMax = 2

Then move left.

[2, 0, 1, 3]
    ↑     ↑
   left right

Now We Can Trap Water

The current height is

But we already know there is a wall of height 2 on the left.

And the right side is currently at least as high as that.

So this position can hold

leftMax - height[left]
= 2

Therefore

water = 2

Move again.

[2, 0, 1, 3]
       ↑  ↑
      left right

Now

height[left] = 1
leftMax = 2

2 - 1 = 1

One more unit of water.

water = 3

Eventually we reach the final wall.

Done! 🎉

Why Can We Process the Shorter Side?

This part is the important idea.

Suppose

height[left] <= height[right]

Then we already know there is a wall on the right that is at least as tall as the current left wall.

So for the current left position, the limiting factor is the best wall we have seen from the left.

That's why we can safely calculate

leftMax - height[left];

without knowing every future wall.

The same logic works from the other side.

height[right] < height[left]

we process the right side using rightMax.

So the algorithm keeps shrinking the unknown area

L → → →     ← ← ← R

until everything has been processed.

Complexity

Each pointer only moves across the array once.

Time:  O(n)
Space: O(1)

👀 Let's View View It

This problem is a perfect example of why I like visualization.

The code contains

left
right
leftMax
rightMax
water

And they all change at different times.

When I only read

water += leftMax - height[left];

I might ask:

Why are we using leftMax here?
What is rightMax right now?
Why did we move left instead of right?
How much water have we already counted?
Which part of the array is still unprocessed?

😿

https://dsa-view-view.vercel.app/#s=j.eyJlIjoidHJhcHBpbmctcbi13YXRlciIsImwiOiJ0eXBlc2NyaXB0IiwibSI6InZlcmlmaWNhdGlvbiIsInYiOjF9

Step by step, we can actually watch the search area shrink.

L         R
↓         ↓
[2, 0, 1, 3]

    L     R
    ↓     ↓
[2, 0, 1, 3]

       L  R
       ↓  ↓
[2, 0, 1, 3]

And at the same time

leftMax
rightMax
water

keep changing.

The algorithm is really asking

Which side can I safely solve right now?

Then it solves that side and moves inward. 🌧️😸

🔢 Top K Frequent Elements

Next, let's find the Top K Frequent Elements.

Suppose we have

[1, 1, 1, 2, 2, 3]

and

k = 2

How often does each number appear?

1 → 3 times
2 → 2 times
3 → 1 time

So the two most frequent values are

[1, 2]

Simple enough.

But how should we implement it?

First, Count Everything

The first thing we need is frequency.

We can use a Map.

const frequency = new Map<number, number>();

Then count each value.

for (const num of nums) {
  frequency.set(num, (frequency.get(num) ?? 0) + 1);
}

For

[1, 1, 1, 2, 2, 3]

we get

frequency = {
  1 → 3
  2 → 2
  3 → 1
}

Nice.

But we still need the top K.

Of course, we could sort everything by frequency.

But there is another interesting approach.

Use Frequency as an Index

The maximum possible frequency is

nums.length

So we can create buckets.

const buckets: number[][] = Array.from({ length: nums.length + 1 }, () => []);

The index represents frequency.

For example

bucket[1] = values appearing 1 time
bucket[2] = values appearing 2 times
bucket[3] = values appearing 3 times

For our example:

frequency = {
  1 → 3
  2 → 2
  3 → 1
}

the buckets become

index 0 → []
index 1 → [3]
index 2 → [2]
index 3 → [1]

That's pretty interesting. 👀👀

Instead of asking

What is the frequency of this number?

we reverse the relationship

Which numbers have this frequency?

Implementation

Here is the full implementation:

function topKFrequent(nums: number[], k: number): number[] {
  const frequency = new Map<number, number>();

  for (const num of nums) {
    frequency.set(num, (frequency.get(num) ?? 0) + 1);
  }

  const buckets: number[][] = Array.from({ length: nums.length + 1 }, () => []);

  for (const [num, count] of frequency) {
    buckets[count].push(num);
  }

  const result: number[] = [];

  for (let count = buckets.length - 1; count >= 0; count--) {
    for (const num of buckets[count]) {
      result.push(num);

      if (result.length === k) {
        return result;
      }
    }
  }

  return result;
}

Let's follow it.

Step 1: Build the Frequency Map

Start

frequency = {}

Read the first 1. And another one and another...

1 → 1
1 → 2
1 → 3

Then 2. And another one.

1 → 3
2 → 1
2 → 2

Finally 3.

1 → 3
2 → 2
3 → 1

Done.

Step 2: Put Values Into Buckets

Now

buckets[count].push(num);

For

1 → 3

we do

buckets[3].push(1)

For

2 → 2

we do

buckets[2].push(2)

And

3 → 1

becomes

buckets[1].push(3)

0: []
1: [3]
2: [2]
3: [1]

Step 3: Read From Highest Frequency

We want the most frequent values.

So don't start at 0. Start from the end.

3 → [1]
2 → [2]
1 → [3]

Take 1.

result = [1]

We still need one more. Move down.

Take 2.

result = [1, 2]

Now

result.length === k

So return.

Done! 🎉

Why Is This Interesting?

I like this solution because the second structure changes our perspective.

The Map says

value → frequency

The buckets say

frequency → values

Same information. But different direction.

And suddenly finding the most frequent values becomes easy.

We just walk backward through the buckets.

Complexity

We count every number once.

We distribute every unique number into a bucket.

Then we walk through the buckets.

Time:  O(n)
Space: O(n)

👀 Let's View View It

There are two transformations happening here.

First

nums
 ↓
frequency Map

Then

frequency Map
 ↓
buckets

Then

buckets
 ↓
result

Reading the final implementation, it can be easy to miss why we're building two different data structures.

https://dsa-view-view.vercel.app/#s=j.eyJlIjoidG9wLWstZnJlcbnQiLCJsIjoidHlwZXNjcmlwdCIsIm0iOiJ2ZXJpZmljYXRpb24iLCJ2IjoxfQ

With the runtime visible, we can follow the data changing shape.

[1, 1, 1, 2, 2, 3]
        ↓ count
1 → 3
2 → 2
3 → 1
        ↓ bucket
1: [3]
2: [2]
3: [1]
        ↓ highest first
[1, 2]

That's the part I like.

We don't magically find the top K.

We reorganize the information until the answer becomes easy to read. 🔢😸

👉 Selection Sort

Finally, let's sort something again!

We already looked at Bubble Sort in a previous article.

This time, let's try Selection Sort.

Suppose we have

[5, 3, 4, 1, 2]

We want

[1, 2, 3, 4, 5]

Selection Sort follows a very simple idea

Find the smallest remaining value and move it to the front.

Then repeat.

First Pass

Start

[5, 3, 4, 1, 2]
 ↑
 i

Assume the first value is currently the smallest.

minIndex = 0

Then scan everything to the right.

5 vs 3

3 is smaller.

So:

minIndex = 1

Then:

3 vs 4

No change.

Then

3 vs 1

1 is smaller.

minIndex = 3

Finally

1 vs 2

Still 1.

So the smallest value is at index 3.

Swap

[5, 3, 4, 1, 2]
 ↑        ↑
 i       min

↓

[1, 3, 4, 5, 2]

Now the first position is finished.

[1 | 3, 4, 5, 2]
 ↑
sorted

Repeat

Next, start from index 1.

[1 | 3, 4, 5, 2]
     ↑
     i

Find the smallest value in

[3, 4, 5, 2]

That's 2.

Swap.

[1, 2 | 4, 5, 3]

Again.

Find the smallest remaining value.

Eventually

[1, 2, 3, 4, 5]

Sorted! 🎉

Implementation

function selectionSort(nums: number[]): number[] {
  for (let i = 0; i < nums.length - 1; i++) {
    let minIndex = i;

    for (let j = i + 1; j < nums.length; j++) {
      if (nums[j] < nums[minIndex]) {
        minIndex = j;
      }
    }

    if (minIndex !== i) {
      [nums[i], nums[minIndex]] = [nums[minIndex], nums[i]];
    }
  }

  return nums;
}

There are two important indexes.

i
minIndex

And also

which searches through the unsorted area.

Why Is It Called Selection Sort?

Because each pass selects the smallest remaining value.

Find smallest
  ↓
Select it
  ↓
Move it to the front
  ↓
Repeat

That's basically the whole algorithm.

Complexity

For every position, we search through the remaining values.

Time: O(n²)

We sort the array in place.

Space: O(1)

Selection Sort is not something I would normally choose for sorting a huge production dataset. 😹

But as a learning algorithm, it is wonderfully visual.

👀 Let's View View It

The implementation contains nested loops.

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

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

Reading it, I might lose track of:

Which area is already sorted?
Where is i?
Where is j?
What does minIndex currently point to?
When exactly does the swap happen?

https://dsa-view-view.vercel.app/#s=j.eyJlIjoic2VsZWN0aW9uLcnQiLCJsIjoidHlwZXNjcmlwdCIsIm0iOiJ2ZXJpZmljYXRpb24iLCJ2IjoxfQ

When we visualize it, the basic pattern becomes obvious.

[5, 3, 4, 1, 2]
          ↑
       smallest

[1 | 3, 4, 5, 2]
              ↑
           smallest

[1, 2 | 4, 5, 3]

The algorithm is continuously growing a finished area from left to right.

That's Selection Sort.

Pick the smallest remaining value.

Put it next. And repeat. 🍥😸

🧠 What Did We Actually Learn?

Again, these three problems look completely different.

But each one introduces a useful way of thinking.

Trapping Rain Water

Use information from both sides to decide which part can already be solved safely.

Which side do I know enough about right now?

Top K Frequent Elements

Sometimes counting the data is only the first step.

Reorganize it into a structure where the answer becomes easy to retrieve.

Can I reorganize this information around what I actually need?

Selection Sort

Build the answer one permanent position at a time.

What value belongs in this position next?

So this time we saw

Two pointers
Frequency buckets
Selection

Three different mental models again.

And just like the previous problems, the difficult part is often not the syntax.

It's the changing state.

Which pointer moved?
What is the maximum now?
What is inside the Map?
Which bucket changed?
Where is minIndex?
Which part is already finished?

That's a lot to keep in our heads.

So instead, I want to view it. 👀👀

🎯 Conclusion

In this article, we looked at:

Trapping Rain Water with two pointers
Top K Frequent Elements with frequency buckets
Selection Sort

And more importantly, we followed how their state changes while they run.

For Trapping Rain Water, we watched two pointers move inward while leftMax, rightMax, and water changed.

left →       ← right

For Top K Frequent Elements, we watched the same data change representation.

array
  ↓
frequency Map
  ↓
buckets
  ↓
result

For Selection Sort, we watched the sorted area grow one position at a time.

This is exactly the kind of thing I built DSA View View for.

https://dsa-view-view.vercel.app

You can write or load a TypeScript implementation, run it with your own inputs, and move backward and forward through the runtime.

If you are learning DSA too, try viewing one of these problems step by step.

And if there is a DSA problem you want me to cover next, please let me know in the comments!

I still have many algorithms to learn myself. 😸

Let's train our DSA muscles together! 💪

If you like DSA View View, please give it a star ⭐

https://github.com/nyaomaru/dsa-view-view

See you in the next article!

LeetCode #273. Integer to English Words

Mon, 07 Sep 2026 21:23:52 +0000

Recursion is a concept taught at University level. It is a concept many don't understand but it appears in coding challenges .For this reason, I have decided to cover it.

Problem
Convert a non-negative integer num to its English words representation.

Example 1:

Input: num = 123
Output: "One Hundred Twenty Three"
Example 2:

Input: num = 12345
Output: "Twelve Thousand Three Hundred Forty Five"
Example 3:

Input: num = 1234567
Output: "One Million Two Hundred Thirty Four Thousand Five Hundred Sixty Seven"

Constraints:

0 <= num <= 231 - 1

Discussion
For this, we can use recursion. We take base cases for some numbers and return specific words. If the number is not any of these numbers, we call the function as much as possible.

Solutions
Java

class Solution {
    public String numberToWords(int num){
      if(num<10){
       if(num==0)return "Zero"; 
       else if(num==1)return "One";
       else if(num==2) return "Two";
       else if(num==3) return "Three";
       else if(num==4) return "Four";
       else if(num==5) return "Five";
       else if(num==6) return "Six";
       else if(num==7) return "Seven";
       else if(num==8) return "Eight";
       else return "Nine";
      }else if(num>=10 && num<100){
        if(num==10)return"Ten";
        else if(num==11)return "Eleven";
        else if(num==12) return "Twelve";
        else if(num==13) return "Thirteen";
        else if(num==14) return "Fourteen";
        else if(num==15) return "Fifteen";
        else if(num==16) return "Sixteen";
        else if(num==17) return "Seventeen";
        else if(num==18) return "Eighteen";
        else if(num==19) return "Nineteen";
        else if(num==20) return "Twenty";
        else if(num==30) return "Thirty";
        else if(num==40) return "Forty";
        else if(num==50) return "Fifty";
        else if(num==60) return "Sixty";
        else if(num==70) return "Seventy";
        else if(num==80) return "Eighty";
        else if(num==90) return "Ninety";
        else if(num>60 && num<70) return "Sixty "+numberToWords(num-60);
        else if(num>70 && num<80) return "Seventy " +numberToWords(num-70);
        else if(num>80 && num<90) return "Eighty " +numberToWords(num-80);
        else if(num>20 && num<30) return "Twenty "+numberToWords(num-20);
        else if(num>30 && num<40) return "Thirty " +numberToWords(num-30);
        else if(num>40 && num<50) return "Forty " +numberToWords(num-40);
        else if(num>50 && num<60) return "Fifty "+numberToWords(num-50);
        else if(num>60 && num<70) return "Sixty "+numberToWords(num-60);
        else if(num>70 && num<80) return "Seventy " +numberToWords(num-70);
        else if(num>80 && num<90) return "Eighty " +numberToWords(num-80);
        else  return "Ninety "+numberToWords(num-90);
      }else if(num>=100 && num<1000){
        int numHundred=num/100;
        int modHundred=num%100;
        if(modHundred==0) return numberToWords(numHundred)+" Hundred";
        else return numberToWords(numHundred)+" Hundred "+numberToWords(modHundred);
      }else if(num>=1000 && num<1000000){
        int numThousand=num/1000;
        int modThousand=num%1000;
        if(modThousand==0) return numberToWords(numThousand)+" Thousand";
        else return numberToWords(numThousand)+" Thousand "+numberToWords(modThousand);
      }else if(num>=1000000 && num<1000000000){
       int numMillion=num/1000000;
       int modMillion=num%1000000;
        if(modMillion==0) return numberToWords(numMillion)+" Million";
        else return numberToWords(numMillion)+" Million "+numberToWords(modMillion);
      }else{
       int numBillion=num/1000000000; 
       int modBillion=num%1000000000;
        if(modBillion==0) return numberToWords(numBillion)+" Billion";
        else return numberToWords(numBillion)+" Billion "+numberToWords(modBillion);
      }    
    }
}

public class Solution {
    public string NumberToWords(int num) {
      if(num<10){
       if(num==0)return "Zero"; 
       else if(num==1)return "One";
       else if(num==2) return "Two";
       else if(num==3) return "Three";
       else if(num==4) return "Four";
       else if(num==5) return "Five";
       else if(num==6) return "Six";
       else if(num==7) return "Seven";
       else if(num==8) return "Eight";
       else return "Nine";
      }else if(num>=10 && num<100){
        if(num==10)return"Ten";
        else if(num==11)return "Eleven";
        else if(num==12) return "Twelve";
        else if(num==13) return "Thirteen";
        else if(num==14) return "Fourteen";
        else if(num==15) return "Fifteen";
        else if(num==16) return "Sixteen";
        else if(num==17) return "Seventeen";
        else if(num==18) return "Eighteen";
        else if(num==19) return "Nineteen";
        else if(num==20) return "Twenty";
        else if(num==30) return "Thirty";
        else if(num==40) return "Forty";
        else if(num==50) return "Fifty";
        else if(num==60) return "Sixty";
        else if(num==70) return "Seventy";
        else if(num==80) return "Eighty";
        else if(num==90) return "Ninety";
        else if(num>60 && num<70) return "Sixty "+NumberToWords(num-60);
        else if(num>70 && num<80) return "Seventy " +NumberToWords(num-70);
        else if(num>80 && num<90) return "Eighty " +NumberToWords(num-80);
        else if(num>20 && num<30) return "Twenty "+NumberToWords(num-20);
        else if(num>30 && num<40) return "Thirty " +NumberToWords(num-30);
        else if(num>40 && num<50) return "Forty " +NumberToWords(num-40);
        else if(num>50 && num<60) return "Fifty "+NumberToWords(num-50);
        else if(num>60 && num<70) return "Sixty "+NumberToWords(num-60);
        else if(num>70 && num<80) return "Seventy " +NumberToWords(num-70);
        else if(num>80 && num<90) return "Eighty " +NumberToWords(num-80);
        else  return "Ninety "+NumberToWords(num-90);
      }else if(num>=100 && num<1000){
        int numHundred=num/100;
        int modHundred=num%100;
        if(modHundred==0) return NumberToWords(numHundred)+" Hundred";
        else return NumberToWords(numHundred)+" Hundred "+NumberToWords(modHundred);
      }else if(num>=1000 && num<1000000){
        int numThousand=num/1000;
        int modThousand=num%1000;
        if(modThousand==0) return NumberToWords(numThousand)+" Thousand";
        else return NumberToWords(numThousand)+" Thousand "+NumberToWords(modThousand);
      }else if(num>=1000000 && num<1000000000){
       int numMillion=num/1000000;
       int modMillion=num%1000000;
        if(modMillion==0) return NumberToWords(numMillion)+" Million";
        else return NumberToWords(numMillion)+" Million "+NumberToWords(modMillion);
      }else{
       int numBillion=num/1000000000; 
       int modBillion=num%1000000000;
        if(modBillion==0) return NumberToWords(numBillion)+" Billion";
        else return NumberToWords(numBillion)+" Billion "+NumberToWords(modBillion);
      }       
    }
}

JavaScript

var numberToWords = function(num) {
  if(num<10){
       if(num==0)return "Zero"; 
       else if(num==1)return "One";
       else if(num==2) return "Two";
       else if(num==3) return "Three";
       else if(num==4) return "Four";
       else if(num==5) return "Five";
       else if(num==6) return "Six";
       else if(num==7) return "Seven";
       else if(num==8) return "Eight";
       else return "Nine";
      }else if(num>=10 && num<100){
        if(num==10)return"Ten";
        else if(num==11)return "Eleven";
        else if(num==12) return "Twelve";
        else if(num==13) return "Thirteen";
        else if(num==14) return "Fourteen";
        else if(num==15) return "Fifteen";
        else if(num==16) return "Sixteen";
        else if(num==17) return "Seventeen";
        else if(num==18) return "Eighteen";
        else if(num==19) return "Nineteen";
        else if(num==20) return "Twenty";
        else if(num==30) return "Thirty";
        else if(num==40) return "Forty";
        else if(num==50) return "Fifty";
        else if(num==60) return "Sixty";
        else if(num==70) return "Seventy";
        else if(num==80) return "Eighty";
        else if(num==90) return "Ninety";
        else if(num>60 && num<70) return "Sixty "+numberToWords(num-60);
        else if(num>70 && num<80) return "Seventy " +numberToWords(num-70);
        else if(num>80 && num<90) return "Eighty " +numberToWords(num-80);
        else if(num>20 && num<30) return "Twenty "+numberToWords(num-20);
        else if(num>30 && num<40) return "Thirty " +numberToWords(num-30);
        else if(num>40 && num<50) return "Forty " +numberToWords(num-40);
        else if(num>50 && num<60) return "Fifty "+numberToWords(num-50);
        else if(num>60 && num<70) return "Sixty "+numberToWords(num-60);
        else if(num>70 && num<80) return "Seventy " +numberToWords(num-70);
        else if(num>80 && num<90) return "Eighty " +numberToWords(num-80);
        else  return "Ninety "+numberToWords(num-90);
      }else if(num>=100 && num<1000){
        let modHundred=num%100;
        let numHundred=(num-modHundred)/100;
        if(modHundred==0) return numberToWords(numHundred)+" Hundred";
        else return numberToWords(numHundred)+" Hundred "+numberToWords(modHundred);
      }else if(num>=1000 && num<1000000){
        let modThousand=num%1000;
        let numThousand=(num-modThousand)/1000;
        if(modThousand==0) return numberToWords(numThousand)+" Thousand";
        else return numberToWords(numThousand)+" Thousand "+numberToWords(modThousand);
      }else if(num>=1000000 && num<1000000000){
       let modMillion=num%1000000;
       let numMillion=(num-modMillion)/1000000;
        if(modMillion==0) return numberToWords(numMillion)+" Million";
        else return numberToWords(numMillion)+" Million "+numberToWords(modMillion);
      }else{
       let modBillion=num%1000000000;
       let numBillion=(num-modBillion)/1000000000; 
        if(modBillion==0) return numberToWords(numBillion)+" Billion";
        else return numberToWords(numBillion)+" Billion "+numberToWords(modBillion);
      }       
};

C++

class Solution {
public:
    string numberToWords(int num) {
     if(num<10){
       if(num==0)return "Zero"; 
       else if(num==1)return "One";
       else if(num==2) return "Two";
       else if(num==3) return "Three";
       else if(num==4) return "Four";
       else if(num==5) return "Five";
       else if(num==6) return "Six";
       else if(num==7) return "Seven";
       else if(num==8) return "Eight";
       else return "Nine";
      }else if(num>=10 && num<100){
        if(num==10)return"Ten";
        else if(num==11)return "Eleven";
        else if(num==12) return "Twelve";
        else if(num==13) return "Thirteen";
        else if(num==14) return "Fourteen";
        else if(num==15) return "Fifteen";
        else if(num==16) return "Sixteen";
        else if(num==17) return "Seventeen";
        else if(num==18) return "Eighteen";
        else if(num==19) return "Nineteen";
        else if(num==20) return "Twenty";
        else if(num==30) return "Thirty";
        else if(num==40) return "Forty";
        else if(num==50) return "Fifty";
        else if(num==60) return "Sixty";
        else if(num==70) return "Seventy";
        else if(num==80) return "Eighty";
        else if(num==90) return "Ninety";
        else if(num>60 && num<70) return "Sixty "+numberToWords(num-60);
        else if(num>70 && num<80) return "Seventy " +numberToWords(num-70);
        else if(num>80 && num<90) return "Eighty " +numberToWords(num-80);
        else if(num>20 && num<30) return "Twenty "+numberToWords(num-20);
        else if(num>30 && num<40) return "Thirty " +numberToWords(num-30);
        else if(num>40 && num<50) return "Forty " +numberToWords(num-40);
        else if(num>50 && num<60) return "Fifty "+numberToWords(num-50);
        else if(num>60 && num<70) return "Sixty "+numberToWords(num-60);
        else if(num>70 && num<80) return "Seventy " +numberToWords(num-70);
        else if(num>80 && num<90) return "Eighty " +numberToWords(num-80);
        else  return "Ninety "+numberToWords(num-90);
      }else if(num>=100 && num<1000){
        int numHundred=num/100;
        int modHundred=num%100;
        if(modHundred==0) return numberToWords(numHundred)+" Hundred";
        else return numberToWords(numHundred)+" Hundred "+numberToWords(modHundred);
      }else if(num>=1000 && num<1000000){
        int numThousand=num/1000;
        int modThousand=num%1000;
        if(modThousand==0) return numberToWords(numThousand)+" Thousand";
        else return numberToWords(numThousand)+" Thousand "+numberToWords(modThousand);
      }else if(num>=1000000 && num<1000000000){
       int numMillion=num/1000000;
       int modMillion=num%1000000;
        if(modMillion==0) return numberToWords(numMillion)+" Million";
        else return numberToWords(numMillion)+" Million "+numberToWords(modMillion);
      }else{
       int numBillion=num/1000000000; 
       int modBillion=num%1000000000;
        if(modBillion==0) return numberToWords(numBillion)+" Billion";
        else return numberToWords(numBillion)+" Billion "+numberToWords(modBillion);
      }       
    }
};

Data Structure & Algorithms

Sat, 05 Sep 2026 07:27:46 +0000

https://github.com/asimayazmrd0987-glitch/Data-Structures-and-Algorithms
This is my github repo where I work on DSA, and I am Still working on it.
It is Open Source, get it free.

Learn Number of Islands, Invert Binary Tree, and Course Schedule with Step-by-Step

Fri, 04 Sep 2026 16:08:26 +0000

Hoi hoi!

I’m @nyaomaru, a frontend engineer who is surprised by how cold it is in the Netherlands even though it’s still summer. 😸

Have you used DSA View View already? 👀👀

https://dev.to/nyaomaru/i-built-a-tool-to-visualize-dsa-lets-learn-together-dsa-view-view--djo

DSA View View allows you to understand DSA by visualizing how your implementation actually runs.

In the previous articles, we looked at problems like:

Two Sum
Binary Search
Bubble Sort
Valid Parentheses
Reverse Linked List
Maximum Depth of Binary Tree

https://dev.to/nyaomaru/is-learning-dsa-boring-lets-use-dsa-view-view-two-sum-binary-search-and-bubble-sort-374o

https://dev.to/nyaomaru/learn-valid-parentheses-reverse-linked-list-and-tree-max-depth-with-step-by-step-visualization-in-3o09

This time, let's try three more classic problems:

Number of Islands
Invert Binary Tree
Course Schedule

These three problems introduce some very useful ways of thinking:

Explore connected things
Transform a tree with recursion
Resolve dependencies in the right order

The implementations are not huge.

But the runtime can become surprisingly difficult to hold in our heads.

So let's view what actually happens. 👀

Let's learn together! 😸

🏝️ Number of Islands

Let's start with Number of Islands.

Suppose we have this grid:

1 means land. 🏝️

0 means water. 🌊

Land connected vertically or horizontally belongs to the same island.

So how many islands are there?

Let's look at the first group.

1 1
1

These cells are connected.

So they form one island.

On the right side

    1
  1 1

Those cells are also connected.

So the answer is 2.

Nice! 🏝️🏝️

But how do we make the code understand that several 1s belong to the same island?

Find One Land, Then Explore All Connected Land

The basic idea is

When we find a new 1, count one island and visit all land connected to it.

Let's use this implementation.

function numIslands(grid: string[][]): number {
  let islands = 0;

  const visit = (row: number, col: number): void => {
    if (row < 0 || col < 0) return;
    if (row >= grid.length || col >= grid[row].length) return;
    if (grid[row][col] !== "1") return;

    grid[row][col] = "0";
    visit(row + 1, col);
    visit(row - 1, col);
    visit(row, col + 1);
    visit(row, col - 1);
  };

  for (let row = 0; row < grid.length; row++) {
    for (let col = 0; col < grid[row].length; col++) {
      if (grid[row][col] === "1") {
        islands++;
        visit(row, col);
      }
    }
  }

  return islands;
}

There are two important parts.

First, we scan the grid

for (let row = 0; row < grid.length; row++) {
  for (let col = 0; col < grid[row].length; col++) {

Then, when we find land

if (grid[row][col] === "1") {
  islands++;
  visit(row, col);
}

We count a new island.

But then visit() does something important.

It removes all land connected to that island from future consideration.

Why Do We Change `1` to `0`?

Inside visit() we have

grid[row][col] = "0";

At first, changing land into water looks a little strange. 😿

But here, 0 really means

We already visited this land.

Let's follow a tiny example.

1 1
1 0

We start at the top-left. And we found land! So

islands = 1

Then

visit(0, 0);

Inside visit(), we mark it as visited.

0 1
1 0

Then we visit the four directions

down
up
right
left

Going down finds another 1.

0 1
1 0
↑

So we visit it too.

0 1
0 0

Going right from the original cell also finds land.

Visit it.

0 0
0 0

Now the whole connected island has disappeared from our search.

When the outer loops continue, there is no 1 left in that island to count again.

That's the key idea.

Count once, then mark the whole connected area as visited.

Why Four Recursive Calls?

We use

visit(row + 1, col);
visit(row - 1, col);
visit(row, col + 1);
visit(row, col - 1);

That means

        up
         ↑
left ← current → right
         ↓
        down

Each visited cell asks

Is there more land next to me?

And every newly discovered land cell asks the same question again.

This continues until we reach:

water
outside the grid
land we already visited

Those cases stop the recursion.

The Base Cases

These lines protect us

if (row < 0 || col < 0) return;
if (row >= grid.length || col >= grid[row].length) return;
if (grid[row][col] !== "1") return;

So,

If we walk outside the grid, stop.
If we reach water, stop.
If we reach a cell we already changed to 0, stop.

Otherwise, continue exploring.

Let's Follow Two Islands

Consider

1 1 0
0 0 1
0 1 1

The scan begins at the top-left.

Found land.

islands = 1

visit() removes everything connected to it.

0 0 0
0 0 1
0 1 1

The loops continue.

Eventually we reach

Another 1.

islands = 2

And visit() explores that entire connected area.

0 0 0
0 0 0
0 0 0

Done!

2 islands

🎉

Complexity

Every cell is processed at most a small number of times.

If the grid has m rows and n columns

Time:  O(m × n)

In the worst case, the recursive call stack may grow with the number of land cells.

Space: O(m × n)

👀 Let's View View It

This is one of those algorithms where the final code is pretty small.

But while reading it, there are a lot of things moving at once

row
col
grid
islands
recursive calls

And then suddenly we see

grid[row][col] = "0";

Why did that cell disappear?
Which recursive call are we inside?
Which cells belong to the current island?
Where will the outer loop continue after recursion finishes?

That is a lot to simulate mentally. 😿

https://dsa-view-view.vercel.app/#s=j.eyJlIjoibnVtYmVyLW9mLWlzbGFuZHMiLCJsIjoidHlwZXNjcmlwdCIsIm0iOiJ2ZXJpZmljYXRpb24iLCJ2IjoxfQ

When we view it step by step, the idea becomes much more visual.

Find land
  ↓
islands++
  ↓
visit connected land
  ↓
mark it visited
  ↓
expand up / down / left / right
  ↓
return to scanning
  ↓
find next island

Instead of thinking about recursion first, I like to think about it like this

Find one island, paint the whole island away, then keep searching.

🏝️😸

🌳 Invert Binary Tree

Next, let's invert a binary tree.

Suppose we have

We want to change

Every left child becomes the right child.

Every right child becomes the left child.

Simple, right?

Well, the final implementation is also surprisingly small.

function invertTree(root: TreeNode | null): TreeNode | null {
  if (root === null) return null;

  const left = invertTree(root.left);
  const right = invertTree(root.right);

  root.left = right;
  root.right = left;

  return root;
}

That's almost suspiciously short. 👀

Go Down First

Let's use a smaller tree.

    1
   / \
  2   3

We start at node 1.

But we don't swap immediately.

First,

const left = invertTree(root.left);

So we go to node 2.

Node 2 also tries to invert its left child.

But there is no child.

if (root === null) return null;

returns null.

The same thing happens on the right side of node 2.

Now node 2 has

left = null
right = null

root.left = right;
root.right = left;

does not visibly change anything.

Node 2 returns.

Then node 1 explores its right subtree.

Node 3 also has no children, so it returns after the same process.

Only then do we come back to node 1.

Now

left = 2
right = 3

And we do

root.left = right;
root.right = left;

    1
   / \
  2   3

becomes 👇

    1
   / \
  3   2

Done! 🎉

The Important Part: The Swap Happens on the Way Back

This is what makes the recursive solution interesting.

The function first goes down.

1
↓
2
↓
null

Then it comes back.

Later it explores the other side.

1
↓
3
↓
null

And after both children have returned, the current node swaps them.

So the flow is more like

Go left
  ↓
Invert left subtree
  ↓
Go right
  ↓
Invert right subtree
  ↓
Swap the returned subtrees
  ↓
Return current node

The tree transformation is built while recursion unwinds.

A Slightly Bigger Example

Let's look at

We start at 4.

invertTree(4)

Then

invertTree(2)

Then

invertTree(1)

Node 1 returns.

Then node 3 returns.

Now node 2 has

left = 1
right = 3

Swap them.

    2
   / \
  3   1

Then recursion returns to 4.

The right subtree rooted at 7 is also processed.

Finally node 4 receives

left = inverted subtree rooted at 2
right = inverted subtree rooted at 7

and swaps them.

The final tree becomes

The interesting thing is that each node only needs to know about its own two children.

It doesn't need to understand the whole tree.

Complexity

We visit every node once.

Time: O(n)

The recursive call stack depends on the height of the tree.

Space: O(h)

For a balanced tree

O(log n)

In the worst case

O(n)

👀 Let's View View It

This is exactly where recursion can become difficult to mentally simulate.

The code says

const left = invertTree(root.left);
const right = invertTree(root.right);

Then

root.left = right;
root.right = left;

But my brain immediately starts asking:

Which root are we talking about now?
Did node 2 already swap?
Are we still going down?
Or are we coming back up?
What does left contain at this moment?

😿

https://dsa-view-view.vercel.app/#s=j.eyJlIjoiaW52ZXJ0LWJpbmFyeS10cmVlIiwibCI6InR5cGVzY3JpcHQiLCJtIjoidmVyaWZpY2F0aW9uIiwidiI6MX0

When we step through the runtime, we can separate two different movements.

The final code is short.

But the actual runtime has a rhythm 🎵

Go down
↓
Return
↓
Swap
↓
Return
↓
Swap

Once I can see that rhythm, the recursive solution feels much less magical. 🌳😸

🎓 Course Schedule

Finally, let's look at Course Schedule.

This one is a little more difficult.

Suppose we have three courses

0
1
2

And the prerequisites are

[1, 0]
[2, 1]

That means

To take course 1, finish course 0 first.
To take course 2, finish course 1 first.

So the dependency looks like

0 → 1 → 2

Can we finish all courses?

Yes.

We can take them in this order 0 → 1 → 2.

Easy.

But what if the dependencies look like this?

0 → 1
↑   ↓
└── 2

Now

0 needs 2
1 needs 0
2 needs 1

Everyone is waiting for someone else.

We can never start.

That is a cycle.

And if there is a cycle, we cannot finish all courses.

Build the Graph

Here is the implementation:

function canFinish(numCourses: number, prerequisites: number[][]): boolean {
  const graph: number[][] = Array.from({ length: numCourses }, () => []);
  const indegree: number[] = Array(numCourses).fill(0);

  for (const [course, prerequisite] of prerequisites) {
    graph[prerequisite].push(course);
    indegree[course]++;
  }

  const queue: number[] = [];
  for (let course = 0; course < numCourses; course++) {
    if (indegree[course] === 0) queue.push(course);
  }

  let completed = 0;
  for (let head = 0; head < queue.length; head++) {
    const course = queue[head];
    completed++;

    for (const next of graph[course]) {
      indegree[next]--;
      if (indegree[next] === 0) queue.push(next);
    }
  }

  return completed === numCourses;
}

There are a few moving parts here.

graph
indegree
queue
completed

This is exactly the kind of algorithm where every individual line makes sense.

but the whole thing can still feel confusing. 😿

Let's break it down.

What Is `graph`?

For

0 → 1 → 2

we want to know

After I finish this course, which courses become closer to being available?

graph[0] = [1]
graph[1] = [2]
graph[2] = []

That means

Finish 0
↓
course 1 is affected

Finish 1
↓
course 2 is affected

We build that here

graph[prerequisite].push(course);

What Is `indegree`?

indegree tells us how many prerequisites a course is still waiting for.

For

0 → 1 → 2

we have

course 0: 0 prerequisites
course 1: 1 prerequisite
course 2: 1 prerequisite

indegree = [0, 1, 1]

Course 0 is special. Because it does not need anything before it.

So we can start there immediately.

Start With Courses That Need Nothing

We build the queue

for (let course = 0; course < numCourses; course++) {
  if (indegree[course] === 0) queue.push(course);
}

For our example

indegree = [0, 1, 1]

Only course 0 has zero prerequisites.

queue = [0]

This means

Course 0 is currently available.

Finish Course 0

Take

course = 0

Then

completed++;

completed = 1

Now look at courses depending on 0.

graph[0] = [1]

Course 1 was waiting for one prerequisite.

But course 0 is now complete.

indegree[1]--;

Then

indegree[1] = 0

Now course 1 needs nothing.

So we add it to the queue.

queue = [0, 1]

Finish Course 1

course = 1

Now

completed = 2

Course 2 depends on 1.

indegree[2]: 1 → 0

Add it to the queue.

queue = [0, 1, 2]

Finish Course 2

Finally

course = 2

completed = 3

And

numCourses = 3

Therefore

completed === numCourses; // true

We can finish everything! 🎉

Why Does This Detect a Cycle?

Now let's try

0 → 1
↑   ↓
└── 2

Every course has one prerequisite.

indegree = [1, 1, 1]

We try to build the initial queue.

if (indegree[course] === 0)

But there is no course with indegree 0.

So, nothing can start.

Therefore

completed = 0

And,

0 === 3 // false

We cannot finish the courses.

Another Example

Suppose

0 → 2
1 → 2
2 → 3

Course 2 needs both 0 and 1.

indegree = [0, 0, 2, 1]

The initial queue is

queue = [0, 1]

Finish 0.

indegree[2]: 2 → 1

Course 2 is still waiting.

So don't add it yet.

Finish 1.

indegree[2]: 1 → 0

Now course 2 is ready.

queue = [0, 1, 2]

Finish 2.

indegree[3]: 1 → 0

Now

queue = [0, 1, 2, 3]

Everything can be completed.

This is the key idea

When all prerequisites for a course are resolved, that course becomes available.

Why Use `head` Instead of `shift()`?

The queue is processed like this

for (let head = 0; head < queue.length; head++) {
  const course = queue[head]

Instead of repeatedly doing

queue.shift();

we keep an index pointing to the next item to process.

So the queue can grow while we iterate through it.

For example

queue = [0]

process 0
↓
queue = [0, 1]

process 1
↓
queue = [0, 1, 2]

head simply moves forward.

0 → 1 → 2
↑
head

Then

0 → 1 → 2
    ↑
   head

Then

0 → 1 → 2
        ↑
       head

Complexity

V = number of courses
E = number of prerequisite relationships

We build the graph once and process every course and edge.

Time: O(V + E)
Space: O(V + E)

👀 Let's View View It

This is probably the most interesting visualization of the three.

Because there are several things changing together.

graph
indegree
queue
head
completed

If I only read

indegree[next]--;
if (indegree[next] === 0) queue.push(next);

I understand the syntax.

But I may still ask:

Why did this course become available now?
Which prerequisite was removed?
Why is this course still not in the queue?
What does completed tell us?
Where exactly does the cycle get stuck?

https://dsa-view-view.vercel.app/#s=j.eyJlIjoiY291cnNlLXNjaGVkdWxlIiwibCI6InR5cGVzY3JpcHQiLCJtIjoidmVyaWZpY2F0aW9uIiwidiI6MX0

When we view the runtime, we can watch the dependencies disappear.

0 → 1 → 2

indegree = [0, 1, 1]
queue = [0]

       ↓ finish 0

indegree = [0, 0, 1]
queue = [0, 1]

       ↓ finish 1

indegree = [0, 0, 0]
queue = [0, 1, 2]

       ↓ finish 2

completed = 3

The code stops feeling like mysterious bookkeeping.

We're really doing one simple thing:

Keep taking courses that are ready, and make their dependent courses closer to being ready.

If eventually every course becomes ready

completed === numCourses

there is no blocking cycle.

If some courses never become ready

completed < numCourses

something is stuck in a cycle. 🎓😸

🧠 What Did We Actually Learn?

These three problems look very different.

But each one teaches a useful way of thinking.

Number of Islands

When you find one part of a connected group, explore the entire group before continuing.

What else is connected to this?

Invert Binary Tree

Let recursive calls solve the smaller subtrees first, then transform the current node using their results.

Can my children finish their work before I change this node?

Course Schedule

Process things that have no unresolved dependencies, then use them to unlock more work.

What can I safely process right now?

The implementations are not very long.

But each one introduces a different mental model.

DFS on a grid
Recursive tree transformation
Topological sorting

And once again, the syntax is not really the hardest part.

The difficult part is keeping track of the changing state.

Where are we?
What changed?
What is waiting?
What has already been visited?
Which recursive call are we inside?

Sometimes I can read every line and still lose the thread somewhere in the middle. 😿

That's exactly when I want to view it. 👀👀

🎯 Conclusion

In this article, we looked at:

Number of Islands with recursive grid traversal
Invert Binary Tree with recursion
Course Schedule with topological sorting

And more importantly, we followed what changed while each algorithm was running.

For Number of Islands, we watched connected land disappear as it became visited.

1 → 0

For Invert Binary Tree, we watched recursive calls go down and the tree change while they returned.

go down
↓
come back
↓
swap

For Course Schedule, we watched prerequisites disappear and new courses enter the queue.

indegree--
↓
0 prerequisites
↓
queue.push()

This is exactly the kind of thing I built DSA View View for.

https://dsa-view-view.vercel.app

You can write or load a TypeScript implementation, run it with your own inputs, and move backward and forward through the runtime.

If you are learning DSA too, try viewing one of these problems step by step.

Especially when the implementation looks short, but your brain still says

Wait... what just changed? 😿

Seeing the runtime may make the idea much easier to follow.

And if there is a DSA problem you want me to cover next, please let me know in the comments!

I still have many algorithms to learn myself. 😸

Let's train our DSA muscles together! 💪

If you like DSA View View, please give it a star ⭐

https://github.com/nyaomaru/dsa-view-view

See you in the next article!

Learn Valid Parentheses, Reverse Linked List, and Tree Max Depth with Step-by-Step Visualization in

Fri, 28 Aug 2026 14:46:28 +0000

Hoi hoi!

I’m @nyaomaru, a frontend engineer who struggles to make game sounds. 😿

Have you used DSA View View already? 👀👀

https://dev.to/nyaomaru/i-built-a-tool-to-visualize-dsa-lets-learn-together-dsa-view-view--djo

DSA View View allows you to understand DSA by visualizing how your implementation actually runs.

In the previous article, we looked at:

Two Sum
Binary Search
Bubble Sort

https://dev.to/nyaomaru/is-learning-dsa-boring-lets-use-dsa-view-view-two-sum-binary-search-and-bubble-sort-374o

This time, let's try three more classic problems:

Valid Parentheses
Reverse Linked List
Maximum Depth of Binary Tree

These problems introduce three very different ideas:

Stack
Pointer manipulation
Recursion

And all three can become confusing when we only stare at the final code.

So let's view what actually happens. 👀

I'm still learning DSA too, so let's learn together! 😸

🥞 Valid Parentheses

Let's start with Valid Parentheses.

Suppose we have this string:

()[]{}

Every opening bracket has a matching closing bracket.

So this is valid. ✅

But this

([)]

is not valid. ❌

Why?

Because the brackets close in the wrong order.

(
  [
)
  ]

The [ should be closed before the (.

So how can we keep track of that order?

Use a Stack

A stack follows a simple rule:

The last thing we put in is the first thing we take out.

This is called LIFO (Last In / First Out)

Imagine stacking plates.

    🍽️  ← remove first
    🍽️
    🍽️

The last plate we put on top is the first one we can take.

Parentheses work in the same way.

If we see:

(
[
{

then the brackets must close in reverse order

}
]
)

So a stack is a very natural fit.

Here is the implementation:

function isValid(s: string): boolean {
  const stack: string[] = [];

  const pairs: Record<string, string> = {
    ")": "(",
    "]": "[",
    "}": "{",
  };

  for (const char of s) {
    if (char === "(" || char === "[" || char === "{") {
      stack.push(char);
      continue;
    }

    if (stack.length === 0) return false;

    const target = stack.pop();
    if (target !== pairs[char]) {
      return false;
    }
  }

  return stack.length === 0;
}

The important part is what happens to stack.

Let's use

([])

At first

stack = []

We see

It's an opening bracket.

Push it.

stack = ["("]

Next,

Push again.

stack = ["(", "["]

Then,

This is a closing bracket.

What should it close?

And what is currently on top of the stack?

Perfect. ✅

So we remove it.

stack = ["("]

Finally,

It should close

The top of the stack is also

Pop!

stack = []

We reached the end with an empty stack.

Valid! 🎉

What About an Invalid Example?

Consider

([)]

We start the same way.

(
↓
stack = ["("]

[
↓
stack = ["(", "["]

Then we find

A ) needs

But the top of our stack is

They don't match.

expected: (
actual:   [

So we immediately know the string is invalid.

Complexity

We walk through the string once.

Time:  O(n)
Space: O(n)

In the worst case, the stack may contain all opening brackets.

👀 Let's View View It

This is where the stack becomes much easier to understand.

When we only read.

stack.push(char);

And

stack.pop();

It can be easy to lose track of what is actually inside the stack.

Especially with something like.

({[]})

What is on top right now?

Which opening bracket are we trying to close?

Instead of remembering everything in our head, we can follow the stack changing step by step.

https://dsa-view-view.vercel.app/#s=j.eyJlIjoidmFsaWQtcGFyZW50aGVzZXMiLCJsIjoidHlwZXNjcmlwdCIsIm0iOiJ2ZXJpZmljYXRpb24iLCJ2IjoxfQ

Conceptually, we can see:

(
↓
[(]

{
↓
[(, {]

[
↓
[(, {, []

]
↓
[(, {]

}
↓
[(]

)
↓
[]

That's the whole idea.

Remember the opening brackets, and always match the most recent one first.

Stack suddenly feels much less mysterious. 🥞😸

🔗 Reverse Linked List

Next, let's reverse a linked list.

Suppose we have

1 → 2 → 3 → 4 → 5

We want

5 → 4 → 3 → 2 → 1

At first glance, this sounds simple.

Just reverse it!

But linked lists are a little different from arrays.

With an array, the values live in positions like

0  1  2  3  4
↓  ↓  ↓  ↓  ↓
1  2  3  4  5

A linked list instead consists of nodes pointing to the next node.

1 → 2 → 3 → 4 → 5 → null

Each arrow matters. To reverse the list, we need to reverse those arrows.

1 ← 2 ← 3 ← 4 ← 5

And this is where things can get confusing.

Because if we change an arrow too early...

we may lose the rest of the list. 😿

Three Important Variables

A common iterative solution uses three variables

prev
current
next

Here is the implementation:

function reverseList(head: ListNode | null): ListNode | null {
  let prev: ListNode | null = null;
  let current = head;

  while (current !== null) {
    const next = current.next;

    current.next = prev;

    prev = current;
    current = next;
  }

  return prev;
}

It's short.

But there is a lot happening inside these few lines.

Let's follow it carefully.

We start with

1 → 2 → 3 → null

And

prev = null
current = 1

Step 1: Save the Next Node

First

const next = current.next;

next = 2

Why do we need this?

Because we're about to change

1 → 2

If we change that arrow without remembering 2, we lose access to the rest of the list.

So first

Save where we need to go next.

Step 2: Reverse the Arrow

Now

current.next = prev;

Originally

1 → 2

But prev is

null

So now

1 → null

The first arrow has been reversed.

Step 3: Move `prev`

prev = current;

prev = 1

Step 4: Move `current`

Finally

current = next;

We saved 2 earlier.

So now

current = 2

Our state looks like this

null ← 1    2 → 3 → null
       ↑    ↑
      prev current

Then we do exactly the same thing again.

Save:

next = 3

Reverse

2 → 1

Move

prev = 2
current = 3

Now

null ← 1 ← 2    3 → null
           ↑    ↑
          prev  current

One more time

next = null

Reverse

3 → 2

Move

prev = 3
current = null

And now

null ← 1 ← 2 ← 3
               ↑
              prev

The loop stops because

current === null

And prev is the new head.

return prev;

Done! 🎉

Complexity

We visit each node once.

Time:  O(n)
Space: O(1)

We don't create another linked list.

We only move a few pointers.

👀 Let's View View It

This is exactly the kind of code that I find difficult to understand by reading alone.

These four lines:

const next = current.next;
current.next = prev;
prev = current;
current = next;

look simple.

But when I first see code like this, my brain starts asking.

Wait.

- Where is current now?
- Did we lose next?
- Which arrow changed?
- What exactly does prev point to?

😿

https://dsa-view-view.vercel.app/#s=j.eyJlIjoicmV2ZXJzZS1saXN0IiwibCI6InR5cGVzY3JpcHQiLCJtIjoidmVyaWZpY2F0aW9uIiwidiI6MX0

When we visualize each step, we can actually follow the pointers moving.

prev      current
 ↓           ↓
null         1 → 2 → 3

      ↓↓↓

null ← 1     2 → 3
       ↑     ↑
      prev current

      ↓↓↓

null ← 1 ← 2     3
           ↑     ↑
          prev current

      ↓↓↓

null ← 1 ← 2 ← 3
               ↑
              prev

The algorithm becomes much simpler when we stop thinking of it as four mysterious assignments.

It's really just

Save next
  ↓
Reverse arrow
  ↓
Move prev
  ↓
Move current
  ↓
Repeat

Nice! 🔗😸

🌳 Maximum Depth of Binary Tree

Finally, let's look at a tree.

Consider this binary tree.

What is its maximum depth?

The longest path from the root to a leaf contains three nodes:

So the answer is.

How can we calculate that?

Think About a Smaller Tree

Suppose we are standing at one node.

We don't really need to understand the entire tree at once.

We only need to ask.

How deep is the left subtree?

How deep is the right subtree?

Then choose the larger one.

And add 1 for the current node.

That's exactly what this implementation does.

function maxDepth(root: TreeNode | null): number {
  if (root === null) {
    return 0;
  }

  const leftDepth = maxDepth(root.left);
  const rightDepth = maxDepth(root.right);

  return Math.max(leftDepth, rightDepth) + 1;
}

The important idea is

Math.max(leftDepth, rightDepth) + 1;

But recursion can feel strange.

When we call

maxDepth(root.left);

where does the current function go?

And how do all those calls eventually become one number?

Let's follow a small example.

We start at

But before 1 can know its depth, it asks its left child

maxDepth(2)

Node 2 asks

maxDepth(4)

Node 4 has no children.

So both sides eventually reach

null

And

maxDepth(null);

returns

Therefore node 4 can calculate

max(0, 0) + 1
= 1

Now we return to node 2.

Its left side has depth

Its right side is null

max(1, 0) + 1
= 2

Now return to node 1.

Eventually its right subtree also returns

So node 1 gets

leftDepth = 2
rightDepth = 1

And calculates

max(2, 1) + 1
= 3

Answer

🎉

The Interesting Part: Going Down and Coming Back Up

This is what makes recursion interesting.

First, the function calls go down the tree.

1
↓
2
↓
4
↓
null

But the answers are built while returning back up.

null → 0
4    → 1
2    → 2
1    → 3

So recursion isn't only

Keep calling the same function.

There are really two directions.

Go down
  ↓
Reach the base case
  ↓
Return values back up

The base case here is

if (root === null) {
  return 0;
}

Without it, the recursion would have no place to stop.

Complexity

Every node is visited once.

Time: O(n)

The recursive call stack depends on the height of the tree.

Space: O(h)

where h is the height of the tree.

For a balanced tree, that is roughly

O(log n)

In the worst case, if the tree looks like a linked list

the depth can become

O(n)

👀 Let's View View It

Recursion is probably my favorite example for visualization.

Because the final implementation is tiny

const leftDepth = maxDepth(root.left);
const rightDepth = maxDepth(root.right);

return Math.max(leftDepth, rightDepth) + 1;

But a lot is hidden inside those function calls.

When reading the code, it can feel like

maxDepth()
inside maxDepth()
inside maxDepth()
inside maxDepth()
...

Where are we now? 😿

https://dsa-view-view.vercel.app/#s=j.eyJlIjoidHJlZS1kZXB0aCIsImwiOiJ0eXBlc2NyaXB0IiwibSI6InZlcmlmaWNhdGlvbiIsInYiOjF9

When we step through the execution, we can follow both parts

Going down

1
↓
2
↓
4
↓
null

and then

Coming back

null → 0
↓
4 → 1
↓
2 → 2
↓
1 → 3

That makes the recursive idea much easier to see.

Ask the smaller subproblems for their answers, then use those answers to build the current answer.

🌳😸

🧠 What Did We Actually Learn?

These three problems look completely different.

But each one introduces a very useful way of thinking.

Valid Parentheses

Use a stack when the most recent item needs to be handled first.

What was the last thing I opened?

Reverse Linked List

When changing references, save what you still need before breaking the old connection.

Where do I need to go next before I change this pointer?

Maximum Depth of Binary Tree

Break a problem into smaller versions of the same problem.

Can I get the answers from my children and build my answer from them?

This is one reason I like learning these problems together.

The implementations are not very large.

But each one introduces a completely different mental model

Stack
Pointer
Recursion

And those mental models are much harder to learn than the syntax itself.

Sometimes the code tells us what happens.

But I also want to see how it happens.

I want to view it. 👀👀

🎯 Conclusion

In this article, we looked at:

Valid Parentheses with a stack
Reverse Linked List with pointer manipulation
Maximum Depth of Binary Tree with recursion

And more importantly, we followed the state while each algorithm was running.

We watched change the stack.

stack.push() / stack.pop()

We watched move through a linked list.

prev
current
next

And we watched recursive calls travel down a tree and return their answers back up.

This is exactly the kind of thing I built DSA View View for.

https://dsa-view-view.vercel.app

You can write or load a TypeScript implementation, run it with your own inputs, and move backward and forward through the runtime.

If you are learning DSA too, try viewing one of these problems step by step.

Especially if a solution feels like

I understand every line individually... but somehow I still don't understand the whole thing. 😿

Seeing the runtime may connect those pieces together.

And if there is a DSA problem you want me to cover next, please let me know in the comments!

I still have many algorithms to learn myself. 😸

Let's train our DSA muscles together! 💪

If you like DSA View View, please give it a star ⭐

https://github.com/nyaomaru/dsa-view-view

See you in the next article!

1366. Rank Teams by Votes

Wed, 19 Aug 2026 18:52:21 +0000

Problem
In a special ranking system, each voter gives a rank from highest to lowest to all teams participating in the competition.

The ordering of teams is decided by who received the most position-one votes. If two or more teams tie in the first position, we consider the second position to resolve the conflict, if they tie again, we continue this process until the ties are resolved. If two or more teams are still tied after considering all positions, we rank them alphabetically based on their team letter.

You are given an array of strings votes which is the votes of all voters in the ranking systems. Sort all teams according to the ranking system described above.

Return a string of all teams sorted by the ranking system.

Example 1:

Input: votes = ["ABC","ACB","ABC","ACB","ACB"]
Output: "ACB"
Explanation:
Team A was ranked first place by 5 voters. No other team was voted as first place, so team A is the first team.
Team B was ranked second by 2 voters and ranked third by 3 voters.
Team C was ranked second by 3 voters and ranked third by 2 voters.
As most of the voters ranked C second, team C is the second team, and team B is the third.
Example 2:

Input: votes = ["WXYZ","XYZW"]
Output: "XWYZ"
Explanation:
X is the winner due to the tie-breaking rule. X has the same votes as W for the first position, but X has one vote in the second position, while W does not have any votes in the second position.
Example 3:

Input: votes = ["ZMNAGUEDSJYLBOPHRQICWFXTVK"]
Output: "ZMNAGUEDSJYLBOPHRQICWFXTVK"
Explanation: Only one voter, so their votes are used for the ranking.

Constraints:

1 <= votes.length <= 1000
1 <= votes[i].length <= 26
votes[i].length == votes[j].length for 0 <= i, j < votes.length.
votes[i][j] is an English uppercase letter.
All characters of votes[i] are unique.
All the characters that occur in votes[0] also occur in votes[j] where 1 <= j < votes.length.

Discussion
This problem can be solved using 2 data structures- a hashmap and a heap. We use the map to store the votes by each judge and the heap to sort the teams. We create a comparator to sort the teams and initialize the heap using it.
We then traverse the votes array to calculate the votes and create the map.Once this is done we add the keys of the map which are the teams to the heap and pull the elements off one by one to get the final string.

Solution

Java

class Solution {
    public String rankTeams(String[] votes) {
      HashMap<Character,int[]>map=new  HashMap<>();
      String answer="";
      for(int i=0;i<votes.length;i++){
       String vote=votes[i];
       for(int j=0;j<vote.length();j++){
        char team=vote.charAt(j);
        if(!map.containsKey(team)){
         int [] counts= new int[vote.length()];
         counts[j]++;
         map.put(team,counts);
        }else{
          int [] counts =map.get(team);
          counts[j]++;
          map.replace(team,counts);
        }
       } 
      }
      PriorityQueue<Character> pq = new PriorityQueue<>((a, b) -> {
        int[] va = map.get(a);
        int[] vb = map.get(b);
        for (int i = 0; i < va.length; i++) {
            if (va[i] != vb[i]) {
            return Integer.compare(vb[i], va[i]);
             }
        }
        return Character.compare(a, b);
      });  
      for (char team : map.keySet()) pq.offer(team);
      while(!pq.isEmpty()){
       char ch=pq.poll();
       answer+=ch; 
      }
      return answer;
    }
}

Is Learning DSA Boring? Let's Use DSA View View 👀👀 (Two Sum, Binary Search, and Bubble Sort)

Wed, 19 Aug 2026 15:14:55 +0000

Hoi hoi!

I’m @nyaomaru, a frontend engineer who dislikes crowded places, so I'm planning to take a quiet vacation in September. 🏝️

Have you used DSA View View already? 👀👀

https://coderlegion.com/22758/i-built-a-tool-to-visualize-dsa-lets-learn-together-dsa-view-view

DSA View View allows you to understand DSA by visualizing how your implementation actually runs.

But just introducing the tool is not enough.

Can it actually help us understand DSA?

In this article, we'll walk through three classic problems:

Two Sum
Binary Search
Bubble Sort

We'll first understand the algorithm, and then see what is actually happening with DSA View View.

Let's learn together! 😸

🗺️ Two Sum

Let's start with a very famous problem.

Given an array of numbers and a target value, find the indices of two numbers whose sum equals the target.

For example,

nums = [2, 7, 11, 15];
target = 9;

The answer is

[0, 1];

Because

2 + 7 = 9

Simple!

So, how should we find them? 🤔

Brute Force

The easiest approach is probably checking every possible pair.

function twoSum(nums: number[], target: number): number[] {
  for (let i = 0; i < nums.length; i++) {
    for (let j = i + 1; j < nums.length; j++) {
      if (nums[i] + nums[j] === target) {
        return [i, j];
      }
    }
  }

  return [];
}

This works.

But if the array becomes large, we may need to compare a lot of pairs, right?

The time complexity is O(n²)

Can we avoid checking the same values again and again?

Yes.

Let's use a Map.

function twoSum(nums: number[], target: number): number[] {
  const seen = new Map<number, number>();

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

    if (seen.has(need)) {
      return [seen.get(need)!, i];
    }

    seen.set(current, i);
  }

  return [];
}

The important part is this 👇

const need = target - current;

Instead of asking

Which two numbers should I combine?

we ask

What number do I need to complete the target?

Let's follow the example.

At first

current = 2
target = 9

need = 9 - 2
     = 7

Have we already seen 7?

No.

So we remember 2.

seen = {
  2 → 0
}

current = 7
target = 9

need = 9 - 7
     = 2

Have we already seen 2?

Yes! 👀👀

seen = {
  2 → 0
}

return [0, 1];

Done!

Because we only need to walk through the array once, the time complexity becomes.

Time:  O(n)
Space: O(n)

👀 Let's View View It

The implementation is quite small.

But when I was first learning this pattern, this part still felt a little magical.

if (seen.has(need))

Where did need come from?
What is inside seen at this moment?
Why does checking the previous values solve the problem?

This is exactly where visualization helps.

{% embed https://dsa-view-view.vercel.app/#s=j.eyJlIjoidHdvLXN1bSIsImwiOiJ0eXBlc2NyaXB0IiwibSI6InZlcmlmaWNhdGlvbiIsInYiOjF9 %}

With DSA View View, we can move through the runtime one step at a time and inspect how the values change.

2
↓
Need 7
↓
Remember 2
↓
7
↓
Need 2
↓
Found 2!
🎉

Now the Map is not just some mysterious trick.

We can actually follow the idea.

Remember what we have already seen, and check whether the value we need is there.

Nice! 😸

🔍 Binary Search

Next is Binary Search.

Suppose we have this sorted array

[1, 3, 5, 7, 9, 11, 13]

And we want to find

Of course, we could start from 1 and check every number.

1 → 3 → 5 → 7 → 9 → 11

That works.

But Binary Search does something smarter.

Instead of checking from the beginning, it checks the middle.

[1, 3, 5, 7, 9, 11, 13]
          ↑
         mid

Our middle value is 7.

We are looking for 11.

11 > 7

Because the array is sorted, we already know something very useful.

Everything on the left side of 7 is also smaller than 11.

So, we don't need that half anymore. 👋

[1, 3, 5, 7, 9, 11, 13]
             └───────┘
               search

Now we check the middle of the remaining range.

[9, 11, 13]
     ↑
    mid

And

11 === 11

Found it! 🎉

Here is the implementation.

function binarySearch(nums: number[], target: number): number {
  let left = 0;
  let right = nums.length - 1;

  while (left <= right) {
    const mid = Math.floor((left + right) / 2);

    if (nums[mid] === target) {
      return mid;
    }

    if (nums[mid] < target) {
      left = mid + 1;
    } else {
      right = mid - 1;
    }
  }

  return -1;
}

There are three important variables.

left
right
mid

They represent the current search range.

For our example, they start like this

left = 0
right = 6
mid = 3

[1, 3, 5, 7, 9, 11, 13]
 ↑        ↑          ↑
left     mid       right

Because

nums[mid] < target;

we move left.

left = mid + 1;

Now

[1, 3, 5, 7, 9, 11, 13]
             ↑   ↑   ↑
           left mid right

And 11 is found.

Why Is Binary Search Fast?

This is the interesting part.

Each step removes about half of the remaining candidates.

If there are 1,000 values, we don't necessarily need 1,000 checks.

It becomes roughly

1000
↓
500
↓
250
↓
125
↓
...

That's why Binary Search has

Time:  O(log n)
Space: O(1)

But there is one very important condition.

The data must be sorted.

Without sorted data, we cannot safely throw away half of the search range.

👀 Let's View View It

Binary Search is one of the algorithms that made me want a visualization tool in the first place.

The code itself is short

left = mid + 1;

right = mid - 1;

Easy.

But when learning it, I sometimes found myself thinking:

Wait... which part are we searching now? 😿

{% embed https://dsa-view-view.vercel.app/#s=j.eyJlIjoiYmluYXJ5LXNlYXJjaCIsImwiOiJ0eXBlc2NyaXB0IiwibSI6InZlcmlmaWNhdGlvbiIsInYiOjF9 %}

When we visualize left, mid, and right, the idea becomes much easier to follow.

We are not randomly changing three numbers.

We are continuously shrinking the search area.

███████████████

       ↓

        ███████

       ↓

          ███

       ↓

           █

That's Binary Search!

Cut the unnecessary half.

Then cut it again. And again. And again.

Until we find the answer. ✂️😸

Bubble Sort

Finally, let's sort something!

Consider this array.

[5, 1, 4, 2, 8];

We want.

[1, 2, 4, 5, 8];

Bubble Sort repeatedly compares two neighboring values.

If they are in the wrong order, it swaps them.

Let's look at the beginning.

[5, 1, 4, 2, 8]
 ↑  ↑

Compare

5 > 1

So swap them.

[1, 5, 4, 2, 8]

[1, 5, 4, 2, 8]
    ↑  ↑

Again

5 > 4

Swap!

[1, 4, 5, 2, 8]

And continue.

[1, 4, 5, 2, 8]
       ↑  ↑

5 > 2

Swap!

[1, 4, 2, 5, 8]

Eventually, larger values move toward the end of the array.

They kind of...

bubble up.

That's why it is called Bubble Sort.

Here is a simple implementation:

function bubbleSort(nums: number[]): number[] {
  for (let i = 0; i < nums.length - 1; i++) {
    for (let j = 0; j < nums.length - i - 1; j++) {
      if (nums[j] > nums[j + 1]) {
        [nums[j], nums[j + 1]] = [nums[j + 1], nums[j]];
      }
    }
  }

  return nums;
}

We repeatedly compare

nums[j];

And

nums[j + 1];

and swap them when necessary.

After one full pass, the largest remaining value reaches its correct position near the end.

So on the next pass, we don't need to check that position again.

That's why the inner loop contains.

nums.length - i - 1;

Complexity

Bubble Sort isn't very fast for large arrays.

Its time complexity is

Time:  O(n²)
Space: O(1)

So I probably won't suddenly replace production sorting with Bubble Sort tomorrow. 😸

But as a learning example, I really like it.

Why?

Because you can see the algorithm working.

👀 Let's View View It

This is probably the most visually satisfying one of the three.

{% embed https://dsa-view-view.vercel.app/#s=j.eyJlIjoiYnViYmxlLXNvcnQiLCJsIjoidHlwZXNjcmlwdCIsIm0iOiJ2ZXJpZmljYXRpb24iLCJ2IjoxfQ %}

Instead of only reading

[nums[j], nums[j + 1]] = [nums[j + 1], nums[j]];

we can follow the values moving through the array.

[5, 1, 4, 2, 8]

 ↓ swap

[1, 5, 4, 2, 8]

    ↓ swap

[1, 4, 5, 2, 8]

       ↓ swap

[1, 4, 2, 5, 8]

Then another pass begins.

The code contains nested loops, indexes, comparisons, and swaps.

But visually, the basic rule is extremely simple:

Compare neighbors. If the left one is bigger, swap them.

Repeat. Repeat. Repeat.

Sorted! 🎉

🧠 What Did We Actually Learn?

These three problems look quite different.

But each one introduces a useful way of thinking.

Two Sum

Remember information from previous steps.

Have I already seen what I need?

Binary Search

Use what we already know to remove impossible candidates.

Can I safely discard half of the search space?

Bubble Sort

Break a larger problem into many small comparisons.

Are these two values in the correct order?

This is one of the things I find interesting about learning DSA.

At first, the implementation can look like a collection of indexes, loops, conditions, and mysterious variables.

But behind the code, there is usually a much simpler idea.

And sometimes I don't fully understand that idea just by staring at the code.

I want to view it. 👀👀

🎯 Conclusion

In this article, we looked at three classic algorithms:

Two Sum with a Map
Binary Search
Bubble Sort

And more importantly, we looked at how the data changes while they run.

I think this is where visualization can be especially useful.

Reading the final implementation tells us what the code is.
Stepping through it helps us understand why it works.

That's exactly why I built DSA View View.

https://dsa-view-view.vercel.app

You can write or load a TypeScript implementation, run it with your own inputs, and move backward and forward through the runtime.

If you are learning DSA too, try taking a problem you already solved and viewing it step by step.

You may notice something you didn't notice when only reading the code. 👀

And if there is a DSA problem you want me to cover next, please let me know in the comments!

I still have many algorithms to learn myself. 😸

Let's train our DSA muscles together! 💪

If you like DSA View View, please give it a star ⭐

https://github.com/nyaomaru/dsa-view-view

And my DSA View View has launched at TinyLaunch! 🚀 Please take a loot 👇

https://www.tinylaunch.com/launch/17804-dsa-view-view

See you in the next article!

768. Max Chunks To Make Sorted II

Mon, 10 Aug 2026 17:51:40 +0000

Problem
You are given an integer array arr.

We split arr into some number of chunks (i.e., partitions), and individually sort each chunk. After concatenating them, the result should equal the sorted array.

Return the largest number of chunks we can make to sort the array.

Example 1:

Input: arr = [5,4,3,2,1]
Output: 1
Explanation:
Splitting into two or more chunks will not return the required result.
For example, splitting into [5, 4], [3, 2, 1] will result in [4, 5, 1, 2, 3], which isn't sorted.
Example 2:

Input: arr = [2,1,3,4,4]
Output: 4
Explanation:
We can split into two chunks, such as [2, 1], [3, 4, 4].
However, splitting into [2, 1], [3], [4], [4] is the highest number of chunks possible.

Constraints:

1 <= arr.length <= 2000
0 <= arr[i] <= 108

Discussion

This can be solved by traversing the array twice. The first time we put the elements in a min-heap/priority queue. This ensures that we have a list of the elements sorted in ascending order. Then we create 3 integer variables. One stores the sum of the sorted elements in the heap and is named sum. The second stores the total of the elements traversed in the array and is named total. The third stores the maximum number of chunks and is named answer.

We then traverse the array for the second time. We pull the topmost element from the heap and add it to sum. We add the element at the current index in the array and add to total. If the values are equal, we increment answer. Once we have traversed the array, we return the value of answer.

Solution

Java

class Solution {
    public int maxChunksToSorted(int[] arr) {
     PriorityQueue<Integer> pq=new PriorityQueue<>();
     int total=0;
     int sum=0;
     int answer=0;
     for(int i=0;i<arr.length;i++)pq.offer(arr[i]);
     for(int i=0;i<arr.length;i++){
      sum+=pq.poll();
      total+=arr[i];
      if(sum==total)answer++;  
     }
     return answer;
    }
}

Leetcode #324. Wiggle Sort II

Tue, 04 Aug 2026 19:55:27 +0000

Greedy algorithms are usually given in leetcode style technical interviews.They involve taking the maximum or minimum.Below is a an example of using the greedy approach to solve a problem.

Problem

Given an integer array nums, reorder it such that nums[0] < nums[1] > nums[2] < nums[3]....

You may assume the input array always has a valid answer.

Example 1:

Input: nums = [1,5,1,1,6,4]
Output: [1,6,1,5,1,4]
Explanation: [1,4,1,5,1,6] is also accepted.
Example 2:

Input: nums = [1,3,2,2,3,1]
Output: [2,3,1,3,1,2]

Constraints:

.1 <= nums.length <= 5 * 104
.0 <= nums[i] <= 5000
.It is guaranteed that there will be an answer for the given input nums.

Discussion

This algorithm can be solved using the greedy approach.We copy the contents of the original array into a new one and sort it.We create two pointers. One is placed at the end of the new array,the other in the middle of it.We iterate through the original from the start.If the index is even,we take the value from the second pointer.Otherwise,we take the value from the first one.This ensures that the biggest values are always placed at the odd indexes.

Solution

Java

class Solution {
    public void wiggleSort(int[] nums) {
     int [] nums1= new int [nums.length];
     for(int i=0;i<nums.length;i++)nums1[i]=nums[i];
     Arrays.sort(nums1);
     int nums1Index=nums.length-1;
     int nums1Index1=(nums.length-1)/2;      
     for(int i=0;i<nums.length;i++){
      if(i%2==0)nums[i]=nums1[nums1Index1--];
      else nums[i]=nums1[nums1Index--];  
     }
     return;
    }
}

public class Solution {
    public void WiggleSort(int[] nums) {
     int [] nums1= new int [nums.Length];
     for(int i=0;i<nums.Length;i++)nums1[i]=nums[i];
     Array.Sort(nums1);
     int nums1Index=nums.Length-1;
     int nums1Index1=(nums.Length-1)/2;      
     for(int i=0;i<nums.Length;i++){
      if(i%2==0)nums[i]=nums1[nums1Index1--];
      else nums[i]=nums1[nums1Index--];  
     }
     return;   
    }
}

C++

class Solution {
public:
    void wiggleSort(vector<int>& nums) {
     vector<int> nums1;
     for(int i=0;i<nums.size();i++)nums1.push_back(nums[i]);
     std::sort(nums1.begin(),nums1.end());
     int nums1Index=nums.size()-1;
     int nums1Index1=(nums.size()-1)/2;      
     for(int i=0;i<nums.size();i++){
      if(i%2==0)nums[i]=nums1[nums1Index1--];
      else nums[i]=nums1[nums1Index--];  
     }
     return;   
    }
};

Leetcode # 107. Binary Tree Level Order Traversal II

Tue, 04 Aug 2026 19:48:53 +0000

Problem

Given the root of a binary tree, return the bottom-up level order traversal of its nodes' values. (i.e., from left to right, level by level from leaf to root).

Example 1:

Input: root = [3,9,20,null,null,15,7]
Output: [[15,7],[9,20],[3]]
Example 2:

Input: root = [1]
Output: [[1]]
Example 3:

Input: root = []
Output: []

Constraints:

.The number of nodes in the tree is in the range [0, 2000].
.-1000 <= Node.val <= 1000

Discussion

Using a recursive function that returns a hashmap, a hashmap of the entire tree from top to bottom was obtained and a list was built. This list was reversed and returned.

Solution

Java

class Solution {
     public HashMap<Integer,List<Integer>> getRestOfTree(int level,TreeNode t){
     int value= t.val;
     List<Integer> root= new ArrayList<>();
     root.add(value);
     HashMap<Integer,List<Integer>> tree= new HashMap<>();
     tree.put(level,root);
     if(t.left ==null && t.right== null){
       return tree;
     }else{
      int nextlevel =level+1;
      if(t.left==null){
         HashMap<Integer,List<Integer>> rightSubtree= getRestOfTree(nextlevel,t.right);
         tree.putAll(rightSubtree);
         return tree;
      }else if(t.right==null){
          HashMap<Integer,List<Integer>> leftSubtree= getRestOfTree(nextlevel,t.left);
         tree.putAll(leftSubtree);
         return tree;
      }else{
         HashMap<Integer,List<Integer>> leftSubtree= getRestOfTree(nextlevel, t.left);
         HashMap<Integer,List<Integer>> rightSubtree= getRestOfTree(nextlevel, t.right);
         HashMap<Integer,List<Integer>> restSubtree = new HashMap<>();
         for(Integer key:leftSubtree.keySet()){
           if(rightSubtree.containsKey(key)){
             List<Integer> rightSubtreeList = rightSubtree.get(key);
             List<Integer> leftSubtreeList= leftSubtree.get(key);
             leftSubtreeList.addAll(rightSubtreeList);
             leftSubtree.replace(key,leftSubtreeList);
           }
         }
         for(Integer key:rightSubtree.keySet()){
            if(!leftSubtree.containsKey(key)){
               List<Integer> rightSubtreeList= rightSubtree.get(key);
               restSubtree.put(key,rightSubtreeList);
            }
         }
         tree.putAll(leftSubtree);
         tree.putAll(restSubtree);
         return tree;
      }
      }
   }
    public List<List<Integer>> levelOrderBottom(TreeNode root) {
        if(root==null)return new ArrayList<>();
        HashMap<Integer,List<Integer>> tree = getRestOfTree(1,root);
        List<List<Integer>> values= new ArrayList<>();
        for(Integer key: tree.keySet()){
         List<Integer> nodes= tree.get(key);
         values.add(nodes);
        }
        Collections.reverse(values);
        return values;
    }
}

Mastering the Two Pointers Technique in Python (With Easy Examples)

Tue, 04 Aug 2026 17:55:59 +0000

Mastering the Two Pointers Technique in Python (With Easy Examples)

Tags: Python • Programming • DSA • Algorithms

Author: Annet A

When I first started solving coding problems, I noticed that many array and string questions looked different but could actually be solved using the same approach: Two Pointers.

Instead of using nested loops and checking every possible pair of elements, the two pointers technique allows us to solve many problems efficiently in O(n) time.

In this blog, I'll explain what the Two Pointers technique is, when to use it, and some common patterns with examples.

What is the Two Pointers Technique?

The Two Pointers technique uses two indices (pointers) that move through a data structure such as an array or string.

Instead of processing one element at a time, we use two positions that move based on certain conditions until we reach the desired result.

This often reduces the time complexity from O(n²) to O(n).

When Should You Use Two Pointers?

The technique is useful when working with:

✅ Sorted arrays
✅ Strings
✅ Palindromes
✅ Removing duplicates
✅ Pair sum problems
✅ Reversing arrays
✅ Sliding window variations

Whenever you see words like:

Pair
Sorted
Remove duplicates
Reverse
Palindrome

think about whether the Two Pointers approach can simplify the solution.

Types of Two Pointer Patterns

There are several common patterns.

1. Opposite Direction Pointers

One pointer starts from the beginning and the other starts from the end.

Left                          Right
 ↓                              ↓

[1, 2, 3, 4, 5]

The pointers move toward each other.

Common Problems

Valid Palindrome
Two Sum II
Reverse String
Container With Most Water

Example

s = list("hello")

left = 0
right = len(s) - 1

while left < right:
    s[left], s[right] = s[right], s[left]
    left += 1
    right -= 1

print("".join(s))

Output

olleh

Time Complexity: O(n)

Space Complexity: O(1)

2. Same Direction Pointers (Fast and Slow)

Both pointers move from left to right.

The fast pointer explores every element while the slow pointer keeps track of the correct position.

Slow   Fast
 ↓      ↓

[1, 1, 2, 2, 3]

Common Problems

Remove Duplicates from Sorted Array
Move Zeroes
Remove Element

Example

nums = [1, 1, 2, 2, 3]

left = 0

for right in range(1, len(nums)):
    if nums[left] != nums[right]:
        left += 1
        nums[left] = nums[right]

print(nums[:left + 1])

Output

[1, 2, 3]

Time Complexity: O(n)

Space Complexity: O(1)

3. Slow and Fast Pointer

This is another variation where one pointer moves slower than the other.

Usually,

slow += 1
fast += 2

Common Problems

Detect Cycle in Linked List
Find Middle of Linked List
Happy Number

Note: This pattern is primarily used with Linked Lists rather than arrays.

Example: Two Sum II

Given a sorted array, find two numbers whose sum equals the target.

numbers = [2, 7, 11, 15]
target = 9

left = 0
right = len(numbers) - 1

while left < right:
    current = numbers[left] + numbers[right]

    if current == target:
        print(left, right)
        break
    elif current < target:
        left += 1
    else:
        right -= 1

Output

0 1

Notice how we never use nested loops.

Advantages

✅ Easy to understand
✅ Reduces time complexity
✅ Often converts O(n²) solutions into O(n)
✅ Uses constant extra space

Limitations

Works best with sorted data.
Doesn't apply to every array problem.
Choosing pointer movement correctly is important.

Tips to Identify Two Pointer Problems

Ask yourself these questions:

Is the array sorted?
Am I searching for a pair?
Can I avoid nested loops?
Can I process elements from both ends?
Can one pointer track the answer while another explores?

If the answer is Yes, the Two Pointers technique is worth considering.

Final Thoughts

The Two Pointers technique is one of the most important problem-solving patterns in Data Structures and Algorithms. Once you understand when and how to move the pointers, many coding interview problems become much easier.

I recently practiced this technique by solving problems like Remove Duplicates from Sorted Array, Merge Sorted Array, Valid Palindrome, and Two Sum II. Each problem helped me recognize different pointer movement patterns and improved my confidence in solving array and string problems efficiently.

Mastering this technique is a great step before learning more advanced patterns like Sliding Window, which builds upon similar ideas while handling subarrays and substrings.

⭐ If you found this article helpful, consider sharing it with fellow developers.

Happy Coding! 🚀

— Annet A

How I Made JavaScript Execution Visual and Rewindable (DSA View View 👀👀)

Wed, 29 Jul 2026 11:39:13 +0000

Hoi hoi!

I'm @nyaomaru, a frontend engineer who was recently knocked off my feet by how good the zeetong (sole) from a Dutch fish shop was. 🐟😸

In the previous article, I explained how DSA View View takes the TypeScript written by a user, analyzes the function or class signature, and generates a Verification form.

https://dev.to/nyaomaru/how-i-built-the-editor-and-compile-pipeline-for-a-typescript-dsa-visualizer-dsa-view-view--530f

This time, we are entering the heart of DSA View View: the Runtime and Visualization layers.

If you call an ordinary JavaScript function, the direct result you get back is usually the final return value.

But when I am studying DSA, that is not the part I really want to see.

I want to know:

What happened in the middle of the loop?
When did the pointer move?
At which exact moment did the variable change?
How deep did the recursion go?

In other words, I want to see the journey to the answer, not only the answer itself.

JavaScript, unfortunately, does not provide an API that accepts:

"Excuse me, could you move the current line one step backward?"

So how does DSA View View rewind execution?

Here is the answer up front. 😸

Before execution, DSA View View rewrites the code into a version that can record its intermediate state, then runs it until it completes or reaches a configured limit.

The UI then plays those recorded states forward and backward like security-camera footage.

In this article, we will look at that record-and-replay system through:

AST transformation with Babel
Injecting recordStep calls
Preserving the original meaning of the code
ExecutionStep and snapshot patches
Rewinding and jumping to variable changes
Running code inside a Web Worker
Detecting the appropriate Visualization
Tests that protect the AST transformation

The source code is available here 👇

embed https://github.com/nyaomaru/dsa-view-view

All right, let’s open the Runtime and see what Mr. View has been watching. 👀👀

📝 The Big Picture: Turning Execution into an Array of Steps

The Runtime pipeline looks roughly like this.

User TypeScript
      ↓
Prepare common DSA classes
      ↓
Parse the code into an AST with Babel Parser
      ↓
Visitors inject recordStep(...)
      ↓
Transform TypeScript into JavaScript with Babel
      ↓
Execute it with new Function inside a Web Worker
      ↓
Generate ExecutionStep[]
      ↓
React moves currentStep forward and backward
      ↓
Display the Visualization that matches the trace

The most important design decision here is that the user’s code is not connected directly to a React component.

Instead, ExecutionStep[] acts as a shared recording format.

That lets arrays, pointers, recursion, trees, heaps, and other structures all live on the same timeline.

Let’s walk through how that works.

🔭 Runtime: Planting Observation Points in the Code

This is the heart of DSA View View. 💖

The Runtime needs intermediate states, so it does not execute the user’s code exactly as written.

First, Babel transforms the AST and injects calls to recordStep.

Injecting `recordStep` into the AST

Suppose the user writes.

let left = 0;

while (left < right) {
  left++;
}

DSA View View parses it into an AST and transforms it into something roughly like this.

let left = 0;
recordStep("variable-declaration", 1, "let left = 0", { left });

while (left < right) {
  recordStep("loop-iteration", 3, "while (left < right)", { left, right });

  left++;
  recordStep("assignment", 4, "left++", { left, right });
}

The second argument to recordStep is the original source line number, not the execution-step number.
Because line 2 is empty, the recorded lines are 1, 3, and 4.

In the real implementation, dedicated visitors handle AST nodes such as:

FunctionDeclaration
FunctionExpression
ArrowFunctionExpression
ClassMethod
VariableDeclaration
AssignmentExpression
UpdateExpression
CallExpression nodes that mutate arrays
for / while / for...of / for...in
ReturnStatement

A step can therefore be recorded when:

A function is entered
A variable is declared
A loop completes an iteration
A value is assigned
An array is mutated
A function returns

Current limitation
callback bodies inside methods such as sort, reduce, map, filter, and forEach are intentionally excluded from instrumentation for now.

The goal is not to trace every corner of JavaScript immediately. I am starting with patterns that are useful for DSA traces and can be instrumented without breaking the original behavior.

Injecting the Code Is Easier Than Not Breaking It

The hardest part of the AST transformation was not calling recordStep.

The hard part was making sure that,

after adding the recording logic, every original expression is still evaluated the same number of times and still returns the same value.

For example, if a return expression were evaluated once for recording and once for the actual return, its side effects would run twice.

return someFunction();

So the transformed code first stores the value in a temporary variable.

const algorithmVisualizerReturnValue = someFunction();

recordStep("return", line, description, {
  "return value": algorithmVisualizerReturnValue,
  "return location": returnLocation,
});

return algorithmVisualizerReturnValue;

Assignment expressions are another fun little trap.

Consider this.

const result = (arr[i++] = 7);

The transformed code must preserve all three facts:

i++ runs exactly once
The pre-increment value of i is used as the array index
The assignment expression itself evaluates to 7

DSA View View wraps the assignment in a synthetic arrow function, stores the result in a temporary variable, records the step, and returns the same value.

Using an arrow function also avoids accidentally stealing the surrounding this or arguments.

AST transformation cannot be "close enough".

If adding more visible steps changes the answer, the visualizer has somehow become the least trustworthy character in the story.

Not ideal.

🖍️ `ExecutionStep`: Making Execution Replayable

The Runtime records each observed state as an ExecutionStep.

A shortened version of the real type looks like this.

type ExecutionStep = {
  stepNumber: number;
  type: ExecutionStepType;
  line: number;
  column?: number;
  description: string;
  variables: Record<string, unknown>;
  timestamp: number;
  callStack?: string[];
  scope?: string;
  metadata?: {
    loopIteration?: number;
    conditionResult?: boolean;
    functionName?: string;
    heapTrace?: HeapTraceSnapshot;
  };
};

The Runtime currently generates steps including:

function-call
function-entry
variable-declaration
assignment
array-mutation
loop-iteration
return

line and description are used in the timeline.

variables provides the data needed to reconstruct the UI at that moment.

Recursive traces also use callStack, while prepared heap implementations can attach metadata.heapTrace.

Saving References Would Rewrite the Past

Suppose an array reference were stored directly inside a step.

const stack = [0, 1];
recordStep(/* save stack */);

stack.pop();

If the recorded step keeps the same reference, the earlier state will also appear as [0] after pop() runs.

That is not a historical record.

That is the past quietly editing itself.

So values passed to recordStep are deep-cloned at that moment.

The Runtime normally uses structuredClone. When it encounters values that need different handling, it falls back to a cloning implementation that supports cycles, Map, Set, Date, RegExp, and other cases.

The "Delta Snapshot" Is Really More Like a Patch

The implementation contains a name called variableDeltas, but this deserves a more precise explanation.

The current Runtime does not compare every value with the previous state and store only the keys that truly changed.

Instead:

The first step stores the initial state, including the inputs
Later steps deep-clone the visible variables passed to that recordStep
When a full snapshot is needed, the patches are merged in order
Reconstructed snapshots are cached

So, strictly speaking, these are closer to per-step patches than minimal deltas.

Step 0 patch: { left: 0, right: 5 }
Step 1 patch: { left: 1 }
Step 2 patch: { right: 4 }

Reconstructing them produces.

Step 0 snapshot: { left: 0, right: 5 }
Step 1 snapshot: { left: 1, right: 5 }
Step 2 snapshot: { left: 1, right: 4 }

The variables property of each ExecutionStep is a getter.

It starts from a previously cached snapshot and merges only the patches needed to reach the requested step.

There is one more implementation detail worth mentioning.

The Runtime sends state from the Worker to the UI with postMessage. During that structured clone, reading the getter also materializes the snapshot.

So the data does not remain a tiny delta forever and magically arrive on the main thread in that form.

The design mainly reduces eager reconstruction and cloning while the execution is being recorded. 📽️

Why Can the Timeline Move Backward?

DSA View View is not reversing JavaScript while it runs.

Inside the Web Worker, it first rewrites the code into an instrumented version and records the execution.

During playback, the main value that changes is currentStep.

type ExecutionState = {
  currentStep: number;
  totalSteps: number;
  steps: ExecutionStep[];
  isComplete: boolean;
  returnValue?: unknown;
  error?: string;
};

Moving forward displays the snapshot for currentStep + 1.

Moving backward displays the snapshot for currentStep - 1.

So rewinding means,

selecting an earlier recorded frame, not undoing the execution itself

Once recording has finished, users can navigate without rerunning their code:

Pause
Move one step forward or backward
Jump to any step in the timeline
Move to the first or final step

Users can also select a variable and jump directly to the previous step where its value changed.

That is especially useful for pointers such as i, left, and right.

No more clicking the Back button 47 times while whispering, "Where did you go wrong?" 😸

There Is a Generator, but It Does Not Suspend the User’s Code Line by Line

The Runtime API contains a Generator<ExecutionStep, ...>.

That might make it look as if the user’s code itself is being paused line by line with yield.

It is not.

After yielding the first function-call step, the instrumented code runs once and accumulates steps inside the execution context.

The generator then yields the already-recorded steps in order.

In the path used by the UI, the Worker consumes the generator completely and returns the finished ExecutionState.

Separating execution from playback is what makes the rewind behavior relatively simple.

⚙️ Web Worker: Do Not Take the UI Down with You

User code runs inside a dedicated Web Worker instead of the main thread.

new Worker(new URL("./execution-worker.ts", import.meta.url), {
  type: "module",
  name: "algorithm-execution",
});

An infinite loop or expensive computation on the main thread would freeze the entire page.

By moving execution into a Worker:

The React UI stays on the main thread
Starting a new run or leaving the page can terminate the Worker through an AbortController

The Runtime also has limits:

Execution timeout: 10 seconds
Maximum recorded steps: 3,000

When a limit is reached, the Worker can be terminated or execution can stop early with a warning.

A Worker Is Not a Security Sandbox

A Web Worker does not have access to the page DOM, localStorage, or sessionStorage.

DSA View View also does not execute user code on a server.

However, a Web Worker is not a security boundary that makes untrusted code safe.

The user code runs through new Function in the Worker global scope.

Web APIs available inside Workers, including fetch, are not automatically disabled.

The purpose of this architecture is to:

Isolate heavy execution from the main thread
Terminate an execution unit on timeout or cancellation

It is an execution boundary for responsiveness and control, not a magical prison for JavaScript.

JavaScript has watched enough escape-room videos to know better.

👀 Visualization: Variables Alone Are Not Enough

The Runtime returns an ExecutionState and snapshots for each step.

The next problem is deciding which View should display that trace.

DSA View View does not ask AI,

"Hey, does this look like Binary Search?"

on every run.

Instead, visualization candidates are detected through logic based on:

Variable names
Variable types and data structures
Whether arrays or matrices actually changed
Pointers such as left, right, and mid
The call stack
Function-entry and return history
Heap metadata
Changes across multiple steps

For example, displaying a Sort Graph whenever a number[] exists would classify algorithms that only read an input array as sorting algorithms.

So the detection logic checks whether the numeric array actually changes between steps.

It also looks for context such as sort, swap, partition, and pivot in descriptions or the call stack.

Some representative mappings are 👇

Runtime state	Displayed View
A changing numeric array	Sort Graph
An array used as a stack	Stack View
Search using `left` / `right` / `mid`	Index View
Sliding Window pointers	Sliding Window View
A two-dimensional array	Matrix View
DP arrays or rolling state	DP View
`TreeNode`	Tree Graph
`ListNode`	List Graph
Recursive function entry and return	Recursion Tree
Logic using `Map`	Map View
Logic using both `MinHeap` and `MaxHeap`	Heap View
Word Ladder-style BFS	Word Ladder View
Container / rain-water / histogram pointers	Area View
Calculator character positions and sign stack	Expression View

When multiple candidate Views are found, DSA View View assigns priorities and selects a primary Visualization.

For example, if heap state is available, Heap View takes priority over an ordinary array View.

Visualization Is Built from `ExecutionState`

Each Visualizer knows nothing about the user’s source code.

It extracts what it needs from the current ExecutionState and converts that data into View-specific state.

<BinarySearchVisualizer
  data={data}
  indexState={{
    left,
    right,
    mid,
  }}
/>

When currentStep changes, the same Visualizer receives a new state.

CSS transitions and Framer Motion animate the difference, making pointers and nodes appear to move.

This creates a clean separation of responsibilities:

Runtime creates a correct trace while preserving the original behavior
Detection decides which View best represents the trace
Visualization focuses on how to display that state

Adding a new visualization generally follows this path:

Detect the target execution state
Convert it into View-specific state
Render it with a React component
Add it to the primary-visualization selection
Add the smallest reproducible code sample as a test

🧪 Tests: Reducing the Number of "It Happened to Work" Cases

Users can write code freely, which means they can also write it in ways I never expected.

AST transformations are especially dangerous because fixing one syntax pattern can quietly break another.

So when a real issue appears, I keep the smallest version of that code as a regression test.

Examples include:

Arguments and local variables for each recursive call
Postfix i++
XOR assignment
Nested array mutations
Class constructors and super()
TreeNode / ListNode inputs
Heap operations
Binary Search and Sliding Window pointers
Word Ladder BFS state
Worker timeouts and step limits

Trusting human memory to say,

"Surely this syntax still works."

is not a particularly strong testing strategy.

Memory is surprisingly optimistic.

And it would be a little embarrassing to build a tool for avoiding confusion in DSA, only to get lost inside the tool’s own behavior.

🎯 Summary

DSA View View is not simply turning an array into a bar chart.

At a high level, it works like this:

Write TypeScript in Monaco
Analyze the source code and signature with Babel
Inject recordStep into the AST
Execute the code inside a Web Worker
Record variable snapshots and the call stack
Replay the steps with React
Display a View matching the data structure

The most important step was converting the user’s code into an array of ExecutionSteps.

Once execution becomes a sequence of steps, the same ExecutionState can power:

Pause
Forward and backward navigation
Timeline jumps
Navigation to the previous variable change
Reconstruction of recursion trees
Data-structure visualizations

The key idea is "Do not try to reverse JavaScript itself. First, transform execution into a recordable domain model".

Then,

"Runtime focuses on producing a correct trace, while Visualization focuses on presenting that trace."

Keeping Editor, Runtime, and Visualization independent from one another has been essential to making the tool extensible. Stable models such as ExecutionStep and ExecutionState connect these layers without coupling them directly.

There are still unsupported algorithms and syntax patterns, so I would love to hear from you if:

An implementation does not run
You want another data structure visualized
You think a trace would be clearer in a different View

Issues and PRs are always welcome 👇

https://github.com/nyaomaru/dsa-view-view

Now let’s run our code and watch what it is doing inside together. 👀👀

And if you enjoy the project, I would be very happy if you left a GitHub ⭐!

How I Built the Editor and Compile Pipeline for a TypeScript DSA Visualizer (DSA View View 👀👀)

Wed, 22 Jul 2026 14:19:08 +0000

Hoi hoi!

I'm @nyaomaru, a frontend engineer. Thanks to my daily Duolingo streak, Dutch is finally starting to sound slightly less like one extremely long word. Progress! 🦉

In my previous article, I introduced DSA View View, a tool for visualizing data structures and algorithm execution.

{% embed https://dev.to/nyaomaru/i-built-a-tool-to-visualize-dsa-lets-learn-together-dsa-view-view--djo %}

That article covers:

Why I decided to study DSA again
What DSA View View is
How to use it
How I plan to study with it

So if this is your first time meeting Mr. View, the previous article is a good place to start.

This time, we're opening the hood.

This is the first half of the implementation story, covering everything from the moment a user writes TypeScript to the moment DSA View View generates an input form for that implementation.

We'll mainly look at:

The overall architecture and FSD
Runtime type guards with is-kit
The Monaco Editor
Static TypeScript analysis
Compilation with Babel
Extracting function signatures from the AST
Generating the Verification form

You can find the source code here:

{% embed https://github.com/nyaomaru/dsa-view-view %}

All right, let's take a look together!

📝 Designing DSA View View

DSA View View has four main responsibilities:

Editor
Compile
Runtime
Visualize

There is also a Verification step in the UI, where the user provides input values before the code is executed.

The overall flow looks like below.

Each part is already a little complicated on its own, and they interact with one another quite deeply.

I could see during the design phase that a flat project structure would eventually leave future-me wandering around the repository like a lost hiker. 🌲

So I decided to use FSD (Feature-Sliced Design).

I previously wrote about how I learned FSD here.

https://dev.to/nyaomaru/lets-learn-feature-sliced-design-fsd-15bb

A simplified version of the project structure looks like this.

src/
├── app/                # App startup and global styles
├── pages/
│   └── main/           # Main page that composes the features
├── widgets/
│   ├── editor-panel/   # UI around the editor
│   ├── control-panel/  # Compile / Verification / Runtime controls
│   └── header/
├── features/
│   ├── code-editing/   # Monaco Editor, formatting, and parsing
│   ├── compilation/    # Compile behavior
│   ├── code-execution/ # AST transforms, execution, step recording, input forms
│   ├── visualization/  # Visualization detection and views
│   └── shareable-url/
├── entities/
│   ├── code/           # Code, types, and compile results
│   ├── execution/      # ExecutionState and ExecutionStep
│   ├── data-structure/ # TreeNode, ListNode, and friends
│   └── algorithm-example/
└── shared/
    ├── ui/             # Generic components such as Button, Card, and Dialog
    └── lib/            # Guards, cloning, serializers, and other utilities

For example, features/code-execution owns the behavior of executing code.

On the other hand, ExecutionState and ExecutionStep describe domain concepts, so they live in entities/execution.

Then pages/main combines the individual features and coordinates the overall flow:

After Compile succeeds, extract the signature and move to Verification
After receiving the inputs, start the Runtime
When the Runtime step changes, highlight the corresponding line in the Editor

Each slice is consumed through a public API such as index.ts, and dependencies are allowed to flow only from higher layers to lower layers.

I also verify those dependency directions and public API boundaries with architecture tests.

Drawing those boundaries helps prevent the classic.

"I changed the Runtime. Why is the Editor broken now?"

A mystery nobody ordered.

🛡️ `is-kit`: Protecting the App from `unknown` Hell

FSD can organize dependency directions, but it cannot automatically make values entering the application safe.

In DSA View View, mysterious unknown values come flying in from many directions:

AST nodes returned by Babel Parser
Messages sent between Web Workers
JSON restored from a shareable URL
Runtime snapshots recorded from user code
Arrays, trees, graphs, and heaps being inspected as visualization candidates

TypeScript is wonderfully reliable at compile time.

But at runtime, it does not interrogate a value and ask.

"Are you really an ExecutionState, or are you just wearing its name tag?"

That is where my type guard library, is-kit, comes in.

is-kit is a small, zero-dependency library for building and composing reusable TypeScript type guards.

import {
  and,
  arrayOf,
  define,
  hasKey,
  isArray,
  isNumber,
  isObject,
  isString,
  not,
  oneOfValues,
  or,
  predicateToRefine,
  type Guard,
} from "is-kit";

const isNumericString = and(
  isString,
  predicateToRefine<string>((value) => {
    return value.trim() !== "" && Number.isFinite(Number(value));
  }),
);

const isNonArrayObject = and(isObject, not(isArray));
const isNumericValue = or(isNumber, isNumericString);
const isNumericArray = arrayOf(isNumericValue);

Small guards can be combined like LEGO bricks to create more complicated runtime checks.

For example, the code that finds class methods in an AST defines a guard.

const isMethodNodeType = oneOfValues("ClassMethod", "MethodDefinition");

const hasType = hasKey("type");

const isMethodLikeNode: Guard<MethodLikeNode> = and(
  isObject,
  define<MethodLikeNode>(
    (value) => hasType(value) && isMethodNodeType(value.type),
  ),
);

After a value passes this guard, it is narrowed from a plain unknown to MethodLikeNode.

The guard can then be passed directly to filter.

const members = classNode.body.body.filter(isMethodLikeNode);

This is extremely convenient.

Without is-kit, checks like this would have multiplied across the repository:

typeof value === "object" &&
value !== null &&
"type" in value &&
Array.isArray(...)

Eventually, slightly different versions of the same guard would appear everywhere.

Six months later, I would be asking:

"What is the difference between this isObject and that isObject?"

And congratulations—we would have built a second maze inside the first maze.

At the time of writing, shared guards are used from around 69 files under src.

If Monaco and Babel are the stars on stage, is-kit is the very serious bouncer standing at every entrance to the AST, Worker, share URL, Runtime, and Visualization layers.

Mr. Unknown is not getting in.

I also use Zod in the Verification forms, but the responsibilities are different:

is-kit: Internal narrowing, filtering, and reusable runtime guards
Zod: Input form schemas, validation messages, and user-facing errors

Instead of making one library solve every problem, is-kit handles internal runtime safety while Zod handles user input validation.

I am very glad I built is-kit before building this application. Fighting all those unknown values with my bare hands would have made me the first thing that needed visualizing.

✏️ Editor

The Editor uses Monaco Editor.

Monaco is the browser-focused editor component also used by VS Code, giving the application syntax highlighting, completion, and TypeScript diagnostics.

The downside is that Monaco is not exactly tiny.

Loading everything immediately made the initial display heavier, so DSA View View first renders a lightweight textarea.

The same textarea is also used as the <Suspense> fallback, preventing the editor area from becoming empty while Monaco is loading.

<textarea
  aria-label="Code Editor"
  value={value}
  onChange={(event) => onChange(event.target.value)}
  onFocus={onActivate}
/>

Behind the scenes, DSA View View waits briefly and prepares Monaco with requestIdleCallback.

If the browser does not support requestIdleCallback, loading starts normally. If the user focuses the textarea before that, Monaco preparation begins immediately.

const CodeEditor = lazy(() =>
  prepareCodeEditorModule().then((module) => ({
    default: module.CodeEditor,
  })),
);

Once loading finishes, the lightweight editor is replaced by Monaco while preserving the same source code.

It looks like an editor, but secretly it is still a textarea.

A tiny editor body-double strategy.

Static `TypeScript` Analysis

Static analysis uses the TypeScript Worker included with Monaco.

The TypeScript Language Service runs in a separate Worker from the editor itself and returns type and syntax problems as markers.

Those markers are converted into the application's CompilationError model and used to control the Compile button and display errors.

type CompilationError = {
  line: number;
  column: number;
  message: string;
  severity: "error" | "warning";
};

The Compile button is disabled only when an error exists. Warnings alone do not prevent compilation.

One important detail is that Babel does not perform TypeScript type checking.

The responsibilities are:

Monaco's TypeScript Worker: Diagnose types and syntax
Babel: Transform TypeScript syntax into JavaScript

Keeping that distinction clear saved me from blaming Babel for crimes it did not commit.

Registering DSA Classes in the Editor

Many LeetCode problems provide classes such as TreeNode and ListNode automatically.

DSA View View also provides common classes so users do not have to declare them every time:

TreeNode
ListNode
GraphNode / _Node
TrieNode
PriorityQueue
MinHeap / MaxHeap
Deque
UnionFind / DSU
Counter

Monaco provides a mechanism called setExtraLibs, which lets the application add these type definitions to the Editor:

monaco.typescript.typescriptDefaults.setExtraLibs([
  {
    content,
    filePath: "ts:algorithm-visualizer-prepared-classes.ts",
  },
]);

However, setExtraLibs only supports type analysis inside the Editor. It does not magically create those classes at Runtime.

So the Compile and Runtime pipelines also prepend the same class definitions to the user's code as a prelude.

If the user declares a class, interface, or type with the same name, DSA View View skips injecting the prepared definition.

Imagine carefully writing your own ListNode, only for another ListNode to emerge from behind it.

That is not type safety. That is a summer horror movie.

Formatting

Formatting uses Prettier.

The Prettier core, TypeScript plugin, and Estree plugin are dynamically imported only when needed and registered as Monaco's Document Formatting Provider.

Users can therefore format their code with Command/Ctrl + S or Shift + Alt + F.

📌 From the Compile Button to Verification

So far, I have described "Compile" as if it were one large operation.

Internally, however, the FSD slice features/compilation does not own the whole flow.

When the user presses the Compile button, pages/main coordinates these operations:

features/compilation checks whether the TypeScript can be transformed into JavaScript
The parser in features/code-editing extracts the function or class signature
If everything succeeds, the UI moves to Verification
features/code-execution displays an input form matching that signature

To the user, this feels like one continuous Compile step.

Inside the application, each responsibility remains separate.

Transforming `TypeScript` with Babel

The application uses Babel to transform TypeScript.

const prepared = prepareTypeScriptCodeWithClasses(code);

const result = transform(prepared.code, {
  presets: ["typescript"],
  filename: "input.ts",
});

DSA View View runs entirely in the browser, so it is not invoking tsc on a Node.js server.

Instead, it uses @babel/standalone to transform TypeScript syntax into JavaScript in the browser.

Before transformation, the application prepends any prepared classes that the user has not declared themselves.

If the source contains imports for those prepared classes, they are removed because the browser execution environment cannot resolve those modules.

Again, an important reminder:

Babel's TypeScript preset primarily removes type information. It does not type-check the program.

Monaco handles type errors. Babel checks whether the syntax can be transformed.

The generated JavaScript from this stage is also not executed directly on the main thread.

For the Runtime, the original source is instrumented separately and then executed inside a Web Worker.

That is the fun part—and the topic of the next article.

Extracting Function Signatures from the AST

After Compile succeeds, DSA View View needs to build an input form.

Suppose the user writes this function:

function trap(height: number[]): number {
  // ...
}

The source code is parsed into an AST with Babel Parser, and DSA View View extracts information like this:

{
  name: "trap",
  parameters: [
    {
      name: "height",
      type: "number-array",
      optional: false,
    },
  ],
  returnType: "number",
}

The parser supports more than ordinary function declarations:

Function declarations
Arrow functions assigned to variables
Function expressions assigned to variables
LeetCode-style factory functions that return another function
Class declarations

For a class, the parser extracts the constructor and callable methods. private methods are currently excluded.

For class-design problems such as LRUCache and MedianFinder, it extracts the class name, constructor, method names, and arguments.

When the source contains multiple helper classes, DSA View View avoids prioritizing prepared classes as solution candidates and compares the number of callable methods to select the likely design class.

This selection is heuristic, so it cannot perfectly identify every possible class structure yet.

There are always more creative ways to write JavaScript than I expect. JavaScript considers this a feature.

Generating the Verification Form

For ordinary functions, the input form is built from the extracted signature using React Hook Form and Zod.

Supported input types include:

number
string
boolean
number[] / string[] / boolean[]
number[][] / string[][] / boolean[][]
TreeNode
ListNode
GraphNode / _Node

The input UI and validation behavior change depending on the type.

For example, a number[] accepts both:

1, 2, 3

and:

[1, 2, 3]

Both formats are converted into a real array that can be passed to the Runtime.

For TreeNode, the application constructs a tree from a level-order array.

When a problem has multiple TreeNode parameters, users can also select a specific node from the first root.

For ListNode, users can build a linked list from an array or node-based input and specify the cycle position.

For GraphNode, a cyclic graph structure is constructed from a LeetCode-style adjacency list.

Class-design problems use a different UI.

Instead of the normal parameter form powered by React Hook Form and Zod, DSA View View displays the same Operations and Arguments JSON format used by LeetCode.

For example, MedianFinder uses:

Operations: ["MedianFinder", "addNum", "addNum", "findMedian"]
Arguments:  [[], [1], [2], []]

This form validates class-design-specific requirements, including:

The number of operations matches the number of argument lists
The first operation matches the class name

So the Compile button starts a chain of separate responsibilities:

Babel verifies that transformation is possible
AST analysis extracts the signature
The Verification layer generates the appropriate input form
pages/main connects the entire flow from the Editor to Verification

🎯 Summary

In this article, we followed the path from writing TypeScript in DSA View View to generating the inputs needed for execution.

The broad flow is:

Render a lightweight textarea first
Prepare Monaco Editor in the background
Diagnose types and syntax with the TypeScript Worker
Use Babel to check whether the TypeScript can be transformed into JavaScript
Extract the function or class signature from the AST
Generate a Verification form based on the detected types

The important design decision was not forcing the Editor, diagnostics, syntax transformation, and input UI into one giant operation.

Instead:

is-kit safely narrows unknown values from the AST, Workers, JSON, and runtime snapshots
Monaco's TypeScript Worker diagnoses types and syntax
Babel transforms TypeScript syntax into JavaScript
AST analysis extracts the signature needed by the Verification UI
The Verification form validates inputs and converts them into Runtime values
pages/main connects the separate steps and advances the UI

Keeping those responsibilities separate made the flow much easier to understand and extend.

In the next article, we will finally enter the heart of DSA View View: the Runtime.

That is where Mr. View stops politely waiting beside the Editor and starts watching every move your variables make. 👀

There are still unsupported patterns and types, so Issues and PRs are always welcome!

And if you enjoy the project, I would be very happy if you left a GitHub ⭐!

https://github.com/nyaomaru/dsa-view-view

I Built a Tool to Visualize DSA. Let’s Learn Together! (DSA View View 👀👀)

Wed, 15 Jul 2026 13:00:13 +0000

Hoi hoi!

I’m @nyaomaru, a frontend engineer currently fighting the intense European heatwave by building DIY window screens here in the Netherlands. 🛠️

https://medium.com/data-science-collective/should-you-still-learn-to-code-in-2026-034685e17707

As this article also discusses, I believe that improving our fundamental engineering skills is still essential in the age of AI.

Imagine that AI makes an F1 car fully autonomous. 🏎️

Would you let someone without even a driver’s license enter a race as its driver?

Or imagine that AI completely automates maintenance during pit stops.

Would you put someone who knows absolutely nothing about cars, their parts, or their internal structure in charge of that AI?

AI is certainly reducing the amount of code we need to write by hand. Typing quickly and memorizing every small piece of syntax or every method are becoming less important.

But can we confidently release a product without understanding its fundamental concepts or implementation? If something goes wrong in production, can we take responsibility and fix it?

My answer was no.

Building things faster is obviously a good thing. But if we build without understanding, we may simply produce fragile software with no long-term sustainability at a faster rate.

The real value comes from building meaningful things quickly.

Then, how can we develop the fundamental skills we still need in the AI era?

I believe one useful approach is learning DSA: Data Structures and Algorithms. So I decided to start learning DSA again.

However, while solving problems on LeetCode, I repeatedly ran into the same problem.

I want to visualize the data flow and understand what is happening, but I still can’t clearly see it.

So I used the skills I have developed through frontend engineering and built a tool that visualizes the execution flow of DSA implementations! 🚀

https://github.com/nyaomaru/dsa-view-view

In this article, I’ll explain how DSA View View works and how we can use it to study DSA.

Let’s take a look together!

Disclaimer
I may sound confident so far, but I’m definitely not a DSA expert. I’m still learning, just like many of you.

In fact, I built this tool precisely because I was struggling. When I realized that I couldn’t immediately solve Binary Search, I started to panic a little. 😸

🖥️ What Is DSA View View?

DSA View View is a tool that executes functions and classes written in TypeScript and lets you inspect how variables and return values change on each line through a runtime timeline.

The easiest way to understand is to try it yourself!

Open the tool and click the Run Demo button.

You’ll quickly see how the workflow works:

Write your implementation
Compile it
Enter the input values
Run it

That’s really it.

Although I created it primarily for DSA problems, you can also use it to inspect and test smaller TypeScript implementations.

And, of course, it’s completely free!

🤔 What Can It Do?

With DSA View View, you can:

Write DSA implementations in TypeScript
Test implementations with different input values
Move forward and backward through runtime steps
Visualize supported data structures and algorithms
Review LeetCode solutions and confirm your understanding

You can also use it as a lightweight environment for executing functions or formatting code blocks for technical articles such as Dev.to 😸

Feel free to experiment with it and find your own use cases!

🧑🏫 How to Use It

The main workflow consists of three modes:

Editor
Verification
Runtime

Let’s look at each one.

Editor

First, write your implementation!

The Editor is designed to feel similar to a basic IDE.

TypeScript diagnostics are available by default, so the editor can detect some errors while you write.

You can also press Cmd/Ctrl + S to format your code with Prettier, so feel free to write first and clean it up afterward.

Common classes used in DSA problems, such as TreeNode and ListNode, are already available.

You don’t need to declare or import them every time.

You can also define your own classes or replace the provided definitions when necessary.

Once your implementation is ready, click Compile Code.

If compilation fails, the tool displays the relevant location and error message so that you can fix it.

There is also an Example menu containing several common implementations.

For example, if you want to quickly inspect a Heap Sort implementation and see how it behaves, you can load the example instead of writing everything manually.

Verification

In Verification mode, you define the input values that should be passed to your function or class.

Enter a test value for each argument.

For arrays, both of the following formats are supported:

[1, 2, 3]

1, 2, 3

Once your input values are ready, click Run.

Runtime

Finally, let’s inspect the runtime!

When you click Run in Verification mode, your implementation is executed.

Runtime mode then lets you play through the execution steps or move backward and forward manually.

When the tool recognizes supported logic, an additional visualization is displayed in a modal.

Not every possible implementation is supported yet, of course. If something you need is missing, I would be happy to receive an issue or pull request!

You can move backward and forward through the executed lines to inspect:

Which line is currently running
How variables change
Where values are returned
How the execution reaches its final result

You can return to the beginning, jump directly to the end, or move through the timeline one step at a time.

The main execution process runs entirely in the browser.

DSA View View also includes a sharing feature.

You can create a URL that preserves your implementation and share it with someone else.

Use the Share button at the top of the page to post it on social media or copy the link directly.

Share your implementations, compare different solutions, and let’s learn together!

Important: The shared URL contains your implementation. Do not paste private, confidential, or proprietary code into the tool before sharing it.

What Is That Thing in the Top-Right Corner? 👀👀

Meet Mr. View.

Mr. View watches over your implementation.

Nothing more.

Nothing less.

He is simply there to support you.

When you need to concentrate, press the TV button to hide him. Press it again to bring him back.

However, if Mr. View is enough to distract you, you may not be ready for an attack from ten simultaneous Slack notifications. 😸

✏️ How Should We Study DSA?

Now you know how to use DSA View View.

The next question is probably

Which problems should I solve?

LeetCode is an obvious place to start, and the study plan from Tech Interview Handbook also provides a useful collection of practice problems. 👇

https://www.techinterviewhandbook.org/coding-interview-study-plan/

Try solving these problems with DSA View View.

Once your implementation works, use the runtime timeline to inspect the data flow and understand exactly how the algorithm reaches its answer.

You can also use tools such as ChatGPT, Codex, Claude, Claude Code, Gemini, and Grok to explore your solution further.

Don’t limit yourself to asking

Is this implementation correct?

Try asking questions such as:

What would happen if I rewrote this DFS solution using BFS?
Could Dynamic Programming solve this problem?
Are there any other reasonable approaches?
What are the time and space complexities?
Why is this approach better than the alternatives?
Under which conditions would another approach be better?

AI becomes much more useful for learning when it helps us compare and understand different approaches instead of only generating a final answer. 👍

Why TypeScript Instead of Python? 🐍

The simple answer is that TypeScript is my favorite language.

I mainly work as a frontend engineer, so TypeScript is also the language in which I feel most comfortable experimenting and learning.

However, I designed the tool so that additional languages could be supported in the future.

If there is enough demand for another language, please leave a comment or open an issue!

🎯 Conclusion

AI is helping us write code faster and faster.

However, understanding what happens inside an implementation remains an important engineering skill.

In fact, I believe that this ability may become even more valuable as AI-generated code becomes increasingly common.

I built DSA View View because I wanted a tool that could help me strengthen those fundamental skills from the ground up.

To be honest, I still have a lot to learn about DSA.

That is exactly why I hope we can learn together.

Please leave a comment or open an issue if:

You want support for a particular problem or data structure
You have an idea for a new visualization
You find a bug
You want support for another programming language

Let’s train our DSA muscles together! 💪😸

If you like it, please give a star ⭐

https://github.com/nyaomaru/dsa-view-vie

And I also launched on ProductHunt! Come say hello and let me know what you think 😸 👇

https://www.producthunt.com/products/dsa-view-view

BFS vs DFS? The Question That Fixed My Graph Solutions

Fri, 22 May 2026 20:01:47 +0000

For a long time I treated BFS and DFS as interchangeable. Two ways to visit every node, pick whichever came to mind first. Then an interview handed me a grid that wanted the minimum number of steps, and a recursive DFS felt faster to type, so that's what went down. The path that came back was valid and far too long. No error. Just an answer that passed the small cases and fell apart on the one that mattered, with no obvious reason why.

What finally clicked:

The two traversals hold different invariants. They don't just visit in a different order.
The queue gives BFS its shortest path guarantee. The stack makes DFS commit to one branch.
"Minimum" in an unweighted graph turns out to be a reliable signal for BFS.
"Detect", "order", and "all paths" point to DFS.
Once edges carry weights, neither applies, and Dijkstra's algorithm takes over.

Where my approach was breaking

The mistake wasn't picking the slower traversal. It was reaching for whichever traversal got practiced most recently instead of reading what the problem actually asked for.

A grid that wants the fewest steps is asking for a distance guarantee, and DFS doesn't offer one. It happily commits to a branch and walks 30 cells deep before it would ever consider the 8 cell route, then stops the moment it touches the goal, satisfied with a path that happens to be valid. The wrong choice there has nothing to do with DFS being worse. It comes from never asking what kind of answer the problem needed.

The one question that changed it

Before writing any code now, the question is always the same: does this problem need a distance guarantee or a structural property? If the answer is distance, that's BFS. If it's structure, meaning cycles, ordering, or which nodes connect to which, that's DFS.

It sounds almost too simple, and that's the point. The decision was never about which algorithm you can implement faster. It's about which guarantee the problem is quietly demanding.

What that looked like on the same six node graph

The clearest way to feel the difference is to run both on one small graph and watch the order. Take six nodes with edges 0→1, 0→2, 1→3, 1→4, 2→4, 2→5, starting from node 0.

from collections import deque

graph = {0: [1, 2], 1: [3, 4], 2: [4, 5], 3: [], 4: [], 5: []}

def bfs(start):
    order, seen, q = [], {start}, deque([start])
    while q:
        node = q.popleft()
        order.append(node)
        for nxt in graph[node]:
            if nxt not in seen:
                seen.add(nxt)
                q.append(nxt)
    return order

def dfs(start):
    order, seen, stack = [], set(), [start]
    while stack:
        node = stack.pop()
        if node in seen:
            continue
        seen.add(node)
        order.append(node)
        for nxt in reversed(graph[node]):
            if nxt not in seen:
                stack.append(nxt)
    return order

print(bfs(0))  # [0, 1, 2, 3, 4, 5]
print(dfs(0))  # [0, 1, 3, 4, 2, 5]

BFS visits in exact distance order: everything one hop from the source (1, 2) before anything two hops away (3, 4, 5). DFS visits 3 before it ever gets back to 2, even though 3 sits further from the source. It cares about depth, not distance. Swapping the queue for a stack is the only structural change between the two functions, and it produces the entire difference in behaviour.

Why this works (the part that took digging)

A queue is first in, first out, so the nodes you discover at distance d always come out behind the remaining d-1 nodes and ahead of the d+1 ones. That ordering is the shortest path guarantee, with no explicit distance tracking needed. A stack is last in, first out, so the most recent branch always gets expanded next, which is depth first by construction.

There's a memory split that follows from the same fact. BFS holds the full frontier, so its peak memory tracks the widest level of the graph. DFS holds only the current path, so its memory tracks the deepest one. Tracing both algorithms frame by frame in the graph course, watching the queue and stack contents change at every step, is what makes the distance ordering stop feeling abstract.

What to do when you're still guessing

If you're staring at a graph problem and reaching for habit, run it through this instead:

If the problem asks for	Reach for
Shortest path or fewest moves, equal cost edges	BFS
Level by level processing	BFS
Nearest target	BFS
Cycle detection	DFS
Topological order	DFS
Connected components	DFS
All paths or backtracking	DFS
Shortest path with weighted edges	Neither, use Dijkstra

I originally posted this on my own blog, a slightly longer version with a directed cycle detection walkthrough.

What's a graph problem that finally made the BFS versus DFS choice click for you, the one where guessing wrong actually cost you in an interview?

FAANG Coding Interviews Aren’t the Same: The DSA Patterns Each Company Actually Tests

Tue, 12 May 2026 15:44:03 +0000

After treating every FAANG company like the same interview, Amazon exposed the gap in about twenty minutes.

I'd built FAANG prep around a small set of pattern families that looked highest-frequency: predicate search, sliding window, hash table fundamentals, and a few graph traversals.

The mental model was that these were the patterns "every big tech round" sampled from.

The first Amazon round asked about Randomised Set design followed by a Queue Design follow up.

Neither was in the deep set the plan covered.

I solved the first one with effort and improvised the second one badly.

The interview went south in the last 20 minutes.

The thing missing wasn't a specific pattern.

It was that Amazon's pattern footprint is meaningfully wider than Google's, and the prep allocation behind every hour was treating every FAANG company as if they sampled from the same bag.

Here's what came out of mapping company tags across 450+ handpicked FAANG problems:

Seven patterns are universal across 6+ major companies. Skipping any of them is a structural hole.
Amazon spans 11+ pattern families, the broadest in the data. "Study three patterns deeply" doesn't work there.
Google has narrower coverage but a distinctive emphasis on predicate search (binary search on the answer space).
Meta wants hash table depth and design fluency in a tighter pattern band.
Prefix Sum is the single most undertrained pattern relative to its 8-company tag count.

Where the old approach was breaking

The old plan looked roughly like this:

Pick five or six pattern families that look universal-ish, drill them to the point you can write the canonical solution from memory, then trust that volume on adjacent problems will generalise to whatever the interview throws.

The implicit bet was that every FAANG company is a sample from roughly the same distribution, and the mean of the drilled patterns covers the mean of the question pool.

The data didn't support the bet.

The surprising part wasn't that companies differed.

It was how much they differed.

Across the company tags:

Google's distribution skewed toward predicate search and graph reasoning. Narrower set, harder reasoning per problem.
Amazon's distribution was the flattest of any company in the set. Eleven plus pattern families, none dominant.
Meta's distribution clustered tight: sliding window, prefix sum, counting, design.
Microsoft had a quietly distinct cluster: 2D binary search and staircase search, multi-dimensional patterns most plans skip.
Apple's distribution was the inverse of Amazon's: deep on fundamentals (especially counting), almost no advanced design.

The mistake wasn't drilling the wrong patterns.

It was applying the same allocation across companies that didn't share the same allocation.

The shift that worked

The shift was small in description and large in practice.

Instead of one prep plan, the move was to build a per-company allocation, anchored to the universal patterns underneath.

Concretely:

Then	Now
Drill 5–6 patterns deeply, hope coverage generalises	Cover 7 universals first, then add 2–4 patterns specific to the target company
Pick problems by data structure (Hash Table, Tree, Graph)	Pick problems by pattern, then filter by company tag
Treat all FAANG rounds as the same problem distribution	Allocate by the company’s actual tag profile
Practise at uniform intensity across pattern families	Front load the universals, then go deep on company-specific gaps

The 7-pattern universal layer never moved:

LRU Cache
Counting
Backtracking
Prefix Sum
Binary Search
Fixed Sliding Window
Variable Sliding Window

What changed was what came after.

For an Amazon round, the next four patterns to drill were:

Randomised Set
Queue Design
2D Binary Search
Staircase Search

plus dedicated time on the Bar Raiser follow up format.

For Google, the next two patterns were:

Predicate Search
Graph reasoning

drilled deeper.

For Meta:

Design depth (LRU Cache from scratch, Randomised Set from scratch)
Maximum Predicate Search

The total prep time stayed roughly the same.

The allocation was different.

What that looked like on the next problem

The clearest example was LRU Cache.

The canonical solution had been in the toolkit for years:

hash map + doubly linked list
O(1) per operation
head and tail sentinels

What I'd never done was rebuild it under a constraint shift.

Which is exactly what the Amazon Bar Raiser round likes to test.

The setup is the standard one:

class LRUCache:
    def __init__(self, capacity):
        self.capacity = capacity
        self.map = {}
        self.head = ListNode()                    # most recently used end
        self.tail = ListNode()                    # least recently used end
        self.head.next = self.tail
        self.tail.prev = self.head

    def get(self, key):
        if key not in self.map:
            return -1
        node = self.map[key]
        self._remove(node)
        self._add_to_front(node)
        return node.value

    def put(self, key, value):
        if key in self.map:
            self._remove(self.map[key])

        node = ListNode(key, value)
        self._add_to_front(node)
        self.map[key] = node

        if len(self.map) > self.capacity:
            lru = self.tail.prev
            self._remove(lru)
            del self.map[lru.key]

The constraint shift Amazon likes to ask:

“Now each entry has a TTL. A read on an expired entry returns -1. The cache still operates at expected O(1) per call.”

That's the moment the canonical answer stops being enough.

The candidate who memorised LRU starts redesigning from scratch.

The candidate who built the original from the invariant asks one question first:

Which invariant did the doubly linked list maintain, and does that invariant still hold under TTL?

The list maintained an ordering:

Nodes near head were used more recently than nodes near tail.

The eviction criterion changes from:

“Least recently used”

to:

“Expired or least recently used.”

The list ordering by recency is still useful for the second clause.

The first clause needs a different signal.

That's where lazy expiry (timestamp checked on read) and eager expiry (min heap on TTL) diverge.

The canonical LRU sits in most candidates' heads.

The constraint flip doesn't.

Once practising the follow up explicitly becomes part of the loop, on every design problem in the universal set, the conversion rate on Amazon-style rounds shifts noticeably.

The pattern that's underrated for years

Looking back at the tag data, the single biggest miscalibration in the old plan was Prefix Sum.

Eight companies tag it.

That's the same as Backtracking.

More than almost every classic searching variant except the basic one.

Most prep plans treat it like a minor utility pattern because it doesn't have a flagship problem the way LRU Cache does.

In the data, it punches above its weight:

Subarray Sum Equals K
Equilibrium Index
Count Subarrays Divisible by K

especially in Meta and Amazon variants.

The fix took less than a weekend.

Prefix Sum's mechanic is small enough that two evenings of focused drilling cover it.

The composite version (prefix sum + hash map of seen sums) is the FAANG-shaped one, and it's the one most prep plans bury under a miscellaneous heading.

What works for someone in the same spot

Three rules from the retrospective:

1. Cover the seven universals first

No exceptions.

LRU Cache
Counting
Backtracking
Prefix Sum
Binary Search
Fixed Sliding Window
Variable Sliding Window

No matter the target company.

2. Specialise second

But specialise to the company’s actual tag profile.

For Amazon:

breadth
constraint-flip follow ups

For Google:

predicate search
graph reasoning depth

For Meta:

design depth
sliding window fluency

For Microsoft:

2D + staircase search

For Apple:

fundamentals depth

3. Cut what doesn't match

Targeting Google and not Amazon?

Queue Design can wait.

Targeting Meta and not Microsoft?

Staircase Search can wait.

Prep time is finite.

The data tells you where the false-priority work lives.

The biggest shift, though, wasn't any one pattern.

“FAANG prep” isn't one allocation problem.

It's five separate ones with a shared seven-pattern foundation.

The company determines which 2–4 patterns sit on top of it.

Every hour spent assuming the foundation was all that mattered was an hour that could've gone to the layer above.

Originally posted in a longer form on my own blog, with the per-company FAQ and a fuller breakdown of what each company quietly deemphasises.

If you've interviewed at more than one FAANG, what was a pattern that came up where the company’s reputation hadn't prepared you for it?

Arrays vs Linked Lists: The Real Difference Most Interview Prep Misses

Sun, 10 May 2026 13:06:23 +0000

It took an LRU Cache interview for me to realise the complexity table wasn't answering the real question.

I'd been picking between arrays and linked lists for years before realising the table wasn't the answer to the question.

Then LRU Cache came up in an interview, and the table didn't help: both structures were on the page, neither alone solved the problem, and the silence ran nine minutes before the interviewer gave a hint.

What I figured out

Arrays and linked lists differ for one reason: contiguous memory vs scattered memory. Every entry on the complexity table follows from that single fact.
Two O(n) operations aren't equal in practice. An array scan of a million integers runs roughly an order of magnitude faster than the equivalent linked list traversal because of CPU cache locality.
The "O(1) insertion" claim about linked lists comes with a hidden prerequisite: the algorithm has to already hold a pointer to the position. Find it first, and you've paid O(n) before the insertion runs.
Many interesting interview problems combine both structures rather than picking one. LRU Cache is the canonical case.

Where the table stopped working

For a long time the table was the decision tree.

The problem mentioned "insert" or "delete," reach for a linked list. The problem mentioned "access by index," reach for an array.

That worked on simple problems.

It fell apart on anything that needed both behaviours.

The specific moment was sitting in front of LRU Cache.

The problem wants get(key) and put(key, value) both in O(1) average time, with eviction of the least recently used entry when the cache is full.

A hash map handles the lookup half, since get has to be O(1) and a hash map is the obvious answer.

Then comes the recency tracking, which means some kind of ordering on the entries.

An array of (key, timestamp) pairs would mean updating timestamps on access, and the eviction step turns into a linear scan for the smallest timestamp.

That breaks the O(1) requirement.

Switch to a linked list and inserting at the front on every access is O(1) given a pointer to the node.

To find the node from a key, the algorithm walks the list, which is O(n).

The hash map gives O(1) lookups but no reordering.

The linked list gives O(1) reordering but no fast lookup.

The problem wasn't picking the wrong structure.

The problem was thinking the question had only two answers.

The realisation that broke the table

The fix sounds obvious in retrospect:

Keep both.

A hash map mapping keys to linked list nodes, and a doubly linked list whose nodes store the values and recency order.

The hash map gives O(1) access to the exact node.

Once the algorithm has the node, the linked list reorders without traversing in O(1).

Eviction becomes removing the tail node, which is also O(1) because a tail pointer is maintained.

The two structures aren't competing.

They're solving different sub-problems.

The hash map handles constant-time access.

The linked list handles pointer reassignment at known positions.

The qualifier on linked list insertion:

"O(1) only if you already hold the pointer"

finally has a structure feeding it those pointers for free.

That's the same property powering a handful of linked list patterns that previously read like tricks: reversal, splitting, merging, fast and slow pointers.

That's the realisation that broke the table.

The table had been answering:

“If you pick exactly one structure, which one wins?”

The interesting problems were asking a different question:

“Which combination of memory layouts gives every operation in the algorithm the access pattern it needs?”

What it looks like in code

Here's the construction the technique walkthrough lands on:

class Node:
    def __init__(self, key, value):
        self.key = key
        self.value = value
        self.prev = None
        self.next = None

class LRUCache:
    def __init__(self, capacity):
        self.capacity = capacity
        self.lookup = {}                  # hash map: key -> Node
        self.head = Node(0, 0)           # sentinel
        self.tail = Node(0, 0)           # sentinel
        self.head.next = self.tail
        self.tail.prev = self.head

    def _remove(self, node):
        node.prev.next = node.next
        node.next.prev = node.prev

    def _add_front(self, node):
        node.prev = self.head
        node.next = self.head.next
        self.head.next.prev = node
        self.head.next = node

    def get(self, key):
        if key not in self.lookup:
            return -1

        node = self.lookup[key]          # O(1) via hash map
        self._remove(node)               # O(1) via direct pointer
        self._add_front(node)            # O(1) splice at head

        return node.value

    def put(self, key, value):
        if key in self.lookup:
            self._remove(self.lookup[key])

        node = Node(key, value)
        self.lookup[key] = node
        self._add_front(node)

        if len(self.lookup) > self.capacity:
            lru = self.tail.prev         # O(1) via tail sentinel
            self._remove(lru)
            del self.lookup[lru.key]

Every operation is O(1).

The hash map carries the lookup load.

The doubly linked list carries the ordering load.

Each structure does the thing it's actually good at, and the combination handles a problem neither could solve alone.

What I'd tell my earlier self

The contrast between the old picking heuristic and the current one comes out cleanest side by side:

Then	Now
Match keywords in the prompt ("insert" → linked list) to the table.	Identify every operation the algorithm performs and check whether each one already has the pointer or index it needs.
Treat arrays and linked lists as competing answers.	Treat them as primitives that combine.
Quote `O(1)` insertion for linked lists without the qualifier.	Read "`O(1)` insertion" as "`O(1)` once you've paid for the pointer."
Trust two `O(n)` operations as equivalent in practice.	Account for cache locality. Array scans often beat linked list traversals in real hardware.

And three rules that would've shortened the loop:

Identify the dominant operation first. Before picking a structure, write down the access pattern the algorithm needs. "Lookup by key, then mutate at that position" is a different question than "lookup by key, then iterate from there."
Check the qualifier on every linked list insertion claim. Does the algorithm already hold the pointer, or does it have to walk to find it? If it has to walk, the advantage is gone.
When two structures each solve half the problem, try combining them. That's the move that handles LRU Cache, caching problems, and most eviction-style systems.

I wrote a longer version on Codeintuition that walks the same memory-layout reasoning through stacks, queues, and graph adjacency representations.

If you want a deeper walkthrough of pointer-based mutation patterns, the singly linked list course on codeintuition covers seven of them with worked examples.

What was the moment a data structure choice finally clicked for you, where the textbook framing had been hiding the actual question?

How to Know If You’re Ready for FAANG Interviews

Sat, 09 May 2026 12:57:37 +0000

After 280 LeetCode problems, I realised “feeling ready” wasn’t a metric. A diagnostic was.

I'd solved around 280 problems by the time the FAANG readiness question got serious, and the answer changed every week. Some weeks felt close after a clean batch of trees. Most weeks the next unfamiliar medium would freeze cold and the confidence would evaporate by Tuesday. The pattern repeated for months without resolving.

It took longer than it should have to notice the question itself was the issue.

"Do I feel ready" wasn't a question with a stable answer.

The threshold was real. The measurement of it was a mood read on a moving session.

What I figured out

Self assessed readiness drifts every session. A clean morning of trees and a frozen afternoon of graphs both produced wrong answers.
The interview wasn't testing the same skill that practice on familiar problems trains. It was testing what holds up on shapes you haven't seen.
Problem count flatlined as a useful signal somewhere around 100 problems. Past that, more volume on familiar shapes added count without moving the threshold.
The fix was a measurable test, not more prep. An unseen medium, a hidden title, a real timer, repeated across three different families.
The diagnostic was more useful than the score. "Two passed, one failed on graphs" was an action plan. "Feeling 70 percent ready" was anxiety.

Quick disclosure before I get into this: I built Codeintuition, a structured learning platform for coding interviews. This post is the retrospective on what someone should have handed me earlier, not a pitch for the product.

Where the approach was breaking

The first thing that broke was the belief that the count was the metric.

The tracker said 280, on its way to 350. The tracker also didn't predict any individual interview performance. Open a medium you haven't seen, freeze for ten minutes, and the count number sits there grinning at you, useless.

The second thing that broke was the topic completion checkmark.

Sliding window finished in February. By June the recall on a sliding window medium you hadn't seen was unreliable. The completion checkmark didn't decay.

Recall did.

The third thing that broke was speed on familiar problems.

Two Sum in two minutes feels like fluency. It's actually retrieval of a stored solution. The first time you hit a problem that looks like Two Sum but has a different constraint structure, the speed disappears and you're back to staring.

The fourth thing was peer comparison, which broke quietly because it had never worked in the first place.

Someone else got into Google in six months. That said nothing about your readiness. Background, family coverage, how they'd practised, the level they interviewed for, none of it generalises.

What was actually happening is that all four signals were measuring the wrong thing.

The interview gives you a problem you haven't seen. The four signals all measured behaviour on problems you had seen.

They were diagnostically useless for the question they were being asked to answer.

The diagnostic that ended up working

The version that worked was small and strict.

Two hours. Three problems. Three different families. Real interview conditions.

The shape:

Pick a pattern family genuinely studied (sliding window, tree traversal, graph BFS, DP subsequence)
Find a medium difficulty problem in that family that has never been solved, hinted, or read about
Cover the problem name so the title can't reveal the family
Twenty minute timer, hard cap on failed code execution attempts, no peeking
Identify the family from the constraints, build the solution from the family's invariant, trace it before running

A pass was:

solved within the timer
fewer than two failed runs
family identified from the constraints

Anything else was data.

Three passes across three families was a strong readiness signal. Recognition was firing on shapes you hadn't seen, the construction was following the family's invariant rather than recall, and the conditions were close enough to a real round that the result generalised.

Two passes and one failure told you precisely which family to work on. No need for more random volume.

Depth in one specific place.

All three failed was the most useful diagnostic of the three.

It said the prep method had been building near transfer without far transfer, which is the gap described in the idea of Transfer of Learning.

Method gap, not talent gap.

The fix was correspondingly narrower than:

“Grind more problems.”

What that looked like on the third pass

The pass that taught the most was a DP subsequence problem run cold.

The family had been studied. The canonical examples had been worked through. It hadn't been ground the way sliding window or trees had been ground, so it was a fair test of recognition rather than recall.

The constraints described a longest increasing subsequence variant.

With the title hidden, the recognition still happened in the first three minutes because the constraints fit the DP subsequence shape:

A one dimensional input, not two.
An output asking for the longest sub structure satisfying a condition.
The absence of two pointer or sliding window triggers that would have applied if the answer had been contiguous.

The skeleton came from the family's invariant, not from a remembered problem:

dp[i] is the length of the longest valid subsequence ending at index i.

def length_of_lis(nums):
    if not nums:
        return 0

    dp = [1] * len(nums)

    for i in range(1, len(nums)):
        for j in range(i):
            if nums[j] < nums[i]:
                dp[i] = max(dp[i], dp[j] + 1)

    return max(dp)

Trace on a five element array by hand. Verify the recurrence on the trace. Then run.

It passed.

Five minutes still on the timer.

The check that mattered wasn't getting it right.

It was how:

Family identified from the constraints inside three minutes
Skeleton written from the invariant rather than retrieval
Verified by tracing

That's what pattern recognition holding under pressure looks like in practice.

If any of those three steps had broken, the pass would have been a memory pass, not a recognition pass, and the family wouldn't actually have been ready yet.

The protocol the earlier version of me needed

The change that mattered most was switching what practice was for.

Up to about month four practice was for a problem set. After running the diagnostic for the first time, practice changed shape to feed the diagnostic.

Before the diagnostic	After
Solve next problem on the list	Pick a family, work through three problems with the title hidden
Read editorial when stuck	Read the foundational material on the family's invariant when stuck
Track problem count	Track families where the diagnostic passes cleanly
Do problems in order of difficulty	Do problems in order of how shallow recognition was on the family
Speed up by recognising problems	Speed up by recognising the family from constraints with the title hidden
"How many problems before I'm ready"	"How many families pass the diagnostic before I'm ready"

Three rules ended up doing most of the work in the after column.

1. One unseen medium per family per week

Title hidden.

Timer running.

Not as a substitute for the rest of practice.

As the diagnostic that anchored what to practise next.

2. Foundational material on the family's invariant before more volume

When a family failed the diagnostic, the next thing to read wasn't a new problem.

It was the page on what made the family applicable.

Volume came after.

That distinction between solving a problem and recognising a family from constraints is exactly what eventually shaped how I built Codeintuition.

3. Don't retest with the same problem

A retest on a problem already seen, even one that was failed, measured recall instead of reasoning.

The whole point of the diagnostic was novel problem performance.

What the failure modes told me

Most engineers running a version of this diagnostic don't pass three for three on the first attempt.

The first attempt for me wasn't clean either.

The diagnoses to read off the result:

One family failed

The pattern was understood at a surface level but the identification triggers and the construction skeleton hadn't been internalised.

Fix:

revisit foundational material
retest with a different unseen problem

Two families failed

Usually:

One strong area with over practised volume, shallow gaps everywhere else.

Common for engineers who spent months on one topic because the work felt productive.

Fix:

broaden coverage
spend focused time on the families where the depth is thin

All three failed

Method gap, not talent gap.

Too much:

solving familiar problems
repetition
memorisation

Not enough:

recognition
transfer
unseen problems
interview shaped conditions

The fix is narrower than:

"Work harder."

What I wish someone had handed me earlier

The difference between the score and the diagnostic was the difference between an opaque feeling and an action plan.

"Maybe 70 percent ready" was anxiety.

"Two passed, the DP subsequence family failed because the invariant for non contiguous selections wasn't internalised yet" was what to do on Wednesday.

If family coverage is the bottleneck rather than conditions, the algorithms learning path on Codeintuition is one place to fill the gap before retesting.

The diagnostic itself doesn't depend on it.

The point is the test, not the source of the problems.

I originally wrote a longer version on my own blog that includes the per family signal breakdowns and diagnosis trees for the most common failure modes.

What was the moment that made the readiness question itself feel like the wrong question, and what did you start measuring instead?

LeetCode Milestone!!!

Sat, 11 Apr 2026 17:07:12 +0000

1400+ leetcode solved!!!

960. Delete Columns to Make Sorted III

Wed, 01 Apr 2026 21:03:23 +0000

In the last post, I discussed how recognizing patterns is important in solving coding challenges and discussed the Longest Increasing Subsequence. I shall talk about applying the basics in this problem to solve one variation of LIS. Follow me here, on Twitter, LinkedIn or Github for more.

Problem
You are given an array of n strings strs, all of the same length.

We may choose any deletion indices, and we delete all the characters in those indices for each string.

For example, if we have strs = ["abcdef","uvwxyz"] and deletion indices {0, 2, 3}, then the final array after deletions is ["bef", "vyz"].

Suppose we chose a set of deletion indices answer such that after deletions, the final array has every string (row) in lexicographic order. (i.e., (strs[0][0] <= strs[0][1] <= ... <= strs[0][strs[0].length - 1]), and (strs[1][0] <= strs[1][1] <= ... <= strs[1][strs[1].length - 1]), and so on). Return the minimum possible value of answer.length.

Example 1:

Input: strs = ["babca","bbazb"]
Output: 3
Explanation: After deleting columns 0, 1, and 4, the final array is strs = ["bc", "az"].
Both these rows are individually in lexicographic order (ie. strs[0][0] <= strs[0][1] and strs[1][0] <= strs[1][1]).
Note that strs[0] > strs[1] - the array strs is not necessarily in lexicographic order.
Example 2:

Input: strs = ["edcba"]
Output: 4
Explanation: If we delete less than 4 columns, the only row will not be lexicographically sorted.
Example 3:

Input: strs = ["ghi","def","abc"]
Output: 0
Explanation: All rows are already lexicographically sorted.

Constraints:

n == strs.length
1 <= n <= 100
1 <= strs[i].length <= 100
strs[i] consists of lowercase English letters.

Discussion

We apply the same principle in LIS with the double for loops.The only difference is we check all the characters in one column are less than or equal to all the characters in the other. We do this as we are trying to maximize the number of columns to be deleted.

Solution

Java

class Solution {
    public int minDeletionSize(String[] strs) {
     int length=strs[0].length();      
     int [] dp=new  int[length];          
     Arrays.fill(dp,1);
     for(int col=1;col<length;col++){       
      for(int j=0;j<col;j++){
        int numOfRows=0; 
        for(int i=0;i<strs.length;i++){
         char curr=strs[i].charAt(col);   
         char prev=strs[i].charAt(j);
         if(prev>curr) break;
         else numOfRows++;  
         }
         if(numOfRows==strs.length && dp[col]<=dp[j])dp[col]=dp[j]+1;          
        }
      }  
     Arrays.sort(dp);
     return length-dp[dp.length-1]; 
    }
}

public class Solution {
    public int MinDeletionSize(string[] strs) {
      int length=strs[0].Length;      
     int [] dp=new  int[length];          
     Array.Fill(dp,1);
     for(int col=1;col<length;col++){       
      for(int j=0;j<col;j++){
        int numOfRows=0; 
        for(int i=0;i<strs.Length;i++){
         char curr=strs[i][col];   
         char prev=strs[i][j];
         if(prev>curr) break;
         else numOfRows++;  
         }
         if(numOfRows==strs.Length && dp[col]<=dp[j])dp[col]=dp[j]+1;          
        }
      }  
     Array.Sort(dp);
     return length-dp[dp.Length-1];    
    }
}

C++

class Solution {
public:
    int minDeletionSize(vector<string>& strs) {
     string first=strs[0];
     int length=first.size();      
     vector<int> dp;          
     for(int i=0;i<length;i++)dp.push_back(1);
     for(int col=1;col<length;col++){       
      for(int j=0;j<col;j++){
        int numOfRows=0; 
        for(int i=0;i<strs.size();i++){
         string str= strs[i];  
         char curr=str[col];   
         char prev=str[j];
         if(prev>curr) break;
         else numOfRows++;  
         }
         if(numOfRows==strs.size() && dp[col]<=dp[j])dp[col]=dp[j]+1;          
        }
      }  
     std::sort(dp.begin(),dp.end());
     return length-dp[dp.size()-1];    
    }
};

300. Longest Increasing Subsequence

Wed, 18 Mar 2026 18:26:42 +0000

A good way to master coding challenges is to recognize patterns. A good way to recognize patterns is to understand the basics. This may involve understanding one core problem and learning to apply it. Think of it as similar to learning to crawl before learning to walk and then learning to run. An example core problem is the Longest Increasing Subsequence. Variations of this problem are frequently asked. Follow me here, on Twitter, LinkedIn or Github for more.

Problem

Given an integer array nums, return the length of the longest strictly increasing subsequence.

Example 1:

Input: nums = [10,9,2,5,3,7,101,18]
Output: 4
Explanation: The longest increasing subsequence is [2,3,7,101], therefore the length is 4.
Example 2:

Input: nums = [0,1,0,3,2,3]
Output: 4
Example 3:

Input: nums = [7,7,7,7,7,7,7]
Output: 1

Constraints:

1 <= nums.length <= 2500
-104 <= nums[i] <= 104

Discussion

To solve, we use dynamic programming. We build a 1-dimensional array lengths to store the maximum length of the subsequences at each index and initialize it so that each value is 1.
Then we use two for loops. The first starts at the second index (index 1 in some programming languages) and iterates forward until the end of the array. We shall refer to it as i .
The second starts at the first index (index 0 in some languages) and iterates forward until it reaches i. We shall refer to it as j. If the number found at j is less than that found at i and lengths[i] is less than or equal to lengths[j], we recalculate the value at lengths[i] as lengths[i]=lengths[j]+1.
On finishing the double for loop,we sort lengths and return the last value which is the largest.

Solution

Java

class Solution {
    public int lengthOfLIS(int[] nums) {
     int [] lengths= new int[nums.length];
     for(int i=0;i<lengths.length;i++)lengths[i]=1;
     for(int i=1;i<nums.length;i++){
      for(int j=0;j<i;j++){
       if(nums[j]<nums[i] && lengths[i]<=lengths[j]) lengths[i]=lengths[j]+1;
      }
     }
     Arrays.sort(lengths);
     return lengths[lengths.length-1];
    }
}

public class Solution {
    public int LengthOfLIS(int[] nums) {
     int [] lengths= new int[nums.Length];
     int max=0;
     for(int i=0;i<lengths.Length;i++)lengths[i]=1;
     for(int i=1;i<nums.Length;i++){
      for(int j=0;j<i;j++){
       if(nums[j]<nums[i] && lengths[i]<=lengths[j]) lengths[i]=lengths[j]+1;
      }
     }
     for(int i=0;i<lengths.Length;i++)max=Math.Max(max,lengths[i]);
     return max;   
    }
}

C++

class Solution {
public:
    int lengthOfLIS(vector<int>& nums) {
     vector<int>lengths;
     int max=0;
     for(int i=0;i<nums.size();i++)lengths.push_back(1);
     for(int i=1;i<nums.size();i++){
      for(int j=0;j<i;j++){
       if(nums.at(j)<nums.at(i) && lengths.at(i)<=lengths.at(j)) lengths.at(i)=lengths.at(j)+1;
      }
     }
     for(int i=0;i<lengths.size();i++)max=std::max(max,lengths.at(i)); 
     return max;   
    }
};

Javascript

var lengthOfLIS = function(nums) {
 const lengths= [];
 let max=0;
 for(let i=0;i<nums.length;i++)lengths.push(1);
 for(let i=1;i<nums.length;i++){
  for(let j=0;j<i;j++){
   if(nums[j]<nums[i] && lengths[i]<=lengths[j]) lengths[i]=lengths[j]+1;
  }
 }
 for(let i=0;i<lengths.length;i++)max=Math.max(lengths[i],max);
 return max;
};

If You’re a Beginner in Tech, Read This Before Choosing DSA, Web Dev or AI

Mon, 23 Feb 2026 06:15:47 +0000

Introduction: The Beginner’s Confusion

If you’re new to tech, you’ve probably heard these three words everywhere:

DSA. Web Development. AI.

Everyone online has an opinion.
One person says: “Do DSA first.”
Another says: “Build projects, do web dev.”
Another says: “AI is the future, learn AI now.”

As a beginner, this creates confusion, pressure, and fear of choosing the “wrong path.”

Here’s the truth:
There is no single correct answer, but there is a smart order.

This blog will help you understand:

What each field actually means
What beginners think they are
What beginners should learn first
How to choose based on your goals

Understanding the Three Paths

1. DSA (Data Structures & Algorithms)

What it really is:
Logical problem-solving using arrays, strings, recursion, trees, graphs, and algorithms.

What beginners think:
“DSA = coding interviews.”

Reality:
DSA trains your thinking, not just your coding.

It builds:

Logical reasoning
Problem-solving mindset
Pattern recognition
Code efficiency

DSA doesn’t make apps.
DSA doesn’t build websites.
DSA builds brains.

2. Web Development

What it really is:
Building real products: websites, apps, platforms, dashboards, systems.

What beginners think:
“Web dev = HTML + CSS only.”

Reality:
Web dev teaches:

System thinking
Real-world problem solving
APIs
Databases
Authentication
Architecture
Debugging
Product building

Web dev builds visible results.

3. AI / Machine Learning

What it really is:
Math + data + programming + statistics + models + logic.

What beginners think:
“AI = using ChatGPT or tools.”

Reality:
AI requires:

Programming foundations
Data handling
Algorithms
Math
Probability
Logic
Structured thinking

AI is not beginner-friendly without foundations.

The Biggest Lie Beginners Are Told

“You must choose one path at the start.”

This is wrong.

Tech is not a single-lane road.
It’s a layered system.

You don’t choose one,
You build in layers.

The Smart Learning Order (Beginner Friendly)

Here’s the most practical path for beginners:

Step 1: Programming Fundamentals

Before anything else:

One language (Python / JavaScript / Java / C++)
Variables
Loops
Conditions
Functions
Basic logic
Input/output

No foundation = no growth.

Step 2: Basic DSA + Problem Solving

Not hardcore competitive coding — but:

Arrays
Strings
Basic recursion
Searching
Sorting
Pattern problems
Logical thinking

This builds thinking ability.

Step 3: Web Development (Project Building Phase)

Now start building:

HTML, CSS, JS
Frontend frameworks
Backend basics
Databases
APIs
Authentication
Real projects

This builds confidence + skill + portfolio.

Step 4: AI / ML (When Foundation Is Ready)

Now AI makes sense:

Data handling
Python
Logic
Algorithms
Math foundations
Real understanding of models

Without foundation, AI becomes copy-paste learning.

So What Should Beginners Actually Learn First?

The honest answer:

Learn how to think, then learn how to build, then learn how to specialize.

In simple words:

Learn programming basics
Learn problem-solving (DSA basics)
Build real projects (Web Dev)
Then choose specialization (AI, ML, Data, DevOps, etc.)

Different Goals = Different Focus

If your goal is jobs:

Programming
DSA
Web dev projects
System understanding

If your goal is startups:

Web dev
Product building
Systems
Scaling thinking

If your goal is research/AI:

Math
Programming
Algorithms
Data
Then AI/ML

Final Truth Beginners Need to Hear

You don’t need to rush into AI.
You don’t need to master DSA on day one.
You don’t need to build startups immediately.

What you need is:

Clarity
Consistency
Foundations
Patience
Daily progress

Because in tech:

Skills compound. Knowledge stacks. Progress multiplies.

Closing Thought

If you’re a beginner and confused between DSA, Web Dev, and AI, remember this:

Strong foundations create strong careers.
Strong thinking creates strong coders.
Strong systems create strong builders.

Start simple.
Build slowly.
Grow deeply.
And choose smartly.

LeetCode #1458.Max Dot Product of Two Subsequences

Wed, 04 Feb 2026 17:37:05 +0000

Many engineers find leetcode problems hard and not a reflection of the actual work to do. I do have some sympathy for this view. Nonetheless, I do think that these questions can help practice and build programming skills. Due to this and the fact that these prop up in interviews, I will post discussions of these from time to time.Follow me on twitter,github or Linkedin for these and more.

Problem

Given two arrays nums1 and nums2.

Return the maximum dot product between non-empty subsequences of nums1 and nums2 with the same length.

A subsequence of an array is a new array which is formed from the original array by deleting some (can be none) of the characters without disturbing the relative positions of the remaining characters. (ie, [2,3,5] is a subsequence of [1,2,3,4,5] while [1,5,3] is not).

Example 1:

Input: nums1 = [2,1,-2,5], nums2 = [3,0,-6]
Output: 18
Explanation: Take subsequence [2,-2] from nums1 and subsequence [3,-6] from nums2.
Their dot product is (23 + (-2)(-6)) = 18.
Example 2:

Input: nums1 = [3,-2], nums2 = [2,-6,7]
Output: 21
Explanation: Take subsequence [3] from nums1 and subsequence [7] from nums2.
Their dot product is (3*7) = 21.
Example 3:

Input: nums1 = [-1,-1], nums2 = [1,1]
Output: -1
Explanation: Take subsequence [-1] from nums1 and subsequence [1] from nums2.
Their dot product is -1.

Constraints:

1 <= nums1.length, nums2.length <= 500
-1000 <= nums1[i], nums2[i] <= 1000

Discussion

I was stumped by this question. I read the hints and somebody mentioned that it was similar to Longest Common Subsequence. That got me thinking. I had to use a 2-D dp array to get the result.

I also had to keep track of the multiplication of each number from each array along with the values from the previous row,current column and the previous column and current row.For edge cases I had to calculate the values for the first row and the first column.I came up with the solution below which passed all 70 cases.

Solution

class Solution {
    public int maxDotProduct(int[] nums1, int[] nums2) {
     int  [] [] dp=new int[nums1.length] [nums2.length];   
     int firstRowMax=nums1[0]*nums2[0];
     int answer=0;
     dp[0][0]=firstRowMax;
     for(int j=1;j<nums2.length;j++){
      int current=nums1[0]*nums2[j];
      firstRowMax=Math.max(firstRowMax,current);
      dp[0][j]=firstRowMax;
     }
     answer=firstRowMax;
     for(int i=1;i<nums1.length;i++){
      for(int j=0;j<nums2.length;j++){
        int current=nums1[i]*nums2[j];
        if(j==0) dp[i][j]=Math.max(dp[i-1][j],current);   
        else
         dp[i][j]=Math.max(dp[i-1][j-1]+current,Math.max(current,Math.max(dp[i-1][j],dp[i][j-1])));
        answer=Math.max(answer,dp[i][j]);
      }  
     }
     return answer;
    }
}

Building Queue From Stack

Fri, 05 Sep 2025 18:44:00 +0000

Imagine your interviewer asks for a queue but with a twist: you can only use stacks.

It’s actually a small shift in approach that reveals how data structure thinking and algorithmic trade offs make you a stronger engineer.

Read on, this one problem has shown up in interviews, production bug fixes, and test cases for people who later got promoted for thinking clearly under constraint.

Building a Queue using Two Stacks is a classic DSA puzzle that’s deceptively practical. It’s not just about solving the puzzle, it’s about demonstrating these career making skills:

1 : converting constraints into elegant designs,
2 : reasoning about amortized complexity (not just worst case noise),
3 : writing predictable, maintainable code that can be explained in an interview or to your teammates.

Stacks are LIFO, queues are FIFO, that’s the core mismatch. But by pairing two stacks and moving elements between them on demand, we get the FIFO behavior for free, while keeping operations simple.

How to approach ? : do most of the work lazily (only when needed). This gives amortized O(1) time for both enqueue and dequeue, which is often good enough in interviews and many real world scenarios.

class QueueUsingStacks:
    """
    Queue implemented with two stacks (lists).
    - push_stack: where we push new elements (enqueue)
    - pop_stack: where we pop elements for dequeue/peek
    Amortized costs: enqueue O(1), dequeue amortized O(1).
    """
    def __init__(self):
        self.push_stack = []
        self.pop_stack = []

    def _transfer_if_needed(self):
        """Move everything from push_stack to pop_stack if pop_stack is empty.
        This reverses order so front of queue is at the end of pop_stack.
        Each element moves at most once => amortized O(1) per op.
        """
        if not self.pop_stack:
            while self.push_stack:
                self.pop_stack.append(self.push_stack.pop())

    def enqueue(self, x):
        """Add x to the end of the queue. O(1)."""
        self.push_stack.append(x)

    def dequeue(self):
        """Remove and return the front element. Raises IndexError if empty."""
        self._transfer_if_needed()
        if not self.pop_stack:
            raise IndexError("dequeue from empty queue")
        return self.pop_stack.pop()

    def peek(self):
        """Return front element without removing it. Raises IndexError if empty."""
        self._transfer_if_needed()
        if not self.pop_stack:
            raise IndexError("peek from empty queue")
        return self.pop_stack[-1]

    def is_empty(self):
        """True if queue has no elements."""
        return not (self.push_stack or self.pop_stack)

    def __len__(self):
        """Total number of elements in the queue."""
        return len(self.push_stack) + len(self.pop_stack)


# ---- clear demo with labeled prints ----
if __name__ == "__main__":
    q = QueueUsingStacks()
    q.enqueue(10)
    q.enqueue(20)
    q.enqueue(30)

    print("dequeue ->", q.dequeue())   # -> 10
    q.enqueue(40)

    print("peek    ->", q.peek())      # -> 20
    print("len     ->", len(q))        # -> 3

    print("draining queue:")
    while not q.is_empty():
        print(q.dequeue())

If you found this helpful, like or share so your network can pick up a neat DSA approach. Read more on DSA with me here.

Understanding Recursion

Fri, 22 Aug 2025 09:29:05 +0000

Have you ever seen those Russian dolls, where one doll opens to reveal a smaller one inside, and then another smaller one, and so on? Recursion in programming is a bit like that. It’s when a function calls itself to solve a smaller piece of the problem until it reaches the simplest version, which can be solved directly.

Let’s take a simple real-world example: printing a list of names from last to first.

# Recursive function to print names in reverse order
def print_names_reverse(names, index):
    # Base case: stop when we reach the beginning
    if index < 0:
        return
    
    # Print the current name
    print(names[index])
    
    # Recursive call: move to the previous name
    print_names_reverse(names, index - 1)

# Sample list
names_list = ["Alice", "Bob", "Charlie", "Diana"]

# Start recursion from the last index
print_names_reverse(names_list, len(names_list) - 1)

How it works step by step:

We start at the last name (“Diana”).

The function prints it, then calls itself for the previous name.

This keeps happening until we reach the first name.

Once the first name is printed, the function stops — this stopping point is called the base case.

Notice how the function keeps calling itself, but each time it’s a slightly smaller problem. That’s recursion in its simplest form.

Recursion can look magical, but it’s all about breaking a problem into smaller pieces. Once you get the hang of it, you’ll see it’s a very natural way to solve problems — especially ones that repeat themselves.

Sometimes, recursion can end up repeating the same work for different parts of a problem. This is where a concept called memoization comes in — it’s a clever way to remember results so you don’t redo work unnecessarily.

Curious about making recursion super efficient and avoiding repeated work? Check out my Medium article on recursion with memoization
to see the next level in action! (Free link attached for you)

From Struggle to Solution-An Approach to Solving a programming problem using #650.Leetcode's 2 keys

Thu, 10 Jul 2025 18:41:52 +0000

1.Introduction

I regularly practice leetcode if not always on a daily basis. The reasons that I do this are: to keep my coding skills sharp, to deepen my understanding of algorithms and data structures and to prepare for coding challenges and technical interviews. Recently, I solved Leetcode's #650-the 2 keys keyboard using dynamic programming and I have decided to share my approach to solving this problem.Below is a description of the problem.

2 Keys Keyboard

There is only one character 'A' on the screen of a notepad. You can perform one of two operations on this notepad for each step:

Copy All: You can copy all the characters present on the screen (a partial copy is not allowed).
Paste: You can paste the characters which are copied last time.
Given an integer n, return the minimum number of operations to get the character 'A' exactly n times on the screen.

Example 1:

Input: n = 3
Output: 3
Explanation: Initially, we have one character 'A'.
In step 1, we use Copy All operation.
In step 2, we use Paste operation to get 'AA'.
In step 3, we use Paste operation to get 'AAA'.
Example 2:

Input: n = 1
Output: 0

Constraints:

1 <= n <= 1000

2.First Thoughts

I read the problem and the topics it was listed under. It was listed as Math and Dynamic Programming. My understanding was that there were 2 types of operations: a copy and paste and a paste. I was at first baffled and confused about where to start. I mean how could I minimize the number of operations to achieve this task? The fact that it was listed as dynamic programming gave me an idea-use a 1-d array to store the results of subproblems but I was still baffled.

3.Attempts & Failures
I read the hints. Only 1 was provided. It said "How many characters may be there in the clipboard at the last step if n = 3? n = 7? n = 10? n = 24?". This confused me more. I decided to try something. I could not come up with anything so I decided to reread the problem. On doing so, I realized my first error. 2 types of operations were allowed: a copy all and a paste.This helped. I did some thinking and realized that for a final string of 6,I could do a copy and paste of 3 characters and ditto for a string of 4 characters. It was progress but unfortunately not enough. I decided to read the discussion.

2 observations.
If n is a prime=> ans=n
If n=2^k=> ans=2*k
Something to do with prime factorization, maybe Sieve method can play again, not very necessary.
Have a nice day.

This was helpful but still I struggled.

4. The Breakthrough
I decided to give it a rest and to come back to it later. I was eating lunch and my mind thought about it. I had a realization!!! If the final string was 1000 characters, I could minimize by performing a copy and paste on a string of 500 problems. If it was prime, I could perform a copy and paste of 1 character n times. If it was a string of 27 characters, I could copy a string of 9 characters and paste it twice. So I found a solution. Create a 1-d array of length n+1.Iterate from the index 2 to the end of the array,if the current index is prime, record its number.Otherwise,get its greatest factor,go to that position in the array and calculate the current value by adding the dp value of the highest factor and the quotient of the current value/highest factor.

if(isPrime(i) dp[i]=i;
else dp[i]=dp[highestFactor(i)]+(i/highestFactor(i)).

With this in mind, I attempted a solution. I attempted to do this in Java. Here was my first solution.

class Solution {
    public int minSteps(int n) {
      int []dp= new int[n+1];
      for(int i=2;i<n+1;i++){
       if(isPrime(i))dp[i]=i;
       else {
        //System.out.println
        dp[i] =dp[highestDivisor(i)]+(i/highestDivisor(i));
       } 
      }  
      return dp[n];
    }

    public int highestDivisor(int n) {
        if (n <= 1) return -1; // No proper divisor exists for 0 or 1

        for (int i = n / 2; i >= 1; i--) {
            if (n % i == 0) {
                return i; // First divisor found from the top is the highest
            }
        }
        return -1; // Should never reach here for n > 1
    }

    public  boolean isPrime(int n) {
        if (n <= 1) return false; // 0 and 1 are not prime
        if (n <= 3) return true;  // 2 and 3 are prime
        if (n % 2 == 0 || n % 3 == 0) return false; // eliminate multiples of 2 and 3

        // Only check up to √n using 6k ± 1 optimization
        for (int i = 5; i * i <= n; i += 6) {
            if (n % i == 0 || n % (i + 2) == 0)
                return false;
        }
        return true;
    }
}

As part of my recent decision to try and get solutions in at least 4 languages (Java, c# ,c++ and javascript),I attempted to achieve solutions in c#,c++ and javascript. I first tried c# and the following solution was accepted.

public class Solution {
    public int MinSteps(int n) {
     int []dp= new int[n+1];
      for(int i=2;i<n+1;i++){
       if(IsPrime(i))dp[i]=i;
       else dp[i] =dp[HighestDivisor(i)]+(i/HighestDivisor(i));        
      }  
      return dp[n];
    }

    public int HighestDivisor(int n) {
        if (n <= 1) return -1; // No proper divisor exists for 0 or 1

        for (int i = n / 2; i >= 1; i--) {
            if (n % i == 0) {
                return i; // First divisor found from the top is the highest
            }
        }
        return -1; // Should never reach here for n > 1
    }

    public  bool IsPrime(int n) {
        if (n <= 1) return false; // 0 and 1 are not prime
        if (n <= 3) return true;  // 2 and 3 are prime
        if (n % 2 == 0 || n % 3 == 0) return false; // eliminate multiples of 2 and 3

        // Only check up to √n using 6k ± 1 optimization
        for (int i = 5; i * i <= n; i += 6) {
            if (n % i == 0 || n % (i + 2) == 0)
                return false;
        }
        return true;
    }
}

I then attempted c++ and my solution was again accepted.

class Solution {
public:
    int minSteps(int n) {
      vector<int>dp;
      for(int i=0;i<n+1;i++)dp.push_back(0);
      for(int i=2;i<n+1;i++){
       if(isPrime(i))dp[i]=i;
       else dp[i] =dp[highestDivisor(i)]+(i/highestDivisor(i));        
      }  
      return dp[n];
    }

    int highestDivisor(int n) {
        if (n <= 1) return -1; // No proper divisor exists for 0 or 1

        for (int i = n / 2; i >= 1; i--) {
            if (n % i == 0) {
                return i; // First divisor found from the top is the highest
            }
        }
        return -1; // Should never reach here for n > 1
    }

    bool isPrime(int n) {
        if (n <= 1) return false; // 0 and 1 are not prime
        if (n <= 3) return true;  // 2 and 3 are prime
        if (n % 2 == 0 || n % 3 == 0) return false; // eliminate multiples of 2 and 3

        // Only check up to √n using 6k ± 1 optimization
        for (int i = 5; i * i <= n; i += 6) {
            if (n % i == 0 || n % (i + 2) == 0)
                return false;
        }
        return true;
    }
};

Feeling very proud, I decided to try in javascript, I tried the following but saw that it was rejected.

var minSteps = function(n) {
      const []dp;
      for(let i=2;i<n+1;i++){
       let highestDivisor=i;
       for(let j=i/2;j>1;j--){
        if(i%j==0){
          highestDivisor=j;
          break;  
        }
       } 
       if(highestDivisor==i)dp[i]=i; 
       else dp[i] =dp[highestDivisor]+(i/highestDivisor);        
      }  
      return dp[n];  
};

I got a runtime error and was flabbergasted. I decided to come back later and to first attempt an optimized java solution. I decided to come up with the following approach. Instead of determining if a number is prime to find the highest divisor. I used the following which was accepted.

class Solution {
    public int minSteps(int n) {
      int []dp= new int[n+1];
      for(int i=2;i<n+1;i++){
       if(isPrime(i))dp[i]=i;
       else {
        //System.out.println
        dp[i] =dp[highestDivisor(i)]+(i/highestDivisor(i));
       } 
      }  
      return dp[n];
    }

    public int highestDivisor(int n) {
        if (n <= 1) return -1; // No proper divisor exists for 0 or 1

        for (int i = n / 2; i >= 1; i--) {
            if (n % i == 0) {
                return i; // First divisor found from the top is the highest
            }
        }
        return -1; // Should never reach here for n > 1
    }

    public  boolean isPrime(int n) {
        if (n <= 1) return false; // 0 and 1 are not prime
        if (n <= 3) return true;  // 2 and 3 are prime
        if (n % 2 == 0 || n % 3 == 0) return false; // eliminate multiples of 2 and 3

        // Only check up to √n using 6k ± 1 optimization
        for (int i = 5; i * i <= n; i += 6) {
            if (n % i == 0 || n % (i + 2) == 0)
                return false;
        }
        return true;
    }
}

It was accepted and was slightly better than the original. I felt happy. I decided to retry the javascript solution. I attempted to debug using print statements and realized that j was initialized as 1.5.So,I made some changes. I used j=i-1 and reran and came up with this solution which was accepted!!! I felt I was on a roll!!!

var minSteps = function(n) {
      const dp=[];
      for(let i=0;i<n+1;i++)dp.push(0);
      for(let i=2;i<n+1;i++){
       let highestDivisor=i;
       for(let j=i-1;j>1;j--){
        if(i%j==0){
          highestDivisor=j;
          break;  
        }
       } 
       if(highestDivisor==i)dp[i]=i; 
       else dp[i] =dp[highestDivisor]+(i/highestDivisor);        
      }
      return dp[n];  
};

5. Lessons Learned

This experience has taught me/helped reinforce a number of lessons.
1) Fully understand the problem a program/coding challenge is trying to solve by careful reading, asking the necessary questions. A problem cant be solved if you have misunderstood or dont understand it.

2) Research how previous or similar problems were solved by other programmers.

3) Develop a first draft solution to the problem.

4) If stuck, take a break. Solutions can come when your mind is at rest.

5) Optimize your solutions where possible. It can save time and memory. In production environments, this can make a noticeable difference.

6) Different programming languages handle variables differently. Understand how.

7) Debugging with print statements is an unsophisticated but simple way to troubleshoot.

6. Wrap-Up

I hope my post has been helpful, please feel free to like,comment and share. Please check out my github profile for this and more solutions.It is here : https://github.com/HectorwTT