Reverse Nodes in k-Groups in Linked List

🌟 Day 69 of #100DaysOfCode 🌟 🔗 Remove Linked List Elements – Clean-Up Operation in Linked Lists 🔹 What I Solved Today’s challenge focused on cleaning up a linked list by removing all nodes that match a given value. Given the head of a singly linked list and an integer val, the task was to delete every node whose value equals val and return the updated list. This problem is a great test of pointer handling, edge-case management, and safe deletion logic in linked lists. 🧩 Problem: Remove Elements from Linked List 💡 Given: A singly linked list An integer val 💥 Goal: Traverse the list and remove all nodes whose value equals val, while keeping the remaining list structure valid. 🧠 Concepts Used ➡️ Dummy Node Technique A dummy node before the head simplifies deletions, especially when the head itself needs to be removed. ➡️ Linked List Traversal Move through the list node by node while checking the next pointer. ➡️ Pointer Manipulation If a node needs to be deleted, redirect pointers to skip it safely. ➡️ Edge Case Handling Handles: Empty list Head node deletion All nodes matching val ✔️ Time Complexity: O(n) ✔️ Space Complexity: O(1) ⚙️ Approach 1️⃣ Create a dummy node pointing to head 2️⃣ Use a pointer curr starting from the dummy 3️⃣ If curr.next.val == val, skip that node 4️⃣ Otherwise, move curr forward 5️⃣ Return dummy.next as the new head 🚀 Learning This problem reinforced: ✔️ Clean and safe deletion logic ✔️ The power of dummy nodes ✔️ Pointer discipline in linked lists ✔️ Edge-case–driven problem solving ✔️ Writing concise and interview-ready solutions #CodingLife #Programmer #LeetCode #GeeksForGeeks #LinkedList #ProblemSolver #CleanCoding #SkillUp

🌟 Day 73 of #100DaysOfCode 🌟 🔗 Move the Last Node to the Front – A Simple Yet Powerful Linked List Pattern! 🔹 What I Solved Today’s challenge focused on an elegant linked list manipulation where the last node is moved to the front. This problem may look simple, but it strengthens understanding of pointer traversal and last-node handling — techniques that are frequently tested in interviews. 🧩 Problem: Move Last Node to Front of Linked List 💡 Given: A linked list such as: 2 → 5 → 6 → 2 → 1 💥 Goal: Take the last node of the list and move it to the front, returning the modified list — all in O(n) time and O(1) space. 📌 Example 1 Input: 2 → 5 → 6 → 2 → 1 Output: 1 → 2 → 5 → 6 → 2 📌 Example 2 Input: 2 Output: 2 (Only one node → no change) 🧠 Concepts Used ➡️ Pointer Traversal Traverse the list to find the last and second-last nodes. ➡️ Re-linking Pointers Detach the last node and connect it before the head. ➡️ Edge Case Handling If the list has only one node, return it as-is. ➡️ Efficient Logic Single traversal → O(n) time No extra memory → O(1) space ⚙️ Approach 1️⃣ Traverse to the second-last node 2️⃣ Separate the last node 3️⃣ Point the last node to the current head 4️⃣ Update head to the last node 5️⃣ Return the modified list 🚀 Learning This problem helped improve my understanding of: ✔️ Boundary cases in linked lists ✔️ Precise pointer manipulation ✔️ Clean and optimal transformations ✔️ Writing space-efficient code ✔️ Thinking in terms of node connections #CodingLife #Programmer #LinkedList #GeeksForGeeks #JavaDeveloper #StudentCoder #ProblemSolving

Optimization Matters: How I solved LeetCode 1390 (Four Divisors) 🚀 When solving algorithmic problems, the difference between a "working" solution and an "accepted" solution usually comes down to one thing: Time Complexity. The Challenge: The problem asks for the sum of divisors of numbers that have exactly four divisors. With values up to 10⁵and an array size of 10⁴, a brute-force approach (checking every number from 1 to n for every element) would result in O(N×M) complexity. In the worst case, that's 10⁹ operations—way too slow for most environments. My Evolution of Logic: Initially, I considered a simple linear scan for divisors. However, I realized I needed a more mathematical approach to stay within the time limits. The Optimized Approach: I shifted to a Square Root of x optimization. Here’s why it works: Divisor Pairs: Divisors always appear in pairs. For a number x, if i is a divisor, then x/i is also a divisor. One will always be < √xand the other will be >=√x Efficiency: By only iterating up to √x, I reduced the operations per number from 100,000 to just 316. The Logic: Loop from 1 to √x If (x% i == 0), identify if it’s a perfect square (i == x/i) or a distinct pair. Early Exit: If the divisor count exceeds 4, I immediately break the loop. This "pruning" saves significant CPU cycles. Only if the final count is exactly 4, do I add the sum to the total. Key Takeaway: Writing code that works is the first step, but writing code that is performant is the goal. This approach brought the complexity down to O(N√M}), making the solution run almost instantly. #SoftwareEngineering #Coding #Optimization #Java #LeetCode #DSA #ContinuousLearning #DailyCoding #LeetCodeChallenge

