Coder Legion - Recent posts tagged leetcode

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);  
    }
};

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;
    }
}

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;
    }
}

I Froze on Iterative Postorder. The Fix Was Understanding the Stack

Thu, 28 May 2026 11:14:52 +0000

I had written recursive preorder, inorder, and postorder more times than I could count, three lines and a base case each. Then an onsite asked for postorder without recursion, and I blanked, pushing nodes onto a stack and popping them in the wrong order for a solid ten minutes. The traversal that had felt automatic fell apart the moment the stack became mine to manage.

What stung was realizing the recursion had been carrying a hidden stack the entire time. The frames were doing the work, and nobody ever made me look at them.

What finally clicked

The three recursive traversals were one walk, not three separate facts to memorize.
Recursion was quietly leaning on a stack the language managed the whole time.
Iterative postorder is the one that proves whether you understand that stack.
The order you choose is a data direction question, not a matter of taste.

Where the understanding was thin

Writing the recursive version of all three was automatic. Explaining what the call stack was doing while they ran was not, and that gap turned out to be the whole story.

I could trace the output by hand but not the machine producing it. So when the iterative version asked me to be the machine, there was nothing underneath the memorized shapes to stand on. The recursion had been doing the bookkeeping, and that was easy to mistake for understanding it.

What the recursion was doing for me

Every call on a child saves the current position and jumps in, then comes back when the child returns. That saved position is a stack frame. A recursive traversal is really a loop over a stack you never have to see, which is exactly why it feels effortless until you have to rebuild it.

Deep trees punish the hidden version. A chain of 10,000 left only children overflows the call stack in most languages. The iterative rewrite moves that work onto a list in heap memory, so the skewed tree that crashes recursion runs fine.

Rebuilding postorder by hand

Postorder is the hard conversion, because you reach a parent before its two children, but you have to process it after them. The cleanest way to hold that backwards is two stacks. The first produces a node, right, left order. The second reverses it into left, right, node, which is postorder.

def iterative_postorder(root):
    if not root:
        return
    stack1 = [root]
    stack2 = []
    while stack1:
        node = stack1.pop()
        stack2.append(node)
        if node.left:           # left first so right lands on top
            stack1.append(node.left)
        if node.right:
            stack1.append(node.right)
    while stack2:               # stack2 holds node, right, left
        process(stack2.pop())   # popping reverses it into postorder

Trace it on a tiny tree with root 1, left child 2, and right child 3. Postorder should read 2, 3, 1.

stack1: [1]                      stack2: []
pop 1 -> stack2: [1]             push 2, 3 -> stack1: [2, 3]
pop 3 -> stack2: [1, 3]          3 is a leaf
pop 2 -> stack2: [1, 3, 2]       2 is a leaf
drain stack2 by popping:         process 2, then 3, then 1

The output 2, 3, 1 is postorder. Watching the second stack get drained in reverse is the moment the whole thing stopped feeling like a trick.

Why the order was never the hard part

The last lesson took the longest to land. The problem was never the traversal. It was that the recursion got practiced and the stack underneath it got skipped.

Once that gap closed, picking an order got simple, because the order is decided by one question. Does the parent need answers from its children, or do the children need data from the parent? Height, diameter, and subtree sums need the children first, so they are postorder. Path sums hand data downward, so they are preorder. Sorted output from a BST is inorder. Work defined per level is level order with a queue instead of a stack. Which way the data had to move decided the order every time, with no preference involved.

That gap, between knowing the recursion and understanding the stack underneath, is what I kept circling back to, and it is a big part of why I built Codeintuition. The lesson that traces the stack frame by frame is the walkthrough I wish I had back then.

The habits that fixed it

Old habit	New habit
Memorize three recursive shapes as separate facts	Treat them as one walk with the visit line moved
Reach for recursion and hope the stack held	Manage the stack by hand when depth is a risk
Guess at iterative postorder under pressure	Build it from the two stack idea every time
Pick a traversal order by familiarity	Pick it by which way data moves, parent to child

If you are staring at the same wall, three things would have saved me a lot of time:

Learn the stack, not the three shapes. Once you read the recursion as a loop over a stack, preorder and inorder stop being separate things to memorize.
Write iterative postorder by hand before an interview forces you to. It is the one that exposes whether you understand the stack, since you meet the parent before its children and have to hold it back.
Decide the order by data direction. Ask whether the parent needs its children's answers or the children need the parent's data, and the order picks itself.

I put the longer version on my own blog, including the level order walkthrough and the full set of traces.

What's a traversal or algorithm you thought you knew cold until an interview asked for the version you had never written by hand?

I Solved 80 Tree Problems Before Binary Tree Recursion Clicked

Tue, 26 May 2026 16:09:31 +0000

I'd solved around 80 tree problems by the time my second on site interview wrapped up. Most were mediums. Preorder, inorder, postorder, level order felt like second nature. Tree height and BST validation, written from scratch, half a dozen times each. But the medium I'd just bombed had a stateful postorder shape I didn't see in the moment, and 20 of the 35 minutes went to patching the wrong recursion.

On the train home I traced the solution by hand. It clicked in 90 seconds. The problem wasn't tree knowledge. What was missing was the skill of predicting how a recursive function would flow through the call stack, frame by frame, before writing any code.

What changed for me

Mental simulation of the call stack is a separate skill from knowing traversal types.

The six tree patterns split cleanly along one axis: which direction information flows.

Stateful postorder problems look right at every node and wrong overall when you confuse the return value with the answer.

BST validation looks structurally fine and is logically broken when you check only direct children.

Practicing tree problems without simulating the call stack is what kept me stuck for months.

Where the recursion kept breaking

The approach had been treating tree problems the same way you'd treat array problems. Read the statement, sketch one small example, write code, test against the example, debug. On arrays that loop works fine because the traversal is linear and the bugs show up immediately. On trees the loop fails silently. The recursion executes, the values look plausible at every node, the test case passes on a small input, and a deeper tree from the interview question produces the wrong answer.

The symptom looked like a knowledge problem, so for a while the response was reading. Reread the postorder explanation. Try more medium problems. Next interview, freeze on something with the same shape. The reading wasn't the gap. The simulation skill was.

The fix turned out to be simpler than expected. Before writing any code for a tree problem, ask one question: which direction does information have to flow to get the answer? Down through parameters? Up through return values? Sideways with a queue?

That single question puts you into the right pattern category before you've written a line of code. It also forces you to predict what's going to happen on the call stack before running anything.

What I started doing differently

The protocol ran something like this. It was deliberately slower than the old read-and-code habit, and it was the part that closed the gap.

Read the problem. Sketch a small concrete tree on paper. Not the example from the problem statement, a tree you make up.
Ask the direction question. Does the answer for a node depend on what's above it, what's below it, or what's beside it?
Pick a pattern. Down means preorder. Up means postorder. Sideways means level order. Stateful versions of each split off by whether a global accumulator is involved.
Write one sentence describing what f(node) returns. If you can't write the sentence, you've misidentified the pattern.
Walk through the call stack on the sketched tree. Predict the order of recursive calls. Predict what each call returns. Note where global state changes if any.
Only then start coding.

The whole protocol took 5 minutes the first few times. It saved 20 in debugging. After running it on 30 problems, the first five steps collapsed into about 60 seconds of thinking before any code got written.

What that looked like on diameter

The first problem I ran this protocol on was tree diameter. The diameter of a binary tree is the longest path between any two nodes, measured in edges.

Sketch a small tree. Root with a left subtree of depth 2 and a right subtree of depth 3.

Direction question: does the diameter at the root depend on what's above it (impossible, it's the root), what's below it (yes, the depths of the subtrees), or sideways (no)?

Information flows up. Postorder.

Sentence describing what f(node) returns: the height of the subtree rooted at node. The diameter accumulates globally.

That last detail is where stateful postorder lives. The return value is the local thing the parent needs (subtree height). The actual answer is a global thing updated at each node (the maximum of left_height + right_height seen anywhere in the tree).

def diameter(root):
    longest = 0

    def height(node):
        nonlocal longest
        if not node:
            return 0
        left = height(node.left)
        right = height(node.right)
        longest = max(longest, left + right)
        return 1 + max(left, right)

    height(root)
    return longest

Walking the call stack:

height(left_child) runs first. Recurses down to the leaves, returns heights from the bottom up. At each node, updates longest with left + right.
height(right_child) runs next. Same behavior on the right subtree.
height(root) runs last. Gets left subtree's height (2) and right subtree's height (3). Updates longest with 2 + 3 = 5. Returns 1 + max(2, 3) = 4 (which is the tree's total height, not the answer).

The diameter is longest = 5. The return value of the top call is 4 (the height) and it isn't the answer. That separation between return value and answer is the entire pattern.

Earlier attempts at diameter kept trying to make the return value carry the answer directly. It doesn't work, because the diameter at a node combines information from two siblings, not from a single root-to-leaf path. The global accumulator is what handles that combination.

Why this works

The mechanism isn't deep, once you see it. Tree recursion is two recursive calls per node. The call stack pushes the parent frame, pushes the left child's call chain, pops back to the parent, pushes the right child's call chain, pops back to the parent. Two branches per frame.

What makes tree problems feel hard is that you have to predict this branching in your head before writing code. Once you can predict it, the choice between preorder, postorder, and level order falls out of the prediction itself. Down means the answer accumulates on the way down. Up means it accumulates on the way back. Sideways means the call stack is the wrong tool entirely and you should use a queue.

The maximum path sum lesson on Codeintuition was the one where this pattern finally became obvious to me, because it's stateful postorder with a meaner set of edge cases (negative values, single node paths, paths that pass through the root rather than ending at it). Watching the call stack trace through that problem frame by frame was what made the structure click for everything after it.

What I'd tell someone in the same spot

If you've solved 50+ tree problems and still freeze on unfamiliar ones, the gap is almost always the simulation skill, not the knowledge. More problems won't close it.

The shortest practice that helped me: take a tree problem you've solved before. Cover the solution. Sketch a small tree. Predict the order of recursive calls and what each call returns. Open the solution in a debugger and step through. Note where your prediction diverged from what actually happened.

Three rounds of that and the call stack stops feeling abstract. Five rounds and you can read a new tree problem, decide direction in 30 seconds, and start coding from a correct mental model.

Worth doing on every pattern category at least once. Stateless preorder. Stateless postorder. Stateful postorder. Root to leaf path. The BST inorder pattern. Level order with a queue. Once each of those patterns has a call stack trace burned into your head, the rest of the variants are small adaptations.

There's a longer version on my own blog that walks through the four BST-only patterns and the heap variants in more depth.

What's a tree problem that finally made the call stack visible to you in your head, where reading the textbook explanation hadn't? For me it was diameter. The protocol I built around it is what made every subsequent stateful postorder problem feel mechanical.

What 40 Binary Tree Problems Didn't Teach Me Before My FAANG Interview

Mon, 25 May 2026 12:09:46 +0000

The tree round on my first onsite was Root to Leaf Paths. Enumerate every root-to-leaf path in a binary tree. Looked easy. The recursion took about four minutes to write. Running it on the sample input came back with a list where every path ended at the leaf of the last branch the function had visited. The earlier paths had been contaminated. The interviewer watched the screen for two full minutes before the cause clicked: the shared list parameter never got cleaned up between recursive calls. That technique had shown up in practice twice before, but the conditions for when it was required had never internalised. What was missing was the framing that root-to-leaf problems are a class with their own boundary handling, separate from the other recursive tree patterns.

What changed afterwards:

Tree problems aren't a single skill. They are six distinct mechanisms (preorder, postorder, root to leaf, level order, LCA, simultaneous traversal), each with its own boundary cases.

Fifteen problems chosen by pattern coverage beat forty random problems sorted by acceptance rate.

The single biggest mistake on root-to-leaf problems is forgetting to backtrack the shared accumulator after each recursive call.

Practice in pattern order, not difficulty order. Each pattern's mechanism transfers to its variants but not to other patterns.

Where the tree prep was breaking

The grinding approach is what most onlines recommend. Open LeetCode's tree tag. Sort by acceptance rate or popularity. Work through the top forty. After about a week the easy ones feel reflexive, after two weeks the mediums start landing more often than not, and by week three the assumption is that tree rounds will be fine.

That assumption broke on the Root to Leaf Paths bug. The problem wasn't hard. It was a class of problem that had been practiced before. What was missing was the recognition that root-to-leaf is its own pattern with its own boundary behaviour, distinct from the postorder problems on the list and distinct from the preorder problems that felt most confident. Forty problems sat behind that interview, and there was no grouping that would have made the root-to-leaf class visible as a class.

The deeper diagnosis was this. What was missing wasn't more problems. It was the grouping that would let problem 1 in a class prepare a candidate for problem 2 in the same class. Forty problems organised by popularity give no transfer. Two problems per pattern, organised by mechanism, give coverage of every interview-grade tree question that's likely to show up.

What started working differently

The rebuild happened pattern by pattern. Each session, pick one of the six patterns. Work through the direct application first (the problem that teaches the mechanism cleanly). Then work through one variant (the problem that proves the mechanism transferred). Two problems per pattern, no more. If the mechanism hadn't clicked after problem two, the answer wasn't to add a third problem in the same pattern. The answer was to go back to problem one and trace it on paper until the mechanism became obvious from the structure of the recursion.

The change in approach looked like this:

Before (grinding random problems)	After (two per pattern, in pattern order)
Sort LeetCode tree tag by frequency, do top 40	Pick six patterns, do two problems each, in pattern dependency order
Treat each problem as a separate puzzle to solve	Treat each problem as an instance of one of six known mechanisms
Practice difficulty order (easy, then medium, then hard)	Practice pattern order, with the direct application before each variant
Recognise solutions you've already seen	Recognise which pattern a new problem needs, then derive the solution
Freeze on root-to-leaf backtracking under pressure	Walk into root-to-leaf knowing the path parameter is shared and needs cleanup

The key was that the six patterns gave the practice a vocabulary. Preorder. Postorder. Root to leaf. Level order. Lowest common ancestor. Simultaneous traversal. Every binary tree problem that came up, the first question became "which of the six is this?" That single question reorganised everything. Problems that previously felt random started feeling like instances of techniques already met.

What that looked like on the next problem

Three weeks into the rebuild, a friend ran a mock interview and the prompt was Root to Leaf Paths. The exact problem that had broken the onsite.

The framing was different this time. Root to leaf problems share a single accumulator (the path list) across all recursive branches. That sharing is what makes them fast (no per-call allocation), and it is what creates the bug if the accumulator doesn't get cleaned up after each child returns. Recognise the pattern first, write the recursion with the cleanup built in.

def root_to_leaf_paths(root):
    paths = []

    def walk(node, current):
        if node is None:
            return
        current.append(node.value)
        if node.left is None and node.right is None:
            paths.append(list(current))
        else:
            walk(node.left, current)
            walk(node.right, current)
        current.pop()

    walk(root, [])
    return paths

Two things to notice in the code. First, current is a single list that gets passed down through every recursive call. There's no copy at each call, which is what makes the algorithm O(n) plus the cost of producing the output. Second, the current.pop() at the end of walk is the cleanup. After the recursion returns from a child, the appended value gets removed so the sibling subtree sees the path as it was when the parent called it. Without that line, the bug from the original onsite shows up.

The mechanism transfers to the variant. Equal paths asks whether any root-to-leaf path sums to a target. Same skeleton (descend, accumulate, check at leaf, backtrack), different terminal check. Once root to leaf paths is solid, equal paths is a five-minute extension. The root to leaf paths lesson walks the backtracking explicitly, which is the part that gets glossed over in most textbook reading.

Why this works (pattern based practice)

The reason pattern grouping holds up under interview pressure has a name in learning science: near transfer versus far transfer. Practicing forty random problems builds a lot of near transfer skill (the ability to handle problems that look like the ones already practiced) and almost no far transfer (the ability to reliably handle a new problem with a slightly different surface).

Practicing two problems per pattern, in pattern order, inverts that ratio. The first problem teaches the mechanism. The second forces a variation that confirms the mechanism transferred, not the surface form. Past two problems per pattern, the marginal value drops fast, because the third is rehearsing the same mechanism with diminishing returns.

The six patterns also explain why difficulty order is the wrong sequencing. A medium postorder problem can be easier than a hard preorder problem, if postorder is already understood and preorder hadn't been met yet. Difficulty is a function of "has this mechanism been seen before?" not a function of the problem's intrinsic complexity. Pattern order respects that dependency. Postorder builds on preorder's recursive structure. Root to leaf reuses postorder's return mechanism plus the backtracking subtlety. Level order is a paradigm shift to a queue-based approach. LCA introduces multi node reasoning. Simultaneous traversal scales LCA's reasoning to two trees.

What I'd tell someone starting tree prep

If you're three weeks into tree practice and tree rounds still feel random, the shift to make is to stop grinding and start grouping.

A protocol that worked for the rebuild:

Before each session, name the pattern you'll practice (preorder, postorder, root to leaf, level order, LCA, or simultaneous traversal). Pick one. Don't mix patterns within a session.
Solve the direct application first (the problem that teaches the mechanism cleanly). For postorder, that's height of binary tree. For root to leaf, that's root to leaf paths. For LCA, that's the canonical lowest common ancestor problem.
Trace the solution on paper after writing it. If you can't narrate why each step preserves the mechanism, the mechanism hasn't clicked. Go back to the recursion and walk it variable by variable.
Solve the variant second. Diameter after height. Equal paths after root to leaf paths. Distance between nodes after LCA. If the variant feels like a fresh problem instead of an extension, the first problem hadn't internalised.
Move to the next pattern only after the current pattern's variant feels like a five-minute job. The transfer signal is "the pattern got recognised first, then the solution wrote itself," not "it took careful work to get there."

The protocol slowed things down at first. Two problems per session felt like less practice than four problems per session. The payoff was that the slower practice transferred. When the next mock interview surfaced a tree problem that hadn't been seen, the pattern recognition kicked in first and the recursion followed. That sequence was what was missing from the original forty-problem grind.

The grouping is what got built into Codeintuition's tree course, because watching engineers grind through forty problems with no transfer was the failure mode that kept showing up across every prep cohort. Pattern-first practice changed how trees felt to walk into, and the course now teaches the same restructure that made the difference.

Originally posted on my own blog, with the full fifteen-problem list grouped by pattern and a recursion-bug catalogue.

What's a tree problem that finally made a pattern click for you, where the textbook explanation hadn't?

What I Wish I'd Known About Binary Search Trees Before Interviews

Mon, 25 May 2026 09:11:56 +0000

Three months of practicing binary search trees on paper. Search procedure memorised. Insertion procedure memorised. Three deletion cases memorised. Then came the onsite. The interviewer drew a tree on the whiteboard, asked for an insertion walkthrough, and the recall worked fine. Then she asked for a deletion of a node with two children, and the freeze lasted almost a full minute before the inorder successor steps came out without any real understanding of why they preserved the ordering. She let the explanation finish, then asked one followup: why does the inorder successor specifically work? There was no answer beyond "because the textbook says so." That was the moment the gap became obvious. The months spent memorising procedures had skipped the part the interview was actually testing.

What changed afterwards:

BST search, insert, and delete are not three procedures. They are the same recursive walk with three different terminal conditions.

The two child deletion case is the one interviewers probe because it is the only case where the invariant has to be explained out loud.

Memorising the inorder successor trick doesn't transfer. Being able to say why the inorder successor specifically works does.

Once the invariant becomes the unit of memory, every operation that preserves it becomes derivable on the spot.

Where the approach was breaking

What had been getting practiced wasn't the data structure. It was a list of procedures the invariant could have handed over for free.

The recall pattern looked like this. Open a BST problem. Recognise it as a BST problem. Try to recall the right procedure for whatever the question asked. Search? Walk down comparing target to current. Insert? Same walk, create a leaf at the bottom. Delete? Three cases, pick the matching one, run the steps. The recall worked fine for problems that matched the textbook exactly. It fell apart the moment the problem deviated, because there was no deeper rule available to derive a new procedure from.

The specific failure on that first interview was treating the two child deletion case as a separate procedure rather than a question about the invariant. The procedure said "find the inorder successor, copy its value, delete the original successor." Those steps executed fine. What didn't execute was the reason behind them, which was the actual signal the interviewer was checking.

The gap is small in concept and load bearing in practice. If you can recite the steps but can't explain why each one preserves the rule, you will lose the thread whenever the interview adds a constraint that doesn't appear in the textbook version. And interviews almost always add a constraint.

What started working differently

After that interview, the practice rebuild was small in shape and large in effect. Instead of "memorise the procedure, then run it," the new approach was "start from the invariant, then derive what has to happen to preserve it." Same problems, same operations, completely different relationship to the material.

The contrast looked like this:

Before (procedure first)	After (invariant first)
Memorise search as a walk down comparing values	Start from `left < node < right` and derive the walk as the consequence
Memorise insert as "find null pointer, create leaf"	Notice that insert is the same walk, only the terminal action changes
Memorise three deletion cases	Ask "what value can sit in this slot without breaking the invariant?"
Recall the inorder successor as a step	Derive the inorder successor as the answer to the slot question
Stall on novel problems	Answer novel problems by reasoning forward from the rule

The shift was to remember fewer things, more carefully. There is exactly one rule for a BST: every node's left subtree contains only smaller values, every right subtree contains only larger values. Every operation either preserves the rule or is incorrect. That framing made the procedures fall out naturally, because the question "what do I do here?" reduced to "what action keeps the rule intact?"

What that looked like on the next problem

A month later came a phone screen at a different company. The interviewer gave a tree with [8, 3, 10, 1, 6, 14] and asked for a search for 6 and then an insertion of 7.

Search started at the root. 6 < 8, so go left to 3. Then 6 > 3, so go right to 6. Found it.

def search(node, target):
    if node is None or node.value == target:
        return node
    if target < node.value:
        return search(node.left, target)
    return search(node.right, target)

Then inserting 7 was the same walk. From the root, 7 < 8, go left. Then 7 > 3, go right to 6. Then 7 > 6, go right again. Right pointer is null. Create node 7 there.

def insert(node, value):
    if node is None:
        return Node(value)
    if value < node.value:
        node.left = insert(node.left, value)
    elif value > node.value:
        node.right = insert(node.right, value)
    return node

What was different this time was the framing said out loud after the code finished. Search and insert are the same recursive walk. Search stops when the value matches or the pointer is null. Insert stops at a null pointer and writes a new leaf there. The walk is what the invariant requires. The terminal action is the only thing that changes between operations. The interviewer asked a few more questions and then moved on. The framing was the part that mattered, not the code.

The same shift made deletion easier too. Instead of three cases, the new mental model was one question: what value can sit in this slot without breaking left < node < right? For a leaf, the answer is no value. Drop the pointer. For a one child node, the answer is the child's value, because the child's subtree already satisfies the invariant against the parent. For a two child node, the answer is the smallest value larger than the deleted node (the inorder successor), which is what the slot requires after deletion. Three procedures collapsed into three answers to the same question.

Why this works (the invariant doing the heavy lifting)

The reason the invariant first framing holds up under interview pressure has a name in learning science: near transfer versus far transfer. Memorising a procedure builds a near transfer skill. The procedure applies to problems that look exactly like the one that got practiced. It doesn't apply to problems that look slightly different, because the procedure is tied to the specific form of the original.

Deriving a procedure from a rule builds a far transfer skill. The rule applies to any problem that respects the rule, regardless of how the form changes. The rule is what generalises. The procedure is what gets generated for the specific case.

BSTs make this concrete because there is exactly one rule and there are dozens of variant problems that ask you to apply it. BST validation. Conversion to sorted array. Conversion to sorted doubly linked list. Range queries. Kth smallest element. Lowest common ancestor in a BST. BST iterator. All derivable from "left subtree smaller, right subtree larger." None easy to memorise as individual procedures, because there are too many of them and they shade into each other.

The inorder successor lesson walks the two child deletion case from the invariant down, which is the framing that most first practice resources skip. The procedure becomes the easy part once the question is framed as "what value belongs in this slot?"

What I'd tell someone in the same spot

If your BST practice is at the point where the procedures feel memorised but the mock interviews aren't going well, the shift to make is to stop quizzing yourself on the steps and start quizzing yourself on the rule.

A practice protocol that worked for the rebuild:

Before solving any BST problem, write the invariant at the top of the page. left < node < right for every node, applied recursively to every subtree. Look at it for ten seconds.
Read the problem and ask: what action does the invariant require here? Not "what procedure do I run." What does the rule say has to happen.
Trace one example by hand on paper, narrating each step as "this preserves the rule because..." If that sentence won't finish, what's running is a memorised procedure, not a derivation from the rule.
Code it up. If the code falls out naturally from the narration, you have it. If a procedure shows up that you can't justify, stop and go back to step 2.

The protocol slows things down at first. Adding a thirty second pause to write the invariant and narrate the reasoning feels expensive under time pressure. The payoff is that the slow practice transfers. When the interview adds a constraint, the procedure that would have been recalled is wrong, but the rule still applies and the new procedure derives in real time.

That gap, between solving a BST problem and recognising why an operation works, is the thing that pushed me to build Codeintuition. Watching engineers grind through hundreds of tree problems without the invariant first framing was the pattern that wouldn't stop showing up. The tree courses now lead with the rule and let the procedures fall out, which is the ordering that would have saved months on the first attempt.

Originally posted on my own blog, a slightly longer version with the inorder traversal proof and the balanced construction algorithm.

What is a data structure that started making sense for you only after you stopped memorising the operations and started re-deriving them from the rule?

Big O Notation: What I Wish I'd Known Before My First Interview

Sat, 23 May 2026 11:29:05 +0000

The Big O table was memorised before the first onsite. Binary search logarithmic, merge sort linearithmic, hash insert constant amortised. All recitable. Then a senior engineer wrote a recursive function on the whiteboard, asked for an analysis, and almost a minute went by trying to match what was on the board to something on the cached table. The function was a naive recursive Fibonacci, seen before, implemented before. The freeze still happened, because nothing about the table told anyone how to count the recursive calls.

What I figured out afterwards

The table is the answer, not the method. Memorising it never builds the ability to derive complexity from code you haven't seen.
The thing the table hides is the counting. How many times the dominant operation runs as a function of input size.
Once four or five derivations have been traced by hand, the shape generalises. Unfamiliar code stops feeling opaque.
Space complexity has the same derivation shape, plus the call stack that's easy to forget.
The drill that actually builds the skill is deriving complexity on problems whose answer you don't already know.

Where the approach was breaking

The Fibonacci moment exposed the gap. The function had been seen. The function had been implemented. What hadn't happened was counting what the recursion actually does.

def fib(n):
    if n < 2:
        return n
    return fib(n - 1) + fib(n - 2)

The interviewer was patient. "How many calls does fib(5) make?" The whiteboard got a tree. fib(5) calls fib(4) and fib(3). fib(4) calls fib(3) and fib(2). fib(3) shows up twice. fib(2) shows up three times. The tree grew faster than the page it was being drawn on. The answer wasn't in cached memory because no one had asked for the count before. The answer is O(2ⁿ), roughly, and the reason is that each call branches into two and the depth is about n.

Big O had been treated as a label to attach after solving. The interview was treating it as a derivation to perform on unfamiliar code. Those are different skills, and the wrong one had been practiced.

What started working differently

The fix wasn't reading more articles. It was changing the drill. The new prompt was "given this code you haven't seen before, what's the complexity, and how would you justify it" instead of "what's the complexity of merge sort." Once the prompt changed, the way unfamiliar code reads changed with it.

Here's the shape that worked, side by side with the old habit:

Then	Now
Match the code to a memorised complexity.	Identify the dominant operation, the one that runs most.
Look up the answer when the match wasn't obvious.	Count how many times that operation runs, as a function of `n`.
Move on once a label was attached.	Sum the work across levels (loops, recursion depth, branching factor).
Forget about space until reminded.	Track space the same way: auxiliary memory plus the call stack.

The change is a habit, not a piece of knowledge. The Big O table doesn't get more correct over time. The way unfamiliar code gets read does.

What that looked like on the next problem

A few weeks after the Fibonacci interview, the same function came back out for re-derivation from scratch. No looking up the answer. Just the dominant operation and counting.

The dominant operation in fib(n) is the recursive call. fib(n) calls fib(n-1) and fib(n-2). Treat both as roughly fib(n-1) for the upper bound. So the call count T(n) ≈ 2 × T(n-1). That recurrence solves to T(n) = 2ⁿ. The depth of the tree is about n. The branching factor is 2. Total work is roughly the number of nodes in a binary tree of depth n, which is 2ⁿ.

That's why naive Fibonacci is unusably slow even at moderate n. fib(40) makes more than a billion calls.

Adding memoisation changes the shape entirely:

def fib(n, memo={}):
    if n in memo:
        return memo[n]
    if n < 2:
        return n
    memo[n] = fib(n - 1, memo) + fib(n - 2, memo)
    return memo[n]

Now each subproblem fib(k) for k from 0 to n is computed exactly once. There are n distinct subproblems. Each one does constant work after its two subcalls return. Total: O(n) time, O(n) space from the memo plus the call stack.

The complexity went from O(2ⁿ) to O(n) because the structure of the work changed, and the derivation made that visible in a way the table never did. (For the longer walkthrough of how memoisation becomes the gateway to dynamic programming, the DP interview blog covers the recurrence-to-table-to-bottom-up progression.)

Why this works (the science behind it)

The learning science term for the swapped drill is elaborative interrogation. Asking yourself why each operation contributes the work it does, rather than accepting the labelled answer at face value. The literature on it is consistent: forcing yourself to construct the reason produces a more durable, more transferable understanding than reading the reason already constructed.

The other piece is near transfer versus far transfer. The old drill was near transfer practice (the same complexity question on the same code already memorised). The interview was a far transfer test (different code, same skill). Near transfer practice doesn't reliably move far transfer scores. Once that lands, the right drill picks itself: derive complexity on code you haven't seen.

What to tell someone in the same spot

Three things, in the order they mattered.

Stop quizzing yourself on named algorithms. "What's the complexity of merge sort" trains memory, not derivation. Quiz yourself on an unfamiliar function instead, and force yourself to count the dominant operation explicitly. If you have to count it out loud, that's the right intensity.
Trace at least one recursive call tree by hand per week. The first few feel slow. The fifth or sixth is where the shape generalises. Branching factor times depth gives nodes, nodes times work-per-node gives total work. The arithmetic is the same on every problem.
Track space the same way you track time. Auxiliary memory plus call-stack frames. Most engineers in interviews get time right and space wrong, and the difference is purely habit.

Before this shift, a solution would read as that looks fast and the analysis would stop there. After, the same solution reads as O(n log n) because the divide step and the merge step can be pointed at independently. Adding a hash map to a nested loop visibly drops the complexity from quadratic to linear, with the derivation right there in the code. Unfamiliar code becomes analysable because the analysis is something you do, not something you recall.

Originally posted on my own blog, with the amortised analysis derivation for hash-map resize and the space-complexity traps skipped over in this retrospective.

What's a piece of complexity analysis that finally clicked for you only after deriving it by hand, where the textbook label had never really stuck?

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?

Backtracking Finally Clicked When I Fixed One Habit

Thu, 21 May 2026 16:14:14 +0000

For a long stretch, backtracking was the topic I quietly dreaded. The recursion was easy enough to write. The code ran. It even returned answers. They were just wrong, and not in a way that threw an error you could chase. A Combination Sum solution would spit out duplicate-looking results with no obvious culprit line. The fix, when it came, had nothing to do with understanding recursion better. It was one habit that kept getting skipped.

Here's what changed once backtracking stopped being a clever trick and became a fixed loop.

What changed

Backtracking is a depth first walk over a state space tree, and the tree is the part worth drawing first.
The loop is always the same: choose an option, check the constraint, undo the choice on the way back up.
The undo step is the easiest to drop, and dropping it silently corrupts later branches.
Pruning before you recurse, not after you reach a leaf, is where the speed lives.
Once the same partial state repeats across branches, the whole thing becomes top down DP.

Where my backtracking kept breaking

The mistake was always the same, and naming it took embarrassingly long. You build a partial solution by mutating a shared list, recurse, then move on to the next option without ever putting the list back the way you found it. So branch two starts with branch one's leftovers still inside it.

What broke wasn't the recursion. It was that the path never got restored on the way back up.

The reason it's so hard to catch: nothing crashes. A forgotten undo doesn't raise an exception. It quietly hands stale state to the next branch, and the answers look plausible until you check them by hand. That single omission costs more debugging time than any actual algorithmic concept.

Picture it concretely on a small Combination Sum case, candidates [2, 3] and target 5. The first branch explores [2, 2, ...], overshoots, and returns. If that branch left a stray 2 in the shared list, the next branch starts from [2] when it should start from []. Now the [3, ...] branch is really exploring [2, 3, ...], and the result set fills with combinations that were never asked for. Reading the function top to bottom, every line looks reasonable. The bug only shows up when you trace the shared list across two sibling branches and notice it isn't the same length going in as coming out.

What I started doing differently

The shift was to stop writing backtracking freehand and write the same three line frame every time, then fill it in. Choose, check, undo, in that order, with the undo non negotiable. Here's the before and after, once it became a fixed habit:

Then	Now
Recursion written ad hoc, undo when remembered	Choose, check, undo written as a fixed frame first
Constraints checked at the leaf	Constraint checked before recursing, so dead branches die early
Debugged by re-reading the whole function	Trace one branch, confirm state is restored after the call
Each problem treated as new	Slot the problem into one of three known shapes

The "check before recurse" row mattered more than expected. Pruning at the leaf still gives correct answers, it's just slow, and on a tight time limit slow is the same as failing.

What that looked like on Combination Sum

Combination Sum is the problem that finally made it click for me. Given a list of candidates and a target, find every combination that sums to the target, where a number can be reused. It's a conditional enumeration problem, so you prune any branch whose running sum overshoots.

Here's the frame, filled in:

def combination_sum(candidates, target):
    result = []

    def backtrack(start, path, remaining):
        if remaining == 0:
            result.append(path[:])      # finished combination
            return
        if remaining < 0:
            return                      # overshot, prune this branch
        for i in range(start, len(candidates)):
            path.append(candidates[i])                       # choose
            backtrack(i, path, remaining - candidates[i])    # explore (reuse allowed)
            path.pop()                                       # undo

    backtrack(0, [], target)
    return result

The line that used to go missing is path.pop(). Without it, every combination after the first carries elements from the previous one. The path[:] matters too, it copies the list into the result instead of storing a reference that later pop calls would mutate out from under you. Two small lines, and they're the entire difference between a function that works and one that lies to you.

The start index is the other quiet detail. Passing i rather than i + 1 into the recursive call is what allows a number to be reused. Pass i + 1 and you've written a different problem, combinations without repetition. Same frame, one parameter changes the meaning.

Why undoing state is the whole game

With the frame in hand, the three problem shapes read as one idea seen from different angles:

Unconditional enumeration, like all subsets, has no constraint, so you walk the whole tree and every node is an answer.
Conditional enumeration, like Combination Sum or valid parentheses, prunes branches that break a rule mid build.
Backtracking search, like N-Queens or Sudoku, looks for configurations under a global constraint and prunes hardest.

All three run the same choose, check, undo loop. The undo is what lets one mutable structure stand in for every node of the tree without the nodes contaminating each other. That's the thing I ended up rebuilding my own approach around.

It also reframes how the three shapes relate. They aren't three separate algorithms to learn. They're one loop with the constraint check dialled from off (subsets) to mid build (Combination Sum) to every level (N-Queens). Seeing them as one thing meant a new problem stopped being a blank page. The question became which shape it was and what the constraint was, and the frame handled the rest.

What I'd tell someone stuck on this

If you're losing time to backtracking that returns wrong answers, the fix is almost never more practice on harder problems. Grinding ten more search problems with the same blind spot just produces ten more silently wrong solutions. The thing standing between you and reliable backtracking is usually one missing line, not a missing concept. It's two habits. First, write the undo line at the same moment you write the choose line, as a pair, before anything else in the loop. Second, trace one full branch on paper and confirm the shared state looks identical before and after the recursive call.

And if the recursion itself still feels unstable underneath all this, that's worth shoring up first, because backtracking is just recursion with the choose, check, undo wrapper on top. Going back through the recursion lessons before touching backtracking again is what makes the wrapper feel mechanical instead of magical.

I originally posted this on my own blog, a slightly longer version with the N-Queens trace and a few more worked examples.

What's a bug that taught you more than the algorithm itself? For a lot of people backtracking is the one where a missing undo quietly breaks everything.

AVL Trees Explained: The Rotation Patterns Most People Memorise Wrong

Wed, 20 May 2026 19:57:13 +0000

The first time an interviewer asked me to walk through an LR rotation on a whiteboard, the four-case table was memorised cold. LL, RR, LR, RL. The interviewer drew three nodes, asked which case it was, and the answer came out fast. Then they asked: "predict what a single right rotation would do to that tree, and tell me why it fails." That part hadn't been drilled. The grade went out as "knows the table, didn't internalise the invariant."

What I figured out

The four rotation cases are not four things. They're two atomic moves applied once or twice.
The balance factor is the rule being protected, not a check. Every rotation is a local repair on the rule |left_height - right_height| <= 1.
Insertion needs at most one rotation. Deletion can need O(log n). That asymmetry is the answer to every "what's the tradeoff" question.
The double-rotation cases exist because a single rotation on an "inside" imbalance shifts the heavy side without reducing the depth.
Knowing the two atomic moves is enough to derive both LR and RL cases. Memorising the table on top is the wrong study target.

Where my approach was breaking

Three failure modes showed up on those rounds, and they show up in most engineers preparing for the same kind of question.

The four-case table got memorised without anyone tracing why each fix works. The table is a lookup. Interviewers test for the derivation. When a tree shows up on the board and the question is "what's the imbalance shape here," pattern matching against a remembered picture fails when the tree is rotated or relabelled.

Insertion got drilled, deletion didn't. Insertion is the cleaner operation. Almost every textbook walks insertion. Few walk deletion with the upward rebalance loop. Knowing "deletion is harder" as a phrase is not the same as knowing what concretely makes it harder.

Wrong rotations never got sketched. When an interviewer asks "what happens if you apply a single right rotation to an LR case," the answer has to come from a drawing, not a memory. Engineers who've never traced a failed rotation can't answer this on the spot.

What I started doing differently

Then	Now
Memorise LL / RR / LR / RL as four rotations	Internalise two atomic rotations and derive the four cases from balance factor signs
Practice insertion only	Practice deletion with the upward loop, including the worst-case `O(log n)` rotation chain
Treat balance factor as a check	Treat balance factor as the invariant being protected, with rotations as the local repair
Draw rotated trees from memory	Draw the pointer assignments explicitly and recompute heights before moving on
Skip wrong-rotation traces	Sketch what each wrong rotation does on an LR case, so the trap is recognisable under pressure

The "now" column is what interviewers actually probe. The "then" column is what most prep material asks you to drill.

The first rule that locks in is this. If you see a node with balance factor +2, the next look is at the left child's balance factor, not at the rotation table. If the left child is +1 or 0, single right rotate the parent. If the left child is -1, left rotate the left child first, then right rotate the parent. The decision is two questions, not a memorised table.

What that looked like on the next problem

Six months later, a different round asked for AVL insertion implementation. The sequence used to motivate the walk-through was [5, 3, 4], which fires an LR rotation. Here's the primitive:

def right_rotate(z):
    y = z.left
    T3 = y.right
    y.right = z
    z.left = T3
    z.height = 1 + max(height(z.left), height(z.right))
    y.height = 1 + max(height(y.left), height(y.right))
    return y

And the insertion function:

def insert(node, key):
    if not node:
        return Node(key)
    if key < node.key:
        node.left = insert(node.left, key)
    else:
        node.right = insert(node.right, key)

    node.height = 1 + max(height(node.left), height(node.right))
    bf = balance_factor(node)

    if bf > 1 and key < node.left.key:
        return right_rotate(node)
    if bf < -1 and key > node.right.key:
        return left_rotate(node)
    if bf > 1 and key > node.left.key:
        node.left = left_rotate(node.left)
        return right_rotate(node)
    if bf < -1 and key < node.right.key:
        node.right = right_rotate(node.right)
        return left_rotate(node)

    return node

Tracing [5, 3, 4]:

Insert 5. Single node, balance factor 0.
Insert 3. Goes left of 5. Node 5's balance factor is +1. Within the rule.
Insert 4. 4 < 5, go left. 4 > 3, go right of 3. Node 4 lands as 3's right child.

Walking back up: node 4 is balance factor 0, node 3 is -1, node 5 is +2. Rule broken at node 5, with its left child right-heavy. That's LR.

First rotation: left rotation on node 3. Node 4 moves up, node 3 becomes 4's left child. Node 5 still has balance factor +2, but its left subtree is now left-heavy. That's LL.

Second rotation: right rotation on node 5. Node 4 becomes the root, node 3 is 4's left child, node 5 is 4's right child. All balance factors back to 0. Height is 1.

The interviewer asked what a single right rotation would have done to the original tree. Sketched it out: node 3 becomes the root, node 5 is 3's right child, but node 4 ends up as 3's right child too, with node 5 displaced. The tree depth does not decrease. That's why the double rotation exists.

Why this works (the height theory behind it)

The choice of ±1 as the balance factor cap is not arbitrary. It's the tightest constraint that's still cheap to maintain locally.

An AVL tree with n nodes has height at most about 1.44 * log2(n). For a million nodes that's roughly 29 levels. A perfectly balanced tree would be 20 levels. The constant factor is small enough that you get the lookup speed of a balanced tree without paying the cost of full rebalancing on every insert.

Red-Black trees relax the constraint to allow heights up to about 2 log(n). That's roughly 40 levels for a million nodes. In exchange, at most 2 rotations per insertion or deletion. Looser balance, fewer rotations, faster writes.

When Adelson-Velsky and Landis named the AVL tree in 1962, the workload they had in mind was read-heavy. Lookups dominated. The strict balance was worth the rebalancing cost because every lookup was faster. Modern systems insert and delete more than they search-only, which is why Java's TreeMap, C++'s std::map, and Linux's CFS process scheduler all picked Red-Black instead. Different workload, different tradeoff. Neither tree is "better."

That's the answer the OS interviewer was looking for. AVL is read-optimised. Red-Black is tuned for mixed workloads. Picking between them is a workload question, not a theory question.

What I'd tell someone in the same spot

Three things to drill before either interview round:

Master the two atomic moves. Write left_rotate and right_rotate from memory, with the height updates in the right order. Three pointer reassignments, two height updates. Everything else builds on these.
Trace deletion at least three times. Pick at least one trace where the rebalance propagates two levels up. That's the answer to every "what's the tradeoff of stricter balance" question.
Sketch what a wrong rotation does on an LR case. Once you've drawn the broken tree, the LR / RL trap stops being a memory test.

Codeintuition's Binary Search Tree course is structured this way. The balance invariant comes before the rotation code, and the rotation code comes before the four-case table. Doing it in that order is what made the table feel mechanical instead of memorised.

I originally posted this on my own blog, a slightly longer version with the worked example for the original [3, 2, 1, 4, 5] insertion sequence and the AVL vs Red-Black tradeoff matrix.

What's the AVL or rotation question that finally made the rule click for you, where the textbook explanation had not?

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?

What Amazon’s Bar Raiser Actually Tests in Coding Interviews

Mon, 11 May 2026 14:47:38 +0000

I thought solving the problem was the round. The last ten minutes turned out to be the part that counted.

I'd put close to four months into Amazon prep by the time my onsite landed. Two coding rounds went fine. The third started fine too.

I solved the initial problem in about twenty minutes, walked through the test cases, and felt the round was already mostly won.

Then the interviewer asked one follow up.

The constraint they changed was small, the kind of thing I'd have called "minor" if I'd been describing it on paper.

It exposed that I'd been preparing for the wrong half of the round, and I spent the next ten minutes recovering ground I should never have lost.

That round was a Bar Raiser round.

I didn't know it at the time (Amazon doesn't tell you), but the debrief came back with the kind of feedback only the Bar Raiser writes:

"Strong initial solution, struggled to adapt under constraint change, did not demonstrate the structural reasoning we look for."

The phrasing is almost word for word from how Bar Raisers grade.

The follow up after the working solution is the round.

What I figured out

The Bar Raiser is one of the four or five interviewers on the loop, but you won't know which one. Treat every round as if it's them.
Amazon's pattern coverage is wider than Google's or Meta's, so going deep on three families isn't enough.
The grade often lives in the last ten minutes after your first working solution, not in the first solution itself.
Adapting after a constraint flip is a specific skill that grinding more problems doesn't build.
The fix is interleaved practice plus an explicit constraint flip rep on every problem.

Where my approach was breaking

My prep model was the standard FAANG one.

Pick the two or three pattern families that show up most for the company. Go deep on those. Time myself on company tagged problems. Repeat until recall got fast.

For Google that worked well enough.

Google leans heavily on predicate search, counting, and graph traversal. If you're solid on those three, the round usually lands in your zone. I'd interviewed at Google with that exact prep and it had been fine.

Amazon's pattern set is wider.

Across the problems Amazon actually tests, you'll see:

counting
fixed and variable sliding window
prefix sum
LRU-style design
randomized set design
plain binary search
2D and staircase binary search variants
queue design
backtracking

That's roughly eleven distinct families against Google's seven or eight.

