neetcode-gh · neetcode-gh · Mar 10, 2025 · Mar 6, 2025 · Mar 7, 2025 · Mar 8, 2025
diff --git a/articles/counting-bits.md b/articles/counting-bits.md
@@ -124,8 +124,10 @@ class Solution {
 
 ### Time & Space Complexity
 
-* Time complexity: $O(n)$
-* Space complexity: $O(1)$
+* Time complexity: $O(n \log n)$
+* Space complexity:
+    * $O(1)$ extra space.
+    * $O(n)$ space for the output array.
 
 ---
 
@@ -248,8 +250,10 @@ class Solution {
 
 ### Time & Space Complexity
 
-* Time complexity: $O(n)$
-* Space complexity: $O(1)$
+* Time complexity: $O(n \log n)$
+* Space complexity:
+    * $O(1)$ extra space.
+    * $O(n)$ space for the output array.
 
 ---
 
@@ -338,8 +342,10 @@ class Solution {
 
 ### Time & Space Complexity
 
-* Time complexity: $O(n)$
-* Space complexity: $O(1)$
+* Time complexity: $O(n \log n)$
+* Space complexity:
+    * $O(1)$ extra space.
+    * $O(n)$ space for the output array.
 
 ---
 
@@ -470,7 +476,9 @@ class Solution {
 ### Time & Space Complexity
 
 * Time complexity: $O(n)$
-* Space complexity: $O(1)$
+* Space complexity:
+    * $O(1)$ extra space.
+    * $O(n)$ space for the output array.
 
 ---
 
@@ -567,4 +575,6 @@ class Solution {
 ### Time & Space Complexity
 
 * Time complexity: $O(n)$
-* Space complexity: $O(1)$
+* Space complexity:
+    * $O(1)$ extra space.
+    * $O(n)$ space for the output array.
diff --git a/articles/insert-new-interval.md b/articles/insert-new-interval.md
@@ -221,7 +221,9 @@ class Solution {
 ### Time & Space Complexity
 
 * Time complexity: $O(n)$
-* Space complexity: $O(1)$
+* Space complexity:
+    * $O(1)$ extra space.
+    * $O(n)$ space for the output list.
 
 ---
 
@@ -515,7 +517,9 @@ class Solution {
 ### Time & Space Complexity
 
 * Time complexity: $O(n)$
-* Space complexity: $O(1)$
+* Space complexity:
+    * $O(1)$ extra space.
+    * $O(n)$ space for the output list.
 
 ---
 
@@ -708,4 +712,6 @@ class Solution {
 ### Time & Space Complexity
 
 * Time complexity: $O(n)$
-* Space complexity: $O(1)$
+* Space complexity:
+    * $O(1)$ extra space.
+    * $O(n)$ space for the output list.
diff --git a/articles/merge-intervals.md b/articles/merge-intervals.md
@@ -169,7 +169,9 @@ class Solution {
 ### Time & Space Complexity
 
 * Time complexity: $O(n \log n)$
-* Space complexity: $O(1)$ or $O(n)$ depending on the sorting algorithm.
+* Space complexity:
+    * $O(1)$ or $O(n)$ space depending on the sorting algorithm.
+    * $O(n)$ for the output list.
 
 ---
 

diff --git a/articles/plus-one.md b/articles/plus-one.md
@@ -139,7 +139,7 @@ class Solution {
 
 ---
 
-## 2. Iteration
+## 2. Iteration - I
 
 ::tabs-start
 
@@ -148,7 +148,7 @@ class Solution:
     def plusOne(self, digits: List[int]) -> List[int]:
         one = 1
         i = 0
-        digits = digits[::-1]
+        digits.reverse()
 
         while one:
             if i < len(digits):
@@ -161,7 +161,9 @@ class Solution:
                 digits.append(one)
                 one = 0
             i += 1
-        return digits[::-1]
+
+        digits.reverse()
+        return digits
 ```
 
 ```java
@@ -344,11 +346,11 @@ class Solution {
 ### Time & Space Complexity
 
 * Time complexity: $O(n)$
-* Space complexity: $O(1)$
+* Space complexity: $O(1)$ or $O(n)$ depending on the language.
 
 ---
 
-## 3. Iteration (Optimal)
+## 3. Iteration - II
 
 ::tabs-start
 
@@ -479,4 +481,4 @@ class Solution {
 ### Time & Space Complexity
 
 * Time complexity: $O(n)$
-* Space complexity: $O(1)$
+* Space complexity: $O(n)$
diff --git a/articles/set-zeroes-in-matrix.md b/articles/set-zeroes-in-matrix.md
@@ -212,7 +212,7 @@ class Solution {
 
 ### Time & Space Complexity
 
-* Time complexity: $O(m * n)$
+* Time complexity: $O((m * n) * (m + n))$
 * Space complexity: $O(m * n)$
 
 > Where $m$ is the number of rows and $n$ is the number of columns.

diff --git a/articles/spiral-matrix.md b/articles/spiral-matrix.md
@@ -203,7 +203,9 @@ class Solution {
 ### Time & Space Complexity
 
 * Time complexity: $O(m * n)$
-* Space complexity: $O(min(m, n))$
+* Space complexity:
+    * $O(min(m, n))$ space for recursion stack.
+    * $O(m * n)$ space for the output list.
 
 > Where $m$ is the number of rows and $n$ is the number of columns.
 
@@ -467,7 +469,9 @@ class Solution {
 ### Time & Space Complexity
 
 * Time complexity: $O(m * n)$
-* Space complexity: $O(1)$
+* Space complexity:
+    * $O(1)$ extra space.
+    * $O(m * n)$ space for the output list.
 
 > Where $m$ is the number of rows and $n$ is the number of columns.
 
@@ -655,6 +659,8 @@ class Solution {
 ### Time & Space Complexity
 
 * Time complexity: $O(m * n)$
-* Space complexity: $O(1)$
+* Space complexity:
+    * $O(1)$ extra space.
+    * $O(m * n)$ space for the output list.
 
 > Where $m$ is the number of rows and $n$ is the number of columns.
diff --git a/articles/string-encode-and-decode.md b/articles/string-encode-and-decode.md
@@ -286,8 +286,8 @@ class Solution {
 
 ### Time & Space Complexity
 
-* Time complexity: $O(m)$ for $encode()$ and $decode()$.
-* Space complexity: $O(n)$ for $encode()$ and $decode()$.
+* Time complexity: $O(m)$ for each $encode()$ and $decode()$ function calls.
+* Space complexity: $O(m + n)$ for each $encode()$ and $decode()$ function calls.
 
 > Where $m$ is the sum of lengths of all the strings and $n$ is the number of strings.
 
@@ -510,7 +510,7 @@ class Solution {
 
 ### Time & Space Complexity
 
-* Time complexity: $O(m)$ for $encode()$ and $decode()$.
-* Space complexity: $O(1)$ for $encode()$ and $decode()$.
+* Time complexity: $O(m)$ for each $encode()$ and $decode()$ function calls.
+* Space complexity: $O(m + n)$ for each $encode()$ and $decode()$ function calls.
 
 > Where $m$ is the sum of lengths of all the strings and $n$ is the number of strings.
diff --git a/articles/subarrays-with-k-different-integers.md b/articles/subarrays-with-k-different-integers.md
@@ -246,7 +246,7 @@ class Solution {
 
 ---
 
-## 3. Slidingt Window (One Pass) - I
+## 3. Sliding Window (One Pass) - I
 
 ::tabs-start
 

diff --git a/hints/burst-balloons.md b/hints/burst-balloons.md
@@ -0,0 +1,39 @@
+<br>
+<details class="hint-accordion">  
+    <summary>Recommended Time & Space Complexity</summary>
+    <p>
+    You should aim for a solution with <code>O(n ^ 3)</code> time and <code>O(n ^ 2)</code> space, where <code>n</code> is the size of the input array.
+    </p>
+</details>
+
+<br>
+<details class="hint-accordion">  
+    <summary>Hint 1</summary>
+    <p>
+    Try to simulate the process recursively by passing the array to the recursive function. At each step, iterate through the array, pop an element, and recursively apply the same process to the two subarrays on both sides of the popped element, returning the maximum result from all recursive paths. This approach is exponential. Can you think of a way to optimize it? Maybe you should consider observing the subproblems instead of modifying the array.
+    </p>
+</details>
+
+<br>
+<details class="hint-accordion">  
+    <summary>Hint 2</summary>
+    <p>
+    Instead of passing the array, we can pass the range of indices <code>l</code> and <code>r</code> that need to be processed. We pad the input array with <code>1</code>s on both sides for easier computation, but <code>l</code> and <code>r</code> represent the first and last indices of the original input array. Can you think of a reverse engineering approach for popping elements?
+    </p>
+</details>
+
+<br>
+<details class="hint-accordion">  
+    <summary>Hint 3</summary>
+    <p>
+    We determine the result by considering each element as the last one to be popped in the current range. For each element, we calculate its value by multiplying it with the elements at <code>l - 1</code> and <code>r + 1</code>, then recursively solve the subproblems for the ranges <code>(l, i - 1)</code> and <code>(i + 1, r)</code>, where <code>i</code> is the current element in the given range. Can you think of a way to optimize and avoid redundant calculations?
+    </p>
+</details>
+
+<br>
+<details class="hint-accordion">  
+    <summary>Hint 4</summary>
+    <p>
+    We can use memoization to cache the results of recursive calls and avoid redundant calculations. A hash map or a <code>2D</code> array can be used to store results since the recursive function parameters <code>l</code> and <code>r</code> are within the range of the input array size.
+    </p>
+</details>
diff --git a/hints/buy-and-sell-crypto-with-cooldown.md b/hints/buy-and-sell-crypto-with-cooldown.md
@@ -0,0 +1,39 @@
+<br>
+<details class="hint-accordion">  
+    <summary>Recommended Time & Space Complexity</summary>
+    <p>
+    You should aim for a solution as good or better than <code>O(n)</code> time and <code>O(n)</code> space, where <code>n</code> is the size of the input array.
+    </p>
+</details>
+
+<br>
+<details class="hint-accordion">  
+    <summary>Hint 1</summary>
+    <p>
+    Try to think in terms of recursion and visualize it as a decision tree. Can you determine the possible decisions at each recursion step? Also, can you identify the base cases and the essential information that needs to be tracked during recursion?
+    </p>
+</details>
+
+<br>
+<details class="hint-accordion">  
+    <summary>Hint 2</summary>
+    <p>
+    At each recursion step, we can buy only if we haven't already bought a coin, or we can sell if we own one. When buying, we subtract the coin value, and when selling, we add it. We explore all possible buying and selling options recursively, iterating through the coins from left to right using index <code>i</code>. For the cooldown condition, if we buy a coin, we increment the index <code>i</code> by two.
+    </p>
+</details>
+
+<br>
+<details class="hint-accordion">  
+    <summary>Hint 3</summary>
+    <p>
+    We can use a boolean variable <code>canBuy</code> to indicate whether buying is allowed at the current recursive step. If we go out of bounds, we return <code>0</code>. This approach is exponential. Can you think of a way to optimize it?
+    </p>
+</details>
+
+<br>
+<details class="hint-accordion">  
+    <summary>Hint 4</summary>
+    <p>
+    We can use memoization to cache the results of recursive calls and avoid recalculations. A hash map or a <code>2D</code> array can be used to store these results.
+    </p>
+</details>
diff --git a/hints/coin-change-ii.md b/hints/coin-change-ii.md
@@ -0,0 +1,39 @@
+<br>
+<details class="hint-accordion">  
+    <summary>Recommended Time & Space Complexity</summary>
+    <p>
+    You should aim for a solution as good or better than <code>O(n * a)</code> time and <code>O(n * a)</code> space, where <code>n</code> is the number of coins and <code>a</code> is the given amount.
+    </p>
+</details>
+
+<br>
+<details class="hint-accordion">  
+    <summary>Hint 1</summary>
+    <p>
+    As we need to find the total number of combinations, think in terms of recursion and visualize it as a decision tree where multiple coin choices are available at each recursion step. Can you determine a way to allow picking the same coin multiple times? Maybe you should consider the decisions made at each recursion step.
+    </p>
+</details>
+
+<br>
+<details class="hint-accordion">  
+    <summary>Hint 2</summary>
+    <p>
+    The given coins are unique. We recursively iterate through the coins array using index <code>i</code>, tracking the collected amount along the current path. At each step, we can either skip the current coin or pick it, ensuring the total does not exceed the target. To allow picking the same coin multiple times, we recurse with the same index but an updated amount, generating different combinations.
+    </p>
+</details>
+
+<br>
+<details class="hint-accordion">  
+    <summary>Hint 3</summary>
+    <p>
+    If we reach the target amount, we return <code>1</code>. The recursion stops if the index goes out of bounds. We count all possible ways and return the total. This approach is exponential. Can you think of a way to optimize it? Maybe you should consider an approach to avoid redundant computations.
+    </p>
+</details>
+
+<br>
+<details class="hint-accordion">  
+    <summary>Hint 4</summary>
+    <p>
+    We can use memoization to cache the results of recursive calls and avoid redundant computations. A hash map or a <code>2D</code> array can be used to store these results.
+    </p>
+</details>
diff --git a/hints/count-paths.md b/hints/count-paths.md
@@ -0,0 +1,39 @@
+<br>
+<details class="hint-accordion">  
+    <summary>Recommended Time & Space Complexity</summary>
+    <p>
+    You should aim for a solution as good or better than <code>O(m * n)</code> time and <code>O(m * n)</code> space, where <code>m</code> is the number of rows and <code>n</code> is the number of columns in the grid.
+    </p>
+</details>
+
+<br>
+<details class="hint-accordion">  
+    <summary>Hint 1</summary>
+    <p>
+    Try to think in terms of recursion and visualize it as a decision tree, where we have two choices at each step. Can you determine the base condition and recurrence relation?
+    </p>
+</details>
+
+<br>
+<details class="hint-accordion">  
+    <summary>Hint 2</summary>
+    <p>
+    We recursively traverse the grid using row <code>i</code> and column <code>j</code>. At each step, we explore both possibilities: moving down or moving right, ensuring we do not go out of bounds. If we reach the bottom-right cell, we return <code>1</code>.
+    </p>
+</details>
+
+<br>
+<details class="hint-accordion">  
+    <summary>Hint 3</summary>
+    <p>
+    This approach has exponential complexity. Can you think of a way to optimize the recursion? Maybe you should consider using a dynamic programming approach.
+    </p>
+</details>
+
+<br>
+<details class="hint-accordion">  
+    <summary>Hint 4</summary>
+    <p>
+    We can use memoization to cache the results of recursive calls and avoid recalculations. A hash map or a <code>2D</code> array can be used to store these results.
+    </p>
+</details>
-Original file line number
+Diff line change
@@ Expand Up / @@ -246,7 +246,7 @@ class Solution { @@
     ---
-    ## 3. Slidingt Window (One Pass) - I
+    ## 3. Sliding Window (One Pass) - I
     ::tabs-start
@@ Expand Down @@