Sometimes the most satisfying code isn’t the most complex , it’s the most intentional. Why this approach feels right: Elegant method chaining Pure function -> predictable & testable Self-documenting logic Edge cases handled without noise Reads like a data pipeline, not a puzzle Each step does one thing. No mutation. No magic. Just clarity. This is the kind of code you enjoy coming back to months later, and that's why I love functional programming... Readable code is a feature. #TypeScript #CleanCode #FunctionalProgramming #MethodChaining #SoftwareEngineering #AIEngineering #WebDevelopment #DeveloperLife

𝗧𝗵𝗶𝗻𝗸𝗶𝗻𝗴 𝗕𝗲𝘆𝗼𝗻𝗱 𝘁𝗵𝗲 𝗗𝗶𝘃𝗶𝘀𝗶𝗼𝗻 𝗢𝗽𝗲𝗿𝗮𝘁𝗼𝗿 I recently tackled the "Product of Array Except Self" problem. My first instinct? Use the division operator. It’s quick, but it's brittle, especially if your data contains a zero. I challenged myself to find a more robust way and discovered the Prefix & Suffix product pattern. Instead of looking at the whole array at once, you calculate the product of everything to the left, then everything to the right. The Results: Logic: O(n) time complexity. Efficiency: O(1) extra space (excluding the output array). Reliability: Handles zeros perfectly without crashing. It’s a powerful reminder that sometimes the most obvious tool isn't the most effective one. I'm learning how to write code that doesn't just work, but scales. #Java #LeetCode #SoftwareEngineering #ProblemSolving #Algorithms #CleanCode #GrowthMindset

🌟 Day 71 of #100DaysOfCode 🌟 🔗 Count Occurrences of a Given Key in a Linked List – Simple but Powerful! 🔹 What I Solved Today’s challenge focused on traversing a singly linked list and counting how many times a specific value (key) appears. Even though it looks simple, this problem strengthens fundamentals like traversal, pointer handling, and space-optimized logic. 🧩 Problem: Count Occurrences of a Key in a Linked List 💡 Given: A singly linked list such as: 1 -> 2 -> 1 -> 2 -> 1 -> 3 -> 1 and a key, for example 1. 💥 Goal: Return the total number of times the key appears in the list. For the example above, the output is 4. 🧠 Concepts Used ➡️ Linked List Traversal Iterating through nodes one by one from head to end. ➡️ Constant Space Counting Only one integer counter is used — O(1) extra space. ➡️ Linear Time Complexity Each node is visited once — O(n). ➡️ Comparison Logic At each node, compare node.data with the key and increment the count. ⚙️ Approach 1️⃣ Start with the head of the list 2️⃣ Initialize a counter count = 0 3️⃣ Traverse each node using a loop 4️⃣ If node.data == key, increment count 5️⃣ Continue until the list reaches null 6️⃣ Return the counter 🚀 Learning This problem reinforced: ✔️ Clean linked list traversal ✔️ Handling edge cases (empty list, key not present) ✔️ Writing efficient and readable code ✔️ Understanding time & space optimization ✔️ Strengthening core DSA fundamentals #CodingLife #Programmer #LeetCode #GeeksForGeeks #JavaDeveloper #StudentCoder #LearnToCode #DeveloperCommunity #ProblemSolver #CleanCoding #LinkedList

🔄 LeetCode Journey — Problem 25: Reverse Nodes in k-Group Solved Reverse Nodes in k-Group, one of the most challenging linked list problems that truly tests pointer control, iteration, and edge-case handling. 🔍 Key Insights Reversal must happen only when k nodes are available. Dummy nodes help manage head changes cleanly. Careful pointer updates allow in-place reversal without extra space. 🧠 What I Learned How group-wise reversal differs from partial and full reversals. Why validating node count before reversing is crucial. Improved confidence in complex linked list manipulation. 📌 Takeaway This problem reinforces that linked lists are all about pointer discipline. Once the flow clicks, the solution becomes clean and reusable for similar patterns. #leetcode #dsa #linkedlist #java #coding #problemsolving #interviewprep #datastructures #softwareengineering #logicbuilding #100DaysOfCode #developers #codingjourney

If you are learning recursion and you start procrastinating when you see too many function calls, then the truth is — the concept is already slipping away. Recursion is not meant to be memorized. It is meant to be seen and understood. 👉 That’s why debugging is extremely important. When you debug recursion in IntelliJ IDEA, you can: watch how every function call is pushed into the stack understand why the stack grows step by step clearly see when and how values return remove confusion between base case and recursive call 🟢 How to Open Debugging (IntelliJ IDEA) Debug current file → Shift + F9 Toggle Breakpoint → Ctrl + F8 🔑 Most Important Debugging Keys Step Into → F7 (go inside recursive call) Step Over → F8 (skip internal execution) Step Out → Shift + F8 (come back from function) Resume Program → F9 If you avoid watching every function call because “it feels slow” or “boring”, then recursion will never feel clear. Slow debugging = strong concepts. Fast coding = weak understanding. Let the call stack teach you recursion. #Recursion #Debugging #IntelliJIDEA #DSALearning #CallStack #JavaStudents #LearnByDoing #ProgrammingJourney #StudentDeveloper

Day 338: Leveling Up: Print vs. Logging 📊 Why I Stopped Using print() for Debugging When I started coding, I used print("Here 1"), print("Here 2") to find bugs. It worked, but it was messy. In production environments, you can't stare at the console. You need logging. The logging module lets you leave "breadcrumbs" in your code. You can save them to a file to see exactly what happened at 3:00 AM when your script crashed. 👉 A Professional Setup: import logging # Configure it to save to a file logging.basicConfig(filename='app.log', level=logging.INFO) def process_payment(amount): logging.info(f"Attempting to process ${amount}...") # Logic here... logging.error("Payment Gateway Timeout!") # This gets saved for later inspection process_payment(50) challenge: Go back to an old script and replace your print statements with logging.info(). It’s a game changer. #Python #DevOps #SoftwareEngineering #BestPractices

𝗗𝗮𝘆 𝟮𝟳/𝟭𝟬𝟬 | 𝗗𝗲𝗰𝗼𝗱𝗲 𝗦𝘁𝗿𝗶𝗻𝗴 Day 27 ✅ — When recursion makes everything elegant. 𝗧𝗼𝗱𝗮𝘆'𝘀 𝗣𝗿𝗼𝗯𝗹𝗲𝗺: ✅ 𝗣𝗿𝗼𝗯𝗹𝗲𝗺 #𝟯𝟵𝟰: Decode String (Medium) 𝗪𝗵𝗮𝘁 𝗖𝗹𝗶𝗰𝗸𝗲𝗱: Decode strings like "3[a2[c]]" → "accaccacc". Numbers indicate repetition, brackets show nested patterns. My first thought? Stack. But then I realized: nested brackets = 𝗿𝗲𝗰𝘂𝗿𝘀𝗶𝗼𝗻 territory. Each time I hit '[', recursively decode what's inside. When I hit ']', return to the outer level. The recursion naturally handles the nesting. 𝗠𝘆 𝗔𝗽𝗽𝗿𝗼𝗮𝗰𝗵: 👉 Build number from consecutive digits 👉 When '[' appears, recursively decode inner string 👉 Repeat the decoded string by the number 👉 When ']' appears, return result to caller 👉 Regular characters get appended directly Time: O(maxK × n) where maxK is max repeat count, Space: O(n) for recursion stack 𝗠𝘆 𝗥𝗲𝗮𝗹𝗶𝘇𝗮𝘁𝗶𝗼𝗻: Recursion isn't just for trees and graphs—it's for any problem with 𝗻𝗲𝘀𝘁𝗲𝗱 𝘀𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲𝘀. The key: recognize when a subproblem looks exactly like the main problem. That's your recursion signal. 27 days in, and I'm getting more comfortable with recursive thinking. 𝗖𝗼𝗱𝗲: https://lnkd.in/gFfUH6bk 𝟮𝟳 𝗱𝗮𝘆𝘀 𝘀𝘁𝗿𝗮𝗶𝗴𝗵𝘁. 𝗔𝗹𝗺𝗼𝘀𝘁 𝗮 𝗺𝗼𝗻𝘁𝗵. Every problem teaches a pattern. Every pattern becomes a tool. 𝗗𝗮𝘆 𝟮𝟳/𝟭𝟬𝟬 ✅ | 𝟳𝟯 𝗺𝗼𝗿𝗲 𝘁𝗼 𝗴𝗼! #100DaysOfCode #LeetCode #Recursion #StringManipulation #DataStructures #CodingInterview #TechnicalInterview #SoftwareEngineer #FAANG #ProblemSolving #Algorithms #Java #Programming #ComputerScience #DeveloperJourney #LearnInPublic #SoftwareDevelopment #CodingSkills #TechJobs #CareerGrowth