DEV Community: 0not0

AI can solve LeetCode in seconds. Is writing coding tutorials still worth it?

0not0 — Tue, 15 Sep 2026 11:18:51 +0000

This article is based on my own experience and observations. Maybe, if the website is still alive, I'll come back to this article in six months and update it with the results I have at that time.

I run a small website called AlgoBytes, where I write about algorithms, coding interview patterns, and LeetCode problems. A detailed solution post can easily take me from 30 minutes to an hour to write, format, check, and publish. Here, I don't take into account the time spent solving the problem.
Meanwhile, I can give the same problem to an AI assistant and get a working solution with an explanation in seconds.

That made me ask a simple question: why am I still doing this, and should I keep doing it?

I decided not to guess. I started watching what actually happens to the articles I publish on AlgoBytes - whether Google indexes them, whether people search for these solutions, and whether anyone actually clicks them.
Almost all of my solution posts reached the top 10 in Google search results, even though there are many big competitors in this niche. There are specialized websites, YouTube channels, and many posts on different platforms dedicated to solving specific LeetCode problems.

For a very young website, getting stable positions on the first page of Google looks like a good result. But at the time of writing this post, those positions haven't brought me any real traffic.

Maybe the way I present the material also affects the results. I intentionally decided not to write long step-by-step explanations of how to solve each problem. Instead, I tried to explain the main idea of the solution in 5 - 10 sentences.

In my opinion, with a short explanation like this and ready-to-use solutions in popular languages such as C++, Java, Python, JavaScript, and TypeScript, a reader can analyze the code and understand the solution on their own. I think this can be more useful than simply reading a complete step-by-step explanation where everything has already been explained for them.
Still, I think I will experiment with both formats in the future.
But I don't think the format is the main reason why being near the top of the search results doesn't bring much traffic.

The main reason, in my opinion, is AI.

You can get a solution to almost any coding problem in almost any programming language in a few seconds, together with a detailed explanation of how the solution works and why it works.
Even when AI gives links to websites where you can read a more detailed explanation, the answer generated directly by AI is probably enough for most users. They simply don't need to click another link.
On top of that, if the search results already have two strong competitors and a YouTube video block above you, the chances that even an interested user will scroll down and click the third, fourth, or fifth result become much lower.

I still don't know whether AlgoBytes will be worth the time I put into it. But that's exactly why I'm continuing the experiment.

LeetCode 4000 - 4010 problems: patterns and approaches explained

0not0 — Tue, 15 Sep 2026 08:10:28 +0000

LeetCode has started publishing problems numbered 4000 and above. At the time of writing this post, there are already 4055 problems.
In this post, I’ll take a look at the first of them, from 4000 to 4010 (except 4004, 4005), including the difficulty level of each problem and the patterns that can be used to solve it.
There are no solutions here, so you can try to solve these problems on your own using the suggested patterns as hints before looking at the actual solutions.

Here:
Easy level: 4000, 4006, 4010
Medium level: 4001, 4002, 4008
Hard level: 4003, 4007, 4009

4000. Largest Integer With Given Digit Sum

Easy level
This is a numbers (digit manipulation) problem. We need to construct the largest number with at most n digits whose digit sum is equal to s.
To make the number as large as possible, we need to place the largest possible digits on the left - first 9, then the remainder, and then 0s.
If s > 9 * n, it is impossible to construct such a number.

Complexity should be:
Time complexity: O(n)
Space complexity: O(n)

Patterns: Greedy, Digit Construction (Math)

Check the solution here

4001. Aggregate Two Time Series

Medium level
This is an array (merge two sorted arrays) problem. We need to iterate through two time series and, for each timestamp, calculate the sum of the values from both series. Since both arrays are already sorted by timestamp, the best approach is to move two pointers through series1 and series2 simultaneously.

Complexity should be:
Time complexity: O(n+m)
Space complexity: O(n+m)

Patterns: Two Pointers, Merge Sorted Arrays, Forward Fill or Next Available Value

Check the solution here

4002. Count Valid Sequences

Medium level
This is a combinatorics (integer compositions problem). We need to count the number of sequences of k positive integers with sum n whose product is even.
The key idea is to count all sequences with sum n and then subtract those where all numbers are odd, because this is the only case where the product is odd.

Complexity for the standard solution using factorials:
Time complexity: O(n)
Space complexity: O(n)

Patterns: Combinatorics, Stars and Bars, Parity Counting, Modular Arithmetic

Check the solution here

4003. Minimum Cost Path with Alternating Directions III

Hard level
This is a graph (shortest path in a grid) problem. The state depends not only on the cell (i, j), but also on the parity of the next action.
So, each cell is effectively represented by two states: (i, j, odd) and (i, j, even).

