Valid Parentheses Problem Solved with Stack

𝐃𝐚𝐲 𝟑𝟏/100 𝐨𝐟 𝐃𝐒𝐀 ✨ Hello Everyone 👋 It’s Day 31 of my #100daysofcode journey, Today was less about writing fast code and more about choosing the correct approach instead of forcing patterns that don’t fit. 🧠 𝐏𝐫𝐨𝐛𝐥𝐞𝐦𝐬 𝐖𝐨𝐫𝐤𝐞𝐝 𝐎𝐧: 🔹 Koko Eating Bananas A problem that highlights how searching the answer space can be smarter than iterating blindly. 🔹 Longest Balanced Subarray I A tricky problem that teaches the difference between frequency and distinctness in subarrays. What I understood today: • Why some problems require Binary Search on Answer instead of brute force • How feasibility checks guide the search efficiently • Why distinct counts cannot be handled with prefix sums or sliding windows • How edge cases expose incorrect assumptions in logic • Why brute force is sometimes the intended and correct solution • That passing most test cases doesn’t mean the approach is correct 🧠 𝐓𝐨𝐝𝐚𝐲’𝐬 𝐅𝐨𝐜𝐮𝐬: ✔️ Understanding problem constraints deeply ✔️ Validating logic with edge cases ✔️ Avoiding over-optimization too early ✔️ Strengthening reasoning around arrays and subarrays Simple-looking problems don’t test coding speed — they test clarity of thought. Learning slowly. Understanding deeply. Improving daily ✨ Always open to feedback and discussions. Follow if you find this useful and relatable 🙌 #Day31 #DSA #LeetCode #BinarySearch #Arrays #ProblemSolving #LearningInPublic #100DaysOfCode

I recently crossed 600+ problems solved on LeetCode. But more than the number, this milestone reflects how my thinking has evolved. Here are a few key learnings from this journey: • Patterns matter more than problems Most questions are variations of a core idea — sliding window, two pointers, DP, binary search, graphs. Once the pattern clicks, new problems feel familiar. • Medium > Easy Easy builds confidence. Medium builds real interview strength. Spending time struggling with Medium problems gave me the biggest growth. • Struggling is part of the process Earlier, getting stuck felt frustrating. Now I’ve learned: If a problem takes 30–60 minutes of thinking, that’s where the actual learning happens. • Writing clean logic matters It’s not just about passing the test cases — it’s about writing code that is structured, readable, and optimized. • Consistency beats intensity A few problems daily > long irregular sessions. Still a long way to go, but the goal is simple — become a better problem solver every day. #LeetCode #DSA #CodingJourney #SoftwareEngineering #ProblemSolving #Consistency #Learning

Today I worked on a problem that asked: “Minimum operations to make an array continuous.(LeetCode 2009)” At first glance, it seemed straightforward just handle duplicates, maybe use a hash map, adjust a few numbers. But that approach didn’t fully solve it. The real learning moment was realizing: It’s not about what you change. It’s about what you can keep. Instead of focusing on replacements, I had to step back and rethink the structure: • Sort the array • Remove duplicates • Use a sliding window to find the largest valid range That shift in perspective made everything clearer. This problem reminded me that writing more code isn’t the same as writing the right code. Sometimes the real challenge is stepping back and asking, “Am I even approaching this the right way?” Getting stuck doesn’t mean you’re not improving , it usually means you’re learning something deeper. The more problems I solve, the more I start noticing patterns. Things that once felt random now make a little more sense. #DSA #LeetCode #ProblemSolving #LearningJourney #Consistency #Growth