The depth strategy that worked for Google had a worse hit rate at Amazon, and on the round that turned into the Bar Raiser slot, the problem landed in a family I'd given less time to.

The deeper issue was something the wider pattern coverage just made more visible.

Even on patterns I had practised, my fluency was template recall, not invariant construction.

As long as the problem looked enough like a textbook example, I produced the standard solution quickly.

The moment the constraint shifted, I tried to retrieve a different template instead of modifying the one I had.

The Bar Raiser format is built to expose that gap.

The follow up after the working solution is the round.

What I started doing differently

After the rejection landed, I went back through every coding round I'd done in mock interviews, including the ones I'd thought went well.

Two patterns showed up across roughly half of them:

I'd produced a correct solution within the time budget, but I couldn't have explained which invariant the data structure I picked was maintaining. The hash map worked. I couldn't have said cleanly what would break if I'd used an array instead.
When the mock interviewer changed a constraint at the end (which the better mocks always did), I either started from scratch or stalled. I almost never reached for the original solution and asked which part of it depended on the constraint that had moved.

Both were habits I'd built by drilling for speed against template problems.

Neither was a coding skill I lacked.

They were prep habits.

I shifted two things.

First, every problem I solved got a constraint flip rep.

Whatever the original constraint was, I changed one piece of it and reimplemented.