Complexity should be:
Time complexity: O(m*n * log(m*n))
Space complexity: O(m*n)

Patterns: Dijkstra, State Graph, Grid Shortest Path, Parity State

Check the solution here

4006. Count Valid Prefixes

Easy level
This is a strings (prefix counting) problem. For each prefix, we need to check whether its characters can be rearranged to form an alternating string.
The key condition is that, for an alternating binary string, the number of 0s and 1s can differ by at most 1.

Complexity should be:
Time complexity: O(n)
Space complexity: O(1)

Patterns: Prefix Counting, Frequency Counting, Parity / Balance Check

4007. Widest Possible Fence

Hard level
This is an arrays (counting) problem. We need to find a height h that allows us to obtain the maximum number of boards, either by using existing boards of height h or by combining pairs of boards whose heights sum to h.
For each pair of different heights x and y, the contribution to height x + y is min(count[x], count[y]). For equal heights x + x, we can create count[x] / 2 boards. Existing boards of height x are also added directly to the result for that height.

Complexity in worst case:
Time complexity: O(n²)
Space complexity: O(n²)

Patterns: Frequency Counting, Hash Map, Pair Sum / Two Sum, Enumeration

4008. Minimum Initial Strength to Defeat All Monsters

Medium level
This is an arrays (range updates, prefix sums) problem. First, we need to calculate the total bonus for each monster, and then determine the minimum initial strength required to defeat all monsters from left to right.
Using a Difference Array pattern lets us apply all boosts [l, r, v] in O(n + boosts.length) time without processing each range separately.
For each i, we effectively determine the minimum initial strength that would have been required, taking into account the strength already spent and the temporary bonus.

Complexity should be:
Time complexity: O(n+b)
Space complexity: O(n)

Patterns: Difference Array, Prefix Sum, Prefix Maximum / Greedy

4009. Minimum Possible Maximum Waiting Time

Hard level
This is a dynamic programming (scheduling with two resources) problem. We need to assign cars to one of two dispensers so that we first maximize the number of cars served and, among those solutions, minimize the maximum waiting time.
The DP state needs to track how much fuel remains in both dispensers, when each dispenser becomes available, and the waiting time accumulated so far.
Because of the small constraints fuel[j] <= 50 and demand[i] <= 20, we can build a DP over the possible states of the two dispensers.

Complexity should be:
Time complexity: O(n*F²)
Space complexity: O(F²)
Here, F <= 50 is the maximum fuel capacity of a single dispenser.

Patterns: Dynamic Programming, State Compression, Scheduling, Minimax Optimization

4010. Maximize Pair Strength Using GCD

Easy level
This is an arrays (number theory) problem. We need to iterate over pairs of numbers and maximize a value that depends on their product and gcd.
For each pair (i, j), we calculate gcd(nums[i], nums[j]) and the corresponding strength.

Complexity should be:
Time complexity: O(n² log M)
Space complexity: O(1)
Here, M = max(nums[i]).

Patterns: Greatest Common Divisor (GCD), Number Theory, Pair Enumeration

LeetCode 1 Two Sum: Imperative C++/Java vs Functional Elixir

0not0 — Fri, 11 Sep 2026 09:29:42 +0000

First of all, I'm not an Elixir developer, so maybe someone can solve this problem in a more optimal way.

You can find the original post here

You can find the problem description and solutions in all programming languages supported by LeetCode here

The general approach for different programming languages is:

For the current nums[i], calculate target - nums[i]
Check whether we have seen this number before.
If yes, return the two indices.
If not, store the current number and its index.

What is more interesting is the difference in implementation in C++ or Java and Elixir.
The biggest conceptual difference here is between the imperative style of C++/Java and the functional style of Elixir with recursion and immutable data.

Let's see two solutions: on Java and Elixir.

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

Java

class Solution {
  public int[] twoSum(int[] nums, int target) {
    Map<Integer, Integer> map = new HashMap<>();

    for(int i = 0; i < nums.length; i++) {
      int val = target - nums[i];

      Integer index = map.get(val);

      if(index != null) return new int[]{index, i};

      map.put(nums[i], i);
    }

    return new int[]{};
  }
}

Elixir

defmodule Solution do
  @spec two_sum(nums :: [integer], target :: integer) :: [integer]
  def two_sum(nums, target) do
    find(nums, target, %{}, 0)
  end

  defp find([num | rest], target, map, i) do
    val = target - num

    case Map.fetch(map, val) do
      {:ok, index} ->
        [index, i]

      :error ->
        find(rest, target, Map.put(map, num, i), i + 1)
    end
  end

  defp find([], _target, _map, _i), do: []
