how to become red on codeforces by Errichto Algorithms | explained simply in a blog

 Yes. I found an available transcript of the video and summarized it simply. The video is “How To Become Red Coder? (codeforces.com)” by Errichto Algorithms, and Errichto’s own Codeforces post links this video as part of his competitive programming intro resources. (Codeforces)

Main idea of the video

To become a red coder on Codeforces, there is no magic book, secret routine, or perfect roadmap. The main thing is:

Solve many problems, at the right difficulty, learn from editorials, and make sure you actually understand the solutions.

Point-by-point simple summary

1. Red coder is a very high level

Errichto says becoming red on Codeforces is like becoming a grandmaster in chess. It is not something most people reach casually. It requires serious practice. (LinkedIn)

2. The most important tip: solve problems

His biggest advice is very direct: practice by solving problems.

Do not spend too much time asking, “Which book should I read first?” or “Which algorithm should I learn first?” Instead, start solving problems. You will learn algorithms naturally when you meet them in problems. (LinkedIn)

3. Choose problems that have editorials

He recommends solving problems that have editorials/problem analyses.

Why? Because when you cannot solve a problem, the editorial becomes your teacher. It tells you the idea, the algorithm, and what you were missing. (LinkedIn)

Example: suppose a problem needs DFS and you do not know DFS. Then you should search for a DFS tutorial, learn the basics, maybe solve 2–3 DFS problems, and then return to solving random problems. (LinkedIn)

4. Do not learn every algorithm before starting

A common beginner mistake is thinking:

“First I will learn all algorithms, then I will solve problems.”

Errichto disagrees. His view is: solve problems first, and when you encounter a new concept, learn that concept then. This keeps learning practical instead of theoretical. (LinkedIn)

5. Pick problems slightly above your level

He says solving problems that are too easy is not useful because you do not learn much.

Solving problems that are too hard is also not useful because you may just waste time and get frustrated.

The best problems are slightly outside your comfort zone: hard enough to teach you something, but not so hard that you have no chance. (LinkedIn)

6. Random problems are usually better than only topic-wise practice

He says it is not always good to solve 20 problems in a row from the same topic.

Why? Because if you already know “this is a graph problem” or “this is DP,” that itself is a hint. But in a real contest, you do not get the topic tag. You have to recognize the idea yourself.

So topic practice is okay sometimes, but random practice is important because it trains real contest thinking. (LinkedIn)

7. Red coders are not all the same

He says it is not true that every red coder:

• has a computer science background,

• read the same book,

• follows the same routine,

• has some magical habit before contests.

The common thing is that they solved a lot of problems. (LinkedIn)

8. You probably do not need 5000 problems

He says you do not necessarily need to solve 5000 problems to become red. For many people, a few hundred good problems may be enough, but it depends on the person.

If someone is already strong in math, puzzles, or logical thinking, they may improve faster. But still, practice is the core. (LinkedIn)

9. Do not stay stuck forever

If you are stuck for around 20–30 minutes, especially as a beginner or intermediate coder, he recommends looking at the editorial.

But he does not mean you should instantly copy the solution. Read a little, stop when you find a new hint or idea, then try again yourself. (LinkedIn)

10. Use editorials properly

There are three levels of using an editorial:

First, read only a small hint and try again.

Second, if still stuck, read more of the explanation.

Third, if needed, read the full solution — but then implement it yourself.

Implementation is important because sometimes you think you understood the idea, but when coding you discover missing details. (LinkedIn)

11. Understanding means you can solve similar problems later

Errichto gives a simple test: after solving a problem with help, if you later see a similar problem and can solve it after some thinking, then you probably understood it.

But if you see a similar problem and still have no idea, then you did not really understand the original solution deeply enough. (LinkedIn)

12. Upsolving is important

Errichto’s related practice notes also say you should upsolve problems you missed in contests. But do not try to upsolve every impossible problem. Usually, pick one or two problems that were just above your level. (GitHub)

The video’s advice in one simple routine

Here is the practical version:

1. Take a Codeforces problem slightly above your level.

2. Try seriously for 20–30 minutes.

3. If stuck, read a small part of the editorial.

4. Try again.

5. If needed, read the full editorial.

6. Code the solution yourself.

7. Check other people’s code if your implementation was messy.

8. Later, make sure you can solve a similar problem.