Second, I started reading my old solutions out loud as if explaining them to an interviewer, naming the invariant the structure maintained on every line.

The first felt like more work for the same problem count.

The second felt like wasted time.

Both turned out to be the gap.

Here's what changed in practice:

What I used to do	What I started doing
Solve the problem, check the answer, move on	Solve the problem, then write down the constraint change that would invalidate the solution most
Drill problems within one pattern family per week	Rotate between three or four pattern families inside a single session
Recall the optimal solution before writing any code	Get a correct `O(n²)` working first, confirm edge cases, then improve
Treat the follow up question in mocks as a bonus	Treat the follow up as the main rep
Explain the solution by walking through the code	Explain the solution by naming the invariant first

What that looked like on the next Word Search follow up

A few weeks later I ran a mock that landed on Word Search.

Standard backtracking on a grid:

Given a board of characters and a target word, return whether the word can be formed by a path of adjacent cells, with no cell reused.

The solution is a depth first search from each starting cell with a visited mark.

def exist(board, word):
    rows, cols = len(board), len(board[0])

    def dfs(r, c, idx):
        if idx == len(word):
            return True
        if r < 0 or r >= rows or c < 0 or c >= cols:
            return False
        if board[r][c] != word[idx]:
            return False

        tmp = board[r][c]
        board[r][c] = '#'

        found = (
            dfs(r+1, c, idx+1)
            or dfs(r-1, c, idx+1)
            or dfs(r, c+1, idx+1)
            or dfs(r, c-1, idx+1)
        )

        board[r][c] = tmp
        return found

    for r in range(rows):
        for c in range(cols):
            if dfs(r, c, 0):
                return True

    return False