end

Let's see the difference.

1. C++ and Java use a loop for. Elixir, on the other hand, uses recursion:

find(rest, target, ..., i + 1)

Each recursive call processes one element.

[num | rest]

This means: num is the first element of the list, rest is all remaining elements.

2. Another important difference is immutability.

In C++

map[nums[i]] = i;

we change the existing unordered_map.

In Java

map.put(nums[i], i);

we also change existing Map.

In Elixir map doesn't change and Map.put returns new map, we pass it to the next recursive call:

Map.put(map, num, i)
find(rest, target, Map.put(map, num, i), i + 1)

3. The difference in search.

C++

auto it = map.find(val);
if (it != map.end())

Java

Integer index = map.get(val);
if (index != null)

In Elixir

case Map.fetch(map, val) do
    {:ok, index} ->
    :error ->
end

Map.fetch/2 explicitly returns one of two possible results:

{:ok, index} - found
:error - not found

That is why case is very useful in this situation.

But we also have a solution without recursion using built-in Enum functions:

defmodule Solution do
  @spec two_sum(nums :: [integer], target :: integer) :: [integer]
  def two_sum(nums, target) do
    nums
    |> Enum.with_index()
    |> Enum.reduce_while(%{}, fn {num, i}, map ->
      val = target - num

      case Map.fetch(map, val) do
        {:ok, index} ->
          {:halt, [index, i]}

        :error ->
          {:cont, Map.put(map, num, i)}
      end
    end)
  end
end

The difference is in the way we iterate:

Manual tail recursion - we control the transition to the next element yourself through a recursive call.

Enum abstraction - iteration is handled by built-in Enum functions such as Enum.with_index() and Enum.reduce_while().

LeetCode 3870 & 3871: from a simple to a general solution

0not0 — Thu, 10 Sep 2026 05:34:59 +0000

LeetCode problems 3870 and 3871 clearly show the transition from a simple case to a generalized one depending on the constraints. I would say this is a good example of why you should always ask about the problem constraints.

The problems are very similar, but different constraints lead to completely different solutions.

Both problems have the same description:

You are given an integer n.
Return the total number of commas used when writing all integers from [1, n] (inclusive) in standard number formatting.
In standard formatting:

A comma is inserted after every three digits from the right.

Numbers with fewer than 4 digits contain no commas.

And the answer to which solution we should choose lies in the constraints themselves.

For 3870 constrain is 1 <= n <= 10⁵
For 3871 constrain is 1 <= n <= 10¹⁵

3870. Count Commas in Range I: the constraints allow us to take advantage of the fact that each number can have at most one comma - a simple solution.

1 ... 999  has 0 commas
1000 ... n has 1 comma

That is why we use max(0, n - 999) in the solution.

class Solution {
public:
  int countCommas(int n) {
    return max(0, n - 999);
  }
};

3871. Count Commas in Range II: n can be much larger (n <= 10¹⁵ ), so numbers can contain 2, 3, 4, or 5 commas, which requires a more general solution.

The idea from LeetCode 3870 is no longer enough for LeetCode 3871 because numbers can now contain more than one comma.

>= 1,000          +1 comma
>= 1,000,000      +1 additional comma
>= 1,000,000,000  +1 additional comma
...

Need to understand: for 3871 due to the specific constraint, the loop runs only a few times at most, so within the given constraints, it can also be considered constant-time bounded work.

Since a new comma appears every three additional digits we have start *= 1000.

class Solution {
public:
  long long countCommas(long long n) {
    long long result = 0;

    for(long long start = 1000; start <= n; start *= 1000) 
      result += n - start + 1;

    return result;
  }
};

Essential coding interview preparation tips you should know before you start

0not0 — Mon, 07 Sep 2026 12:06:30 +0000

What you need to understand before you start preparing for a Coding Interview

Previously, I wrote about why you need to solve LeetCode problems in the AI era. And if you've decided to prepare for a coding interview, I hope these tips will be useful to you.

First. You need to understand that you are spending your free time developing a purely practical skill that you will need only at the interview stage. That is what this skill is for - passing a specific stage of the interview process. Nothing more.

Second. You need to set a clear timeframe for your preparation and decide when you are going to start interviewing. You can prepare forever and still never feel completely confident that you are ready to solve coding interview problems.

Third, and this is closely related to the second point. During your preparation, you will constantly experience emotional ups and downs: I can do it - I can't do it. That is exactly why it is important to set a clear deadline for yourself. For example: I have three months to prepare, and then I enter the job market. When you have a fixed deadline, you reduce your chances of burning out during the preparation stage.