9. Repeat this many times.

Final takeaway

The message of the video is:

To become red, do not search for a perfect roadmap. Solve many good problems, learn from editorials, practice slightly above your level, and make sure you truly understand each problem you solve.

3917. Count Indices With Opposite Parity (Brute Force) O(n2) + Optimized Solution O(n) + tips LEETCODE WEEKLY 500

 class Solution {

    public int[] countOppositeParity(int[] nums) {

        // approach 1 - checks every pair

        int n = nums.length;

        // i dont get the logic of how the conditions satisfy each other, and score part.

        int[] ans = new int[n];

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

            int score = 0;

            for(int j=i+1; j<n; j++) {

                // check if value parity is opp

                boolean oppositeValue = (nums[i]%2!=nums[j]%2);

                if(oppositeValue) {

                    score++;

                }

            }

            ans[i] = score;

        }

        return ans;

    }

}

// approach 2 - checks every element once

oddCount =0;

evenCount=0; for(int =n-1; i>=0; i--) { if(n%2==0) { // curr->even, it pairs with all odds to its right

ans[i] = evenCount;

oddCount++;

} else {

//curr-> odd, it pairs with all even to its right ans[i] = oddCount;

evenCount++;

} }

NEW TO TECH WORLD: natural progression path: when to choose backend, sre, platform engieering? clear all your buzzwords doubts here!

---

🤔 Feeling Confused? Good.

That’s normal.

The tech world throws around a lot of buzzwords. So instead of thinking:

“Which role should I pick forever?”

Think of it like this:

👉 You’re not choosing a floor in a building
👉 You’re choosing a position on a sports team

---

🧭 Step 1: Understand the Journey (Not the Label)

You don’t lock yourself into one role for life.

Instead, you evolve.

🚀 The Real “Elite” Path Looks Like This:

🔰 Entry Level (Years 1–2):
➡️ Backend Engineer

• You learn Java, Spring Boot
• You build real features
• You understand how apps actually work

---

🧠 Mid-Level (Years 3–5): Choose Your Direction

Ask yourself:

👉 Do I enjoy building systems/tools for others?
➡️ Go Platform Engineering (“I build the road”)

👉 Do I enjoy fixing problems and debugging systems?
➡️ Go SRE (“I fix the race car”)

👉 Do I enjoy designing and improving core logic?
➡️ Go Senior Backend (“I design the engine”)

---

🎮 Step 2: Pick Your “Vibe”

Instead of titles, ask:

“What kind of work feels fun to me?”

Role	What You Actually Do	Your Vibe
Backend Engineer	“I’m coding a Like button.”	🎨 Creator
SRE	“The Like button is slow. I fix it.”	🧩 Problem Solver (Doctor)
Platform Engineer	“I build tools so others can create Like buttons easily.”	🏗️ Architect

---

⚠️ Step 3: Important Reality Check

Trying to become SRE or Platform Engineer on Day 1?

❌ Bad idea.
You’ll get overwhelmed.

---

✅ The Smart Strategy: “Backend First”

Why Backend?

👉 Easier to get jobs

• Most fresher roles = SDE (Backend/Fullstack)

👉 Builds coding strength

• You can’t manage systems if you can’t build them

👉 Keeps doors open

• Backend ➝ Platform ✅ easy
• SRE ➝ Backend ❌ harder

---

🗺️ Step 4: Your 4.5-Year Game Plan

🎓 Step 1: BCA (Now → 1.5 Years Left)

👉 Focus: Backend Mastery

• Learn: Java + Spring Boot
• Practice: 200+ LeetCode problems

🔥 Main Target: Crack NIMCET

This is your biggest “career security” move

---

🎓 Step 2: MCA (Next 2 Years)

👉 Focus: Bridge to DevOps

• Learn: Docker, Kubernetes
• Learn: Cloud (AWS/GCP)

💡 Result:
You become:

Backend Developer + Infrastructure Knowledge = 🔥 Valuable

---

💼 Step 3: First Job (After 4.5 Years)

👉 Apply for:

• Software Engineer
• SDE-1 roles

👉 Once inside:

• Observe Platform & SRE teams
• If you like it → switch internally in ~1 year

---

🧠 Step 5: What Should You Do RIGHT NOW?

Stop this thought:

“SRE or Platform???”

That’s like asking:

“Heart surgeon or brain surgeon?”
…before learning basic biology.

---

🎯 Your ONLY job right now:

👉 Master Java + Backend

And while coding, always ask:

💡 “What if 1 million users use this?”

That one question = 🚪 Gateway to elite engineering

---

⚔️ Final Mindset

• Java = 🗡️ Your sword
• Backend = 🎯 Your first quest
• SRE & Platform = 🐉 Boss levels

You don’t skip to boss fights.
You level up first.

---

👀 Now your turn:

Which one feels unclear?

👉 The roadmap?
👉 Backend vs SRE vs Platform?
👉 Or how to actually start learning?

Tell me, and I’ll break that part down even simpler.

3Sum - Leetcode solution - How i turned into two-pointer approach?

 class Solution {

    public List<List<Integer>> threeSum(int[] nums) {

        Arrays.sort(nums); // first sort -> helps to turn into 2pointer

        List<List<Integer>> res = new ArrayList<>();

        for(int i=0; i<nums.length-2; i++) {

           

            // skip duplicates

            if(i > 0 && nums[i] == nums[i-1]) continue;

            int left = i+1;

            int right = nums.length-1;

            while(left < right) {

                int sum = nums[i] + nums[left] + nums[right];

                if(sum == 0) {

                    // add

                    res.add(Arrays.asList(nums[i], nums[left], nums[right]));

                    // skip duplicates

                    while(left < right && nums[left] == nums[left+1]) left++;

                    while(left < right && nums[right] == nums[right-1]) right--;

                    left++; right--;

                }

                // move pointers

                else if(sum < 0){

                     left++;

                     }

                else {

                    right--;

                    }

            }

        }

        return res;

       

    }

}

167. Two Sum II - Input Array Is Sorted

1. TWO POINTER APPROACH

 class Solution {

    public int[] twoSum(int[] numbers, int target) {

        // 1. two pointer approach - initialize the var.

        int left = 0;

        int right = numbers.length-1;

        // 2. while loop until pointers meet

        while(left < right) {

            int currentSum = numbers[left]+numbers[right];

            // 3. check the sum

            if(currentSum == target) {

                return new int[] {left+1, right+1}; // why we did this, Q. asked 1-indexed array, so we add +1 in our 0-idxed array

            } if(currentSum < target) {

                left++;

            } else {

                right--;

            }

        }

        return new int[] {-1, -1}; // -1 cuz exactly 1 solution

    }

   

}

2.

1. TWO POIN1. TWO POINTER APPROACHTER APPROACH

Next Greater element 1 - monotonic stack problem - LEETCODE 496

class Solution {

    public int[] nextGreaterElement(int[] nums1, int[] nums2) {

        HashMap<Integer, Integer> map = new HashMap();

        Deque<Integer> stack = new ArrayDeque<>(); // faster than stack

        for(int num : nums2) { // scans each no. in nums2

           

            while(!stack.isEmpty() && stack.peek() < num) {

                map.put(stack.pop(), num);

            }

            stack.push(num);

           

        }

        int[] result = new int[nums1.length]; // num1 jitna length ka answer hona chaiye!

       

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

            result[i] = map.getOrDefault(nums1[i], -1); // if it exists, return value nums1[i] else return -1

        }

        return result;

       

           

        }

    }

Encode and Decode Strings - NeetCode.IO Solution by me + gemini pro 3.0 explained

 class Solution {

        // encode: List of Strings -> String

    public String encode(List<String> strs) {

        StringBuilder sb = new StringBuilder();

        for(String str : strs) {

            // Pattern: Length + Delimiter # + String

            sb.append(str.length()).append("#").append(str);

        }

        return sb.toString(); // return in String

    }

        // decode: String -> List of Strings

    public List<String> decode(String str) {

        List<String> res = new ArrayList<>(); // store res

        int i = 0; // var. for loop

        while(i < str.length()) {

            // 1. find delimitter to get length prefix

            int slash = str.indexOf('#', i);

            // 2. parse the length from characters between i and slash

            int length = Integer.parseInt(str.substring(i, slash));

            // 3. store extractedStr

            String extString = str.substring(slash + 1, slash + 1 + length);

            res.add(extString);

            // 4. move the pointer 'i' to the start of next encoded_String

            i = slash + 1 + length;

        }

        return res;

    }

}