The invariant the in-place marking maintains:

At any point in the recursion, the cells along the current path are marked #, every other cell is restored.

Backtracking by restoring on the way out keeps the invariant true at depth zero, which is what makes:

“No cell reused along this path”

hold.

Then came the follow up.

Instead of a single word, you now have a list of k words to find on the same board.

Same constraint.

No cell reused along a single word's path.

The old me would've started writing:

for w in words:
    exist(board, w)

taken the cost of:

O(k * rows * cols * 4^L)

and gone home.

The interviewer would've asked the obvious question:

“Can you do better than the naive loop?”

Which is exactly what had happened in the real round.

This time I asked a different question first:

Which part of the original solution depended on the constraint that just changed?

The DFS was doing the same prefix walk repeatedly for every word sharing a prefix.

So instead of changing the traversal:

Change what the traversal checks against.

Compose the DFS with a trie of all k words.

Every board walk now checks against all words simultaneously.

The invariant doesn't change.

The base case changes.

The grid traversal stays.

The constraint changed.

Not the structure.

def find_words(board, words):
    root = build_trie(words)
    rows, cols = len(board), len(board[0])
    found = set()

    def dfs(r, c, node):
        ch = board[r][c]

        if ch == '#' or ch not in node.children:
            return

        nxt = node.children[ch]

        if nxt.word:
            found.add(nxt.word)
            nxt.word = None

        board[r][c] = '#'

        for dr, dc in ((1,0), (-1,0), (0,1), (0,-1)):
            nr, nc = r + dr, c + dc

            if 0 <= nr < rows and 0 <= nc < cols:
                dfs(nr, nc, nxt)

        board[r][c] = ch

    for r in range(rows):
        for c in range(cols):
            dfs(r, c, root)

    return list(found)

I got there in roughly four minutes.

Not because I'd drilled Word Search II as a separate template.

Because I'd been practising one question repeatedly:

Which part of the original depended on the constraint that changed?

The change was in what the DFS checked.

Not in the DFS itself.

Why interleaving works for breadth

The other half of the gap was simply pattern coverage.

Three families deep wasn't enough for Amazon's surface area.

But I also couldn't realistically go equally deep on eleven families in the time I had left.

What I could do was rotate between them.

Research on interleaved practice consistently shows that mixing problem types improves your ability to identify which pattern applies to a new problem.

Mixed practice feels harder.

Blocked practice feels easier.

That's exactly why it works.

Blocked practice gives you:

“This week is sliding window.”

The Bar Raiser gives you:

“Figure out what this is.”

The added friction during practice was the same identification work the round required.

Practically, that meant:

A session of four problems became:

four different families

not:

four sliding window problems.

What I'd tell someone in the same spot

A few rules I wish I'd had four months earlier.

1. Get a working solution before chasing the optimal one

Twenty-five minutes thinking before writing leaves no room for the follow up.

A correct O(n²) solution that gets improved beats a half-written O(n) attempt every time.

2. Treat the follow up as the round

When the interviewer changes a constraint:

Ask which part of your solution depended on that constraint.

Modify only that part.

The instinct to redesign from zero is expensive.

3. Practise the constraint flip explicitly

Every problem gets a second pass with one constraint changed.

Implement the modified version.

That rep builds adaptation.

And adaptation is what the round grades.

If someone had explicitly taught me how to identify which part of a solution depends on a changing constraint, it would've shortened the loop considerably. The closest thing to the work I had to build for myself later was a pattern-identification lesson I eventually added inside Codeintuition.

I originally posted a longer version on my own blog with the per-pattern breakdown across all eleven families and how the rest of Amazon's interview loop factors into the Bar Raiser grade.

What’s a constraint flip from an interview that exposed a solution you thought you understood?

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?

How to Recognize Which Algorithm a Coding Interview Problem Needs

Thu, 07 May 2026 12:47:24 +0000

I'd solved around 300 problems by the time my third senior screen wrapped up. The medium that had just bombed the call was something I could explain back to myself in 90 seconds once it ended. The constraints were familiar. The technique was one anyone with my problem count had implemented before. The thing that wouldn't fire, in the moment, was the connection between the constraints and the technique.

The instinct, when that happens, is to grind more problems. That instinct cost me about two months. The thing that actually moved the needle was something else.

What I figured out

Volume practice was building memory of specific problems. It wasn't building the skill that recognises which technique applies to a problem you haven't seen before.
The default LeetCode loop trains around recognition, not at it. Reading the tag before attempting skips the part of the work that interviews actually test.
The fix is small and unglamorous. Read the problem for two or three observable features before any code. Name the technique. Then code.
Conditions matter as much as content. The LeetCode UI is friendlier than any phone screen, and it takes conscious effort to practise under conditions that resemble the real thing.

Quick disclosure before I get into this: I built Codeintuition, a structured learning platform for coding interviews. The story above is the version of this realisation that keeps showing up across engineers prepping for senior screens, almost verbatim. The closing link goes to the longer version on my own blog.

Where the approach was breaking

For most of the prep arc, every stuck problem got handled the same way. Attempt for fifteen or twenty minutes, hit a wall, glance at the tag, read a solution, move on. The progression chart said the weekly count was climbing. The interview chart said the bar wasn't moving.

Tracing what was actually being learned per problem made the picture clearer. The implementation got learned each time. The shape of the solution got learned. What didn't get learned was the answer to a question nobody was asking: why is this problem the kind of problem that takes this technique? The tag and the solution skipped that step every single time.

In a real interview, the tag is gone. So the thing that came for free in practice (which technique to use) becomes the thing the candidate has to figure out from scratch under a clock. The freeze makes sense in retrospect. Nothing in the practice loop had trained for it.

What started working

The shift was small. Before opening the editor, the rule was: spend 30 to 60 seconds reading just the problem statement, trying to name the technique and the reasons. No code, no guessing. The output of the pass is a sentence: "this is a [technique] problem because [feature one], [feature two], [feature three]." If you can't write that sentence, you don't start coding. Go back to the constraints with a checklist of features for each technique and try again.

Concretely:

What used to happen	What started happening
Open problem, attempt for 20 minutes, glance at tag if stuck	Read constraints first, name the technique in 60 seconds, only then attempt
Read solutions to learn the implementation	Read solutions only after attempting, and look for which features in the statement point at the technique
Practise one technique in batches (15 sliding window problems back-to-back)	Mix techniques in each session so the constraints had to be read before knowing what to use
Practise with the title and difficulty visible	Cover the title with a sticky note, ignore the difficulty tag

The first time, this protocol feels slow. The second week, it feels slow but useful. By the fourth week, the features start firing on their own as the problem statement is read.

What that looked like on the next problem

The problem that finally landed for me was Longest Increasing Subsequence. The O(n^2) version was familiar. The patience-sorting O(n log n) version was familiar too. What wasn't trustworthy was the read of when LIS was the right tool versus when something else was.

The session with the new approach started with the constraints. Three features fell out:

A single sequence, not two. That ruled out edit-distance-family techniques right away.
The optimisation target was the length of an ordered subsequence. Order of the original sequence had to be preserved.
The transition between elements was a comparison, not a sum or a count. "Strictly greater than the previous kept element" is a binary check.

Once those three features were written down, the technique was obvious. The simpler O(n^2) version was enough because the problem didn't require the faster one:

def lis(nums):
    if not nums:
        return 0
    dp = [1] * len(nums)
    for i in range(len(nums)):
        for j in range(i):
            if nums[j] < nums[i]:
                dp[i] = max(dp[i], dp[j] + 1)
    return max(dp)

The implementation wasn't new. The change was that the technique got reached for because the features matched, not because the exact problem had been memorised.

A second problem the same week

The same week brought Russian Doll Envelopes, which usually trips people up because it doesn't look like an LIS problem on the surface. The problem asks for the maximum number of nested envelopes given pairs of width and height.

Reading for features: a single sequence (after sorting), a length to maximise, a strict comparison between consecutive kept elements (one envelope must fit inside the next). That's LIS, run on the heights after sorting by width with a tiebreak rule. The reframe took two minutes once the read was for features instead of surface details.

That was the moment the recognition drill paid for itself. Two surface-different problems, same three features, same technique. Far transfer.

Why this works (the science to dig into later)

The learning sciences have language for this. Transfer of learning splits into near transfer (a problem that resembles one already practised) and far transfer (a problem that doesn't resemble anything practised, but whose structure can be read).

Volume practice mostly trains near transfer. Whether far transfer is reliably teachable is a debate the research hasn't fully settled. What the evidence does support is the specific intervention this protocol is built around. Explicit instruction in when and why a method applies, not just how to execute it, produces more transfer than practice alone.

In retrospect, the "how" was everywhere on the internet. The "when" and "why" were the parts no resource in the practice loop bothered to teach explicitly.

What to try if you're in the same spot

If problem 200 feels harder than problem 50, the bottleneck probably isn't volume. It's a recognition skill that volume alone doesn't build for everyone. A few things worth trying:

For each technique you've practised, write down two or three observable features that signal it applies. Sliding window: contiguous range, condition across the window, optimisation on length. Two pointers: sorted array, search for a pair or triple, pointers move from the ends. Monotonic stack: per element answer, directional search, comparison. Keep the checklists short.
On every new problem, run the 60 second feature pass before any code. Write a sentence: "this is a [technique] problem because [features]." If you can't write the sentence, don't code yet.
Mix techniques across sessions. Three problems from three different techniques will train recognition in a way that fifteen problems from one technique won't.
Cover the title and the difficulty before reading the constraints. Many problem names give away the technique, and the assistance is exactly the kind of help that disappears in an interview.

This is a practice protocol, not a product. It runs against any problem bank.

Where it's still hard

The recognition drill doesn't fix everything. There's a separate axis prep tends to skip, which is the conditions the practice runs under. The default LeetCode loop has the tag, the difficulty, the discussion thread, and no clock. None of those are present in a real interview. Even with recognition trained, the first time the tag disappears the read gets harder. So the last few weeks of any prep cycle, run every practice session under interview-shaped conditions: clock running, tag covered, discussion section closed.

That's the version of the lesson worth keeping. It wasn't the problem count. It was what was happening on each problem, and what nobody had ever trained on purpose.

I originally posted this on my own blog, with the feature checklists for six more techniques and a longer worked example for variable sliding window.

What's a problem that finally made a technique click for you, where the explanations you'd read before hadn't quite landed?

How to Explain Algorithm Correctness in Coding Interviews

Wed, 06 May 2026 19:47:14 +0000

I'd written the BFS in about eight minutes. The interviewer ran the example I'd traced and said "ok, but how do you know this is right for any input?" My instinct was to point at the code. Pointing wasn't an argument. The silence stretched, and the realisation landed: nobody had ever taught me how to answer that question.

The interview ended without an offer. The post-mortem felt strange because the algorithm was correct, and there was still no way to say why in a form the interviewer could check.

What changed for me

Tracing one input is testing, not proving. Most engineers, including a past version of me, don't notice the difference.
Interviewers want a loop invariant, the property that's true at the start of every iteration.
The full method is two checks: state and verify the invariant, then check initialization, termination, and edge cases.
Different patterns produce differently shaped invariants, but the two step structure stays constant.
The skill is separate from problem solving. It needs its own practice before it becomes reflexive.

Quick disclosure before I get into this: I built Codeintuition, a structured learning platform for coding interviews. This post is the retrospective version of the lesson that BFS interview should have taught me years earlier.

Where my approach was breaking

The default habit looks reasonable from the outside. You write the algorithm. You walk through it on the example the interviewer suggested. You get the right answer. You stop. If they ask a follow up, you trace a slightly harder example. If they push harder, you start guessing about edge cases.

None of that is an argument. It's a sequence of tests. Each test confirms one input. The interviewer's question was about every input.

The gap is small in description and large in practice. A trace shows the algorithm worked once. A correctness argument has to give the interviewer a reason it works always. That bridge is where the interview lives, and most prep material skips it.

The discrete math course you took in college covered induction proofs with formal notation. It's easy to dismiss as academic and move on. What that misses is that the idea (a property that holds every iteration) is exactly what the interview wants. The interview just asks for it as 90 seconds of clear English instead of a paper proof.

What I started doing differently

The first habit was simple. Before tracing any input, write down what's supposed to be true at the start of each iteration. One sentence.

The hard part is that for a few weeks, the sentence wouldn't always come. That alone is the diagnostic. If you can't state the invariant, you solved the problem by pattern matching, not by understanding what made the algorithm work.

The second habit, after stating the invariant, is to check the boundaries separately. What happens before the loop runs. What happens when the loop exits. What happens on an empty input. What happens on a single element. What happens on the maximum size.

The two step method is short. The change in interview outcomes is not.

Step	What I used to do	What works
Before tracing	Pick an example and run it	State the invariant in one sentence, then trace 3 to 4 iterations
At the loop end	Say "and that gives the right answer"	Confirm the invariant plus the loop's exit condition together force the right output
On boundaries	Mention "edge cases" if asked	List initialization, termination, and at least three degenerate inputs explicitly

What that looked like on the next problem

A few months later, the same kind of BFS question came up on a different graph problem. This time the invariant came first.

from collections import deque

def shortest_path(graph, start):
    distances = {start: 0}
    queue = deque([start])
    while queue:
        node = queue.popleft()
        for neighbor in graph[node]:
            if neighbor not in distances:
                distances[neighbor] = distances[node] + 1
                queue.append(neighbor)
    return distances

The argument went something like this: the invariant is that when a node is dequeued, its recorded distance equals the shortest path from the start. The reason it holds is FIFO ordering on a graph with equal edge weights. Any node enqueued later has been reached by a path of the same length or longer, so the first time you see a node is via the shortest path to it.

Then the boundaries. Initialization: only the start node sits in distances with value 0, which is the shortest path from the start to itself. Termination: the loop exits when the queue is empty, meaning every reachable node has been dequeued with its correct distance. Edge cases: a graph with one node returns {start: 0} immediately. A disconnected graph returns distances only for nodes reachable from the start. A self-loop is fine because the check if neighbor not in distances runs before enqueueing.

The interviewer didn't follow up with "but how do you know it's right for any input?" The argument had already covered that.

Why this works (the bit worth digging into later)

The two step method generalises because the structure is the same across every algorithm class. Only the shape of the invariant changes. Sliding window tracks a running variable. Two pointers tracks a search range. Binary search tracks a range too, but a different one. BFS tracks a relationship between dequeue order and shortest path. DP tracks an entire table of subproblem solutions.

The verification framework is invariant plus boundaries, in that order, regardless of pattern.

This connects to a broader idea in computer science formalism: the loop invariant is a logical statement that, combined with the loop's exit condition, gives you the postcondition you wanted to prove. The interview version drops the formal symbols and keeps the structure. Same skeleton, different vocabulary.

What I'd tell someone in the same spot

Three concrete things matter most:

Pick a problem you've solved. Set a timer for 60 seconds. Try to state the loop invariant in one sentence. If the sentence doesn't come, that's the most important diagnostic in your prep, and more problems won't fix it.
Take a correct algorithm. Write down an invariant that sounds plausible but is subtly wrong. Find the iteration where it breaks. This trains the gap between invariants that describe what the code does and invariants that guarantee correctness.
Pair correctness reasoning with mental dry running. The dry run gives you a trace. The invariant gives you the claim to verify against the trace. Practising them apart leaves a hole that interview pressure exposes.

If you want a worked walkthrough of the BFS distance invariant before solving a graph problem with it, the BFS lesson walks through why FIFO ordering plus equal edge weights forces the shortest path property to hold.

I originally posted this on my own blog, a slightly longer version that walks through the two step method on sliding window, binary search, and DP, with an FAQ on nested loops where each loop needs its own invariant.

What's a problem where you understood the algorithm but couldn't say why it was right when someone asked, and what was the missing sentence you wished you'd had?

I Solved 200 LeetCode Problems and Still Froze in Interviews

Mon, 04 May 2026 10:59:45 +0000

A few years ago I solved 200 LeetCode problems and still froze on Mediums I hadn't seen. The breakthrough wasn't another hundred problems. It was a different loop.

A problem asks for the longest substring with at most K distinct characters. You've solved sliding window before. Maximum sum subarray of size K, done. Longest substring without repeating characters, done. This third one stalls you. Twenty minutes pass. Discuss says sliding window. You'd already solved sliding window problems. The recognition didn't work on this one.

TL;DR: Practice volume builds memory of specific problems, not the recognition you have to do before you start coding. The skill that transfers to unfamiliar interview mediums is identifying which technique applies from what the problem looks like. That recognition is what most LeetCode-style prep doesn't train, and that gap is what this post is about.

What LeetCode actually does well

LeetCode is the default coding interview prep platform for a reason. The problem bank is the strongest available: 3,000+ problems across every common data structure, tagged by company and frequency. The company tagging is the most reliable public signal you can get for "what does Amazon currently ask." Nothing else is close on that dimension.

The free tier is generous, the discuss forum is open, and the weekly contests are free. If you already understand the underlying patterns and you need volume to drill them, LeetCode is the right platform. The contest system is genuinely underrated for building speed under time. Top voted discuss replies on popular problems also hold up. They often explain the reasoning more clearly than the official editorials.

So the question isn't whether LeetCode is good. It is good. The real question is whether the thing holding you back is the kind of thing LeetCode's design actually fixes.

The gap volume doesn't close

The earlier sliding window problems taught implementation on those specific problems, not the rule for when sliding window applies. The connection between "K distinct characters" and "variable sliding window" was never made explicit anywhere in your prep. You learned an implementation by example, not a recognition rule. When the visible parts of the problem change, the implementation memory doesn't carry over.

Learning research calls this near transfer versus far transfer. Near transfer means solving problems that look like ones you've already solved. Far transfer means reasoning through problems that look different but follow the same underlying pattern. The Wikipedia article on transfer of learning covers it. The short version: practice volume produces near transfer reliably and far transfer unreliably. You can grind 500 problems and still not generalise across the differences in description if no one ever taught you which features signal which pattern.

That isn't a talent gap. It's a gap in the method.

What recognition actually looks like

Recognition is reading a problem statement, naming the visible features, and matching them to a technique before any code is written. Every technique has a small set of trigger conditions, usually three to five. When all of them match, you've identified the technique.

For variable sliding window, the trigger conditions are:

The input is a contiguous range (a substring, a subarray, a window of consecutive elements).
The optimisation target is the length of that range (longest, shortest, smallest valid).
There is a condition you can check incrementally as the window expands or contracts (count of distinct characters, sum within bounds, set membership).

When all three apply, variable sliding window is the technique. K distinct characters hits all three. So does longest substring without repeating characters. So does minimum window substring. The triggers are the same. The descriptions differ.

The skill is matching problems to triggers before coding. That's what doesn't get built by grinding problems sequentially.

A code template you can adapt

Here's the variable sliding window template in Python. Once you recognise the technique, the implementation has very few moving parts.

def variable_window(arr, condition):
    left = 0
    state = init_state()
    best = 0

    for right in range(len(arr)):
        state = expand(state, arr[right])
        while not condition(state):
            state = shrink(state, arr[left])
            left += 1
        best = max(best, right - left + 1)

    return best

For K distinct characters, state is a hash map of character counts within the current window, condition is len(state) <= K, and shrink decrements counts and removes keys whose count drops to zero. The recognition step (this is variable sliding window) is the decision that matters. The code follows.

For longest substring without repeating characters, state becomes a hash set and condition is "no duplicate." Same skeleton. Same invariant.

That's the payoff of recognition trained explicitly. Write the template once. Adapt per problem in two or three lines. Stop staring at problems hoping the right approach surfaces.

How practice and interview conditions diverge

Recognition is half the gap. The other half is the conditions you practise under. LeetCode's practice environment shows you the problem name (which often hints at the technique), gives unlimited code executions, and doesn't penalise failed attempts. Real interviews give none of that.

Dimension	Practice (LeetCode default)	Real interview
Problem name	Visible, often hints at category	Not given
Code executions	Unlimited, no penalty	Limited, every failure costs
Hints / discuss	One click away	Not available
Time limit	Self set, often skipped	20 to 45 minutes hard
Reasoning	Internal	Spoken aloud

The middle column is fine for the early learning phase. Open exploration helps when you're still building the model. The problem comes when those conditions are the only conditions you ever rehearse under, and the actual test wants something the rehearsal never asked for.

Replicating interview pressure on your own takes one friend and a kitchen timer. The friend covers the problem name and reads the constraints aloud. You set the timer to 20 or 30 minutes. You don't open the IDE before stating the technique you intend to use. Two sessions a week against a friend who isn't shy about silence will do more for interview readiness than another fifty problems on the comfort setting.

A protocol you can run this week

If the K distinct characters story sounded like your last three failed problems, the move isn't more volume. It's a tighter loop on recognition first.

Pick one technique a week (variable sliding window, two pointers, prefix sum, monotonic stack, and so on).
Write down the trigger conditions for that technique. Three to five features of the problem that, when they all apply, make this technique the right tool. Write them in your own words, not from a cheat sheet.
Read five problems that use this technique without solving them. For each, name the triggers you can see in the problem statement before reading the constraints in detail.
Solve three to five problems on this technique with the problem name and tag hidden. Force the recognition step.
Once a week, do one timed pressure session: friend covers the title, you talk through your reasoning, no IDE until you've named the technique. If you can't name it inside five minutes, the problem rewinds to the recognition queue, not the implementation queue.

A pattern a week, eight to ten patterns covered, roughly ten weeks of focused work. That replaces the hundreds of mediums where the signal gets buried under details that don't matter.

The longer write up of this is on my own blog, with trigger conditions for prefix sum, two pointers, and monotonic stack alongside the variable sliding window walkthrough above, plus a worked example on minimum window substring that uses the same template.

When did the recognition click for a pattern you used to grind without seeing, and what was the specific problem that broke it open?

Disclosure: I built Codeintuition, a structured learning platform for coding interviews. The post above is about the technique, not the platform.

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;
};

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;
    }
}

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