🚀 #Day98 of my #100DaysCodingChallenge Today, I solved an interesting simulation + observation based problem related to circular traversal — Most Visited Sector in a Circular Track. This problem looks tricky at first, but once you observe the pattern, the solution becomes clean and elegant. 🔹 Problem: Most Visited Sector in a Circular Track Problem Statement: - You are given: (i) An integer n representing the number of sectors on a circular track (labeled 1 to n) (ii) An array rounds where each element represents the sector visited in order during a marathon Your task is to return all sectors that were visited the maximum number of times, in ascending order. ✅ Approach: The key insight here is: 👉 The most visited sectors are always those between the starting sector and the ending sector of the marathon path. Why? (a) Every round starts from rounds[i] and ends at rounds[i+1] (b) All intermediate sectors get covered uniformly (c) Only the path from the first sector to the last sector determines the maximum visits Steps: (1) Identify start = rounds[0] (2) Identify end = rounds[last] (3) If start ≤ end → sectors are simply [start … end] (4) If start > end → wrap around the circular track: [start … n] and [1 … end] (5) Finally, sort the result (as required by the problem) ⏳ Time Complexity: O(n) At most, we traverse all sectors once. 📦 Space Complexity: O(n) To store the result list. 💡 Key Takeaways ✔ Recognizing patterns avoids unnecessary simulation ✔ Circular problems often reduce to range analysis ✔ Sorting may still be required even after correct traversal ✔ Clean logic beats brute-force counting ✔ Frequently asked problem to test observation skills This problem was a great reminder that thinking before coding can dramatically simplify the solution. Grateful to Abhishek Kumar Sir and K R Mangalam University for their continuous support and guidance 🙌 #100DaysOfCode #Day98 #Java #DSA #Arrays #Simulation #ProblemSolving #InterviewPreparation #CodingChallenge #LeetCode #KRMangalamUniversity

🚀 Day 5 of 90 Days LeetCode Challenge 📌 Problem: Permutations II (Backtracking | Medium) Today’s problem looked simple at first , generate all permutations. But the twist was duplicates. And that’s where the real thinking started. 🔍 Key Observation When the input contains duplicate numbers, normal permutation logic creates repeated results. So the goal isn’t just to generate permutations ... 👉 it’s to generate only unique permutations efficiently. 💡 Core Insight 1️⃣ Sort the array first This brings duplicate numbers together and makes pruning possible. 2️⃣ Track used elements A boolean used[] array ensures each index is used only once per permutation. 3️⃣ Prune duplicate paths 🧠 Approach (Backtracking) 1. Build permutations step by step 2. At each level, try all unused numbers 3. Skip duplicates using the pruning rule 4. When the permutation length equals n, store it Simple idea. Powerful optimization. 📈 What I Learned Today ✅ How sorting simplifies duplicate handling ✅ Why pruning is essential in backtracking ✅ How small conditions can save exponential work One problem. Multiple insights. Consistency over motivation. 🔁 Day 5 done. On to Day 6. If you’re also grinding LeetCode or learning DSA drop a comment or connect 🤝 Let’s grow together 💻🔥 #90DaysOfLeetCode #Day5 #Backtracking #DSA #Java #ProblemSolving #Consistency #CodingJourney

𝗙𝗶𝗿𝘀𝘁 𝗣𝗼𝘀𝘁! 🚀 𝟯/𝟰 𝗦𝗼𝗹𝘃𝗲𝗱 𝗶𝗻 𝗪𝗲𝗲𝗸𝗹𝘆 𝗖𝗼𝗻𝘁𝗲𝘀𝘁 𝟰𝟴𝟲 (𝗥𝗮𝗻𝗸 𝟰𝟮𝟴𝟭) I’ve been a bit shy about documenting my journey publicly, but I decided it’s time to step out of my comfort zone and celebrate the small wins. I had a solid run in today’s LeetCode contest. I actually solved the problems in 40 mins, but a 5-minute penalty on Q2 (due to a Runtime Error) pushed my official time to 45 minutes. Here is a quick breakdown of my approach: 𝗤𝟭: 𝗠𝗶𝗻𝗶𝗺𝘂𝗺 𝗣𝗿𝗲𝗳𝗶𝘅 𝗥𝗲𝗺𝗼𝘃𝗮𝗹 Used a Reverse Greedy strategy. Scanning from n-1 down to 0 allows you to instantly find the first index where the strictly increasing order breaks. O(N) time, no extra space. 𝗤𝟮: 𝗥𝗼𝘁𝗮𝘁𝗲 𝗡𝗼𝗻-𝗡𝗲𝗴𝗮𝘁𝗶𝘃𝗲 𝗘𝗹𝗲𝗺𝗲𝗻𝘁𝘀 I extracted the non-negative numbers into a vector b. To rotate it without extra space, I used a manual sequence: calculated p = k % b.size(), pushed the first p elements to the back, reversed the vector, popped the excess, and reversed it back. Finally, I replaced the original non-negative elements in the main array with these new values. The Mistake: I missed the check for b.size() == 0 before calculating the modulo, which caused a Division by Zero crash. 𝗤𝟯: 𝗣𝘆𝘁𝗵𝗮𝗴𝗼𝗿𝗲𝗮𝗻 𝗗𝗶𝘀𝘁𝗮𝗻𝗰𝗲 𝗡𝗼𝗱𝗲𝘀 Standard Multi-Source DFS. I ran the traversal three times to get distances from X, Y, and Z. For each node, I collected the three distances, sorted them to find the hypotenuse, and then checked the theorem (a² + b² = c²). Feels good to finally break the ice on LinkedIn. Let’s see how the consistency goes. Happy Coding! 💻 #LeetCode #TLEEliminators #DSA #CompetitiveProgramming #CPP #Algorithms #SDE #FirstPost #ProblemSolving

🚀 Day 28/30 FastAPI: 𝗔𝘂𝘁𝗼𝗺𝗮𝘁𝗶𝗻𝗴 𝗤𝘂𝗮𝗹𝗶𝘁𝘆 𝘄𝗶𝘁𝗵 𝗚𝗶𝘁𝗛𝘂𝗯 𝗔𝗰𝘁𝗶𝗼𝗻𝘀 Manual testing is a bottleneck. Today, I moved to the “Auto-pilot” phase of development by setting up a 𝗖𝗜/𝗖𝗗 𝗣𝗶𝗽𝗲𝗹𝗶𝗻𝗲. ✅ What I Learned Today: 𝗚𝗶𝘁𝗛𝘂𝗯 𝗔𝗰𝘁𝗶𝗼𝗻𝘀 𝗪𝗼𝗿𝗸𝗳𝗹𝗼𝘄𝘀: I learned how to write 𝗬𝗔𝗠𝗟 files that tell 𝗚𝗶𝘁𝗛𝘂𝗯 exactly how to build and test my application. 𝘂𝘃 𝗶𝗻 𝘁𝗵𝗲 𝗖𝗹𝗼𝘂𝗱: I integrated the 𝘀𝗲𝘁𝘂𝗽-𝘂𝘃 𝗮𝗰𝘁𝗶𝗼𝗻, which makes my CI pipeline incredibly fast compared to traditional 𝗽𝗶𝗽-𝗯𝗮𝘀𝗲𝗱 setups. ⚡ 𝗔𝘂𝘁𝗼𝗺𝗮𝘁𝗲𝗱 𝗧𝗲𝘀𝘁𝗶𝗻𝗴: Now, every 𝘗𝘶𝘭𝘭 𝘙𝘦𝘲𝘶𝘦𝘴t is automatically checked. If a test fails, I can’t merge the code. This is how you maintain high-quality software at scale. 𝗟𝗶𝗻𝘁𝗶𝗻𝗴 & 𝗙𝗼𝗿𝗺𝗮𝘁𝘁𝗶𝗻𝗴: I added a “𝗥𝘂𝗳𝗳” check to the pipeline to ensure my code style stays consistent and professional automatically. 🛠️ The Tech Progress: My workflow is now “Push and Forget.” GitHub acts as my 24/7 quality assurance team. We are only 2 days away from the finish line! More detailed and technical article on my blog 𝗕𝗲𝘆𝗼𝗻𝗱𝟰𝟬𝟬: https://lnkd.in/eiUUnydC #FastAPI #GitHubActions #CICD #Python #30DaysOfCode #DevOps #Automation #uv #BackendDevelopment #WebDevelopment #LearningInPublic

SWE-bench Lite — The Fast Lane Scenarios: When teams need quick feedback while building coding agents When researchers want cheap, repeatable evaluations When iterating daily without running massive benchmarks Definition: SWE-bench Lite is a 300-task curated subset of the original SWE-bench benchmark, designed to evaluate real software engineering ability faster and cheaper, while still using real GitHub issues and codebases. Analogy: Full SWE-bench is a full marathon. Verified is a championship race with strict judges. Lite is a time-trial track — shorter, faster, but still demanding skill. Real-Time Example: An agent is tested on 300 real GitHub issues from Django, scikit-learn, pytest, etc., producing code patches that must pass FAIL_TO_PASS unit tests — but the entire run completes in hours instead of days. Conditions & Usage: Dataset size: 300 tasks (+ ~23 dev split) Built via heuristic filtering, not human validation Removes brittle test patterns (e.g., exact error-message matching) Covers 11 of the 12 original Python repositories Typically 5–10× faster to evaluate than full SWE-bench Dos and Don'ts: Do use Lite for rapid prototyping and ablation studies Do use it for CI-style regression checks on agents Don’t claim true SOTA using Lite alone Don’t compare Lite scores directly to Verified scores Cheat Sheet: Lite → 300 tasks Verified → 500 human-validated tasks Full → 2,294 raw tasks Lite difficulty → medium Lite goal → speed Tips & Tricks: Run Lite weekly; run Verified monthly Track trend improvements, not absolute percentages Use Lite to debug agent failures before expensive runs Memory Trick: “Lite = iterate fast, learn fast” Questions and Answers: Q: Is SWE-bench Lite easier than Verified? A: Yes — it filters out many noisy cases and skews slightly easier. Q: Why still use Lite in 2026? A: Because it gives realistic signal at a fraction of the cost and time. key learning s: SWE-bench Lite enables fast, affordable evaluation Uses real repos and real tests, not synthetic tasks Not human-verified, but far cleaner than the full set Ideal for development loops, not final claims Hashtags: #SWEBenchLite, #CodingAI, #AgenticAI, #LLMBenchmarks, #AIForDevelopers, #OpenSourceAI, #SoftwareEngineering, #FutureOfAI

I’ve solved 200+ questions on LeetCode, and here’s what I’ve actually learned 1️⃣ Don’t solve the whole problem at once Break the problem statement into small chunks. Understanding comes before coding. 2️⃣ Stop judging problems by tags or difficulty Don’t assume you can’t solve a “Hard” or that failing an “Easy” means you’re bad. Difficulty is subjective : it depends on whether you’ve seen the pattern before. 3️⃣ Struggle before you look at solutions Give at least 30 minutes. Even after watching the approach, try coding it yourself just by understanading the algorithm and only watch the solution if you cant solve it dont just sit and watch the solutions Passive watching = false confidence. 4️⃣ Dry run is non-negotiable It’s boring. It’s tricky. But this is where real understanding happens. Skipping it is the fastest way to think you’re learning without actually learning. 5️⃣ Revise using active recall During revision, try recalling the logic just from the problem name : without opening the statement. This forces your brain to retrieve patterns, not recognize them. DSA is less about intelligence and more about how you practice. What’s one thing LeetCode taught you the hard way ? #DataStructures #Algorithms #LeetCode #DSA #LearningInPublic #ProblemSolving #SoftwareEngineering #CodingJourney #DeveloperLife

Day 48/100 – #100DaysOfLeetCode 🚀 🧩 Problem: LeetCode 338 – Counting Bits (Easy) 🧠 Approach: For each number from 0 to n, count the number of set bits using the trick x & (x - 1), which removes the lowest set bit in each step. 💻 Solution: class Solution:   def countBits(self, n: int) -> List[int]:     counts = [0]     for i in range(1,n+1):       count=0       while i:         i&=(i-1)         count+=1       counts.append(count)     return counts ⏱ Time | Space: O(n log n) | O(n) 📌 Key Takeaway: The bit manipulation trick x & (x - 1) efficiently removes the lowest set bit and helps count 1's in binary representation. #leetcode #dsa #development #problemSolving #CodingChallenge