Fourth. A clear deadline allows you to plan your preparation, while intermediate checkpoints allow you to adjust its direction. For example, you may be comfortable solving problems involving strings and arrays but struggle with Binary Search. In that case, add more Binary Search problems to your preparation and spend less time on strings and arrays.

Fifth. You should accept that there will be problems you simply cannot solve on your own, especially during the early stages of preparation. This is completely normal. There is no reason to feel bad about it or think that it makes you a failure or a bad programmer.

Sixth. Don't spend too much time trying to solve a single problem. If you cannot find a solution within an hour, there is usually no point in stubbornly sitting there trying to figure it out. Most likely, you will just waste your time without making much progress. Google, ChatGPT, or any other resource - use whatever helps you move forward. Your free time is limited. Don't waste it on stubbornness just because you feel that you have to prove something to yourself.

Seventh, and probably the most important point. Consistency is the foundation of the entire preparation process. Many people who start this coding interview preparation marathon never reach the finish line. And that is exactly what it is - a marathon that lasts several months. Only consistent, persistent, routine work every day can produce results. Motivation usually disappears after a few weeks. After that, what remains is the simple routine of solving LeetCode problems, accompanied by constant emotional ups and downs.

You need to be ready for this.
Before you start preparing, ask yourself whether you are really ready to invest your free time for several months into this emotional marathon. But you should also remember why you are developing this coding interview problem-solving skill in the first place. Behind it may be new professional opportunities, better career prospects, and possibilities that are currently unavailable to you. And all you need to do to reach them is finish this marathon.

And most importantly, that part depends entirely on you.

Why do you need to solve LeetCode problems in the AI era?

0not0 — Sun, 06 Sep 2026 13:18:53 +0000

I often hear and read on forums and in my LinkedIn feed that solving coding problems yourself, such as LeetCode problems, is the old way, and AI can do it quickly and accurately. And that's absolutely true. AI can solve a hard-level problem in one minute, while a trained person doing it may take much longer, and their solution is more likely to be suboptimal. But AI writes code faster and more efficiently than the average programmer. So, does that mean we shouldn't write code at all? This is a controversial question.

If solving LeetCode-style problems is a hobby for someone, obviously they will keep doing it regardless of how much faster and more efficiently AI can solve them, or whether AI exists at all. But a lot of people spend a lot of time solving LeetCode-style problems, not out of love for them.

We can rewrite this question: Why do we need to solve LeetCode problems in the AI era? on: Why do we need to spend our free time solving LeetCode-style problems in the AI era? Or much more detailed:

Why do we need to spend our limited free time solving LeetCode-style problems in the AI era instead of spending it with our families, pursuing our hobbies, or doing something else?

Why spend time on LeetCode problems in the AI era?

Time is a very valuable resource. We need a good reason to spend it solving algorithmic coding problems. And the only real motivation for doing it is finding a job and preparing for job interviews. This is what forces a lot of people to put off other, much more enjoyable things and solve coding interview problems instead. Even now, LeetCode-style problems still exist and, in many cases, are part of the interview process for many IT professionals. From my point of view, preparing for job interviews is the only reason why we need to spend our free time solving algorithmic coding problems. The skill of solving such tasks quickly is almost never needed in day-to-day work.

We can develop the ability to structure our thoughts without spending time on a skill that we won't need in our actual work. The ability to write compact code, which you develop after solving enough LeetCode-style problems, is more of a disadvantage than an advantage in real-world projects. What matters there is not brevity, but code readability. The ability to use data structures in practice? Yes, that's a valid point, but this skill can also be developed by solving real-world problems. The ability to analyze algorithmic complexity? If you really need it in your job, you'll know how to do it. If you don't, you won't.

In addition, we need to understand that solving LeetCode problems is a skill. And like any other skill, it fades if you don't practice it regularly. Motivation can't last forever either.
So, to repeat my point, the only reason to solve algorithmic coding problems in the AI era is to pass one of the stages of the interview process and get a job.

LeetCode as a skill for technical interview preparation

The ability to pass job interviews is a separate skill that has little to do with what you will actually be doing at work. And this skill needs to be practiced too. An interviewer has very limited time - an hour or two - to decide whether you are a good fit. The better you present yourself, the better your chances of moving forward in the interview process.

And as long as different variations of LeetCode-style problems are used in job interviews, people will continue to invest their free time and effort in learning how to solve these problems as quickly as possible and with the most optimal solution they can find. Because in this case, they aren't simply wasting their free time - they are investing it in their future.

It should be a focused push for a few months. A period with a clear beginning and end, and a strictly defined deadline. Only in this case will the time and effort spent on LeetCode problems be an investment that pays off rather than time wasted for nothing.

Originally published at https://algobytes.net