Why HashMap is More Efficient than Arrays for Frequency Counting

🚀 Day 17 – equals() and hashCode(): A Crucial Contract Today I explored why "equals()" and "hashCode()" are so important—especially when using collections like "HashMap" or "HashSet". --- 👉 By default: - "equals()" → compares object references - "hashCode()" → generates a hash based on memory location But in real applications, we override them. --- 💡 The contract I learned: ✔ If two objects are equal using "equals()", they must have the same "hashCode()" --- ⚠️ What happens if we break this? - "HashMap" may fail to retrieve values - Duplicate entries may appear in "HashSet" - Leads to very tricky bugs --- 👉 Example scenario: Two objects look identical (same data), but: - "equals()" returns true - "hashCode()" is different 👉 Result: Collections treat them as different objects 😬 --- 💡 Real takeaway: Whenever overriding "equals()", always override "hashCode()" properly. This is not just theory—it directly impacts how collections behave internally. #Java #BackendDevelopment #HashMap #JavaInternals #LearningInPublic

First Missing Positive — Not as Simple as It Looks At first glance, this problem looks simple. A natural instinct is to solve it using a hashmap or a set to track elements. But that approach won’t work here. The problem strictly requires: O(n) Time Complexity O(1) Space Complexity So we need a different way of thinking. The key idea is to use the input array itself as a marker instead of extra space. Approach: Clean the array Replace all negative numbers, zeros, and values greater than n with n + 1 Because the answer will always lie in the range [1, n+1] Mark presence using indices For every number num, mark the index num - 1 as negative This indicates that the number exists in the array Identify the missing number The first index that has a positive value gives the answer (index + 1) Edge case If all indices are marked, then the answer is n + 1 Why this works: We reuse the given array, so no extra space is needed. Each element is processed a constant number of times, ensuring linear time. Insight: This problem shows how constraints change your approach. A hashmap solution is straightforward, but it violates the space requirement. Sometimes the optimal solution comes from rethinking how to use the existing data instead of adding new structures. #DataStructures #Algorithms #Java #CodingInterview #ProblemSolving

Day 25 of my #30DayCodeChallenge: The Art of Categorization! The Problem: Group Anagrams. Given an array of strings, group the words that are rearrangements of each other. The Logic: This problem is a perfect example of using Hashing and Canonical Forms to organize unstructured data efficiently. 1. Identifying the "Signature": The core challenge is realizing that all anagrams, when sorted alphabetically, become the exact same string. I used this "sorted version" as a unique key (the signature) for each group. 2. The Hash Map Strategy: I utilized a HashMap<String, List<String>>. Key: The sorted version of the word. Value: A list of all original words that match that sorted key. 3. Efficient Lookups: Using computeIfAbsent, I streamlined the process of initializing lists and adding words in a single pass. This keeps the code clean and the logic tight. Complexity Analysis: Time Complexity: O(N Klog K), where N is the number of strings and K is the maximum length of a string (due to sorting). Space Complexity: O(N K) to store the grouped strings in our map. One step closer to mastery. Onward to Day 26! #Java #Algorithms #DataStructures #Hashing #ProblemSolving #150DaysOfCode #SoftwareEngineering

🚀 Day 19 of Consistency – Optimized “Intersection of Two Arrays II” (LeetCode) Today I pushed one step further and solved a variation where duplicates also matter — making it slightly more challenging and interesting. 🔍 Problem Understanding Given two arrays, return their intersection including duplicates. Each element should appear as many times as it shows in both arrays. 🧠 Initial Thought (Brute Force) Compare each element of one array with another Track used elements manually ⛔ Inefficient due to nested loops → O(n × m) ⚡ Optimized Approach (HashMap – Frequency Count) 👉 This time, I used a smarter strategy: Store frequency of elements from nums1 in a HashMap Traverse nums2 If element exists in map and count > 0: Add to result Decrease frequency 💡 Example nums1 = [1,2,2,1] nums2 = [2,2] Output → [2,2] ⏱ Complexity Analysis Time Complexity: O(n + m) Space Complexity: O(n) 📊 Result ✔️ All test cases passed (61/61) ⚡ Runtime: 3 ms 🔥 Beats 95.42% submissions 🧩 Key Learning HashMap is extremely useful for frequency-based problems Handling duplicates = tracking counts properly Small optimization can drastically improve performance 🙏 Grateful for the journey and learning every single day 🔥 Consistency + Optimization = Growth mindset #DSA #Java #LeetCode #CodingJourney #HashMap #ProblemSolving #100DaysOfCode #SoftwareDeveloper

🚀 𝗗𝗦𝗔 𝗣𝗮𝘁𝘁𝗲𝗿𝗻 𝗦𝗲𝗿𝗶𝗲𝘀 – 𝗗𝗮𝘆 4 𝗣𝗿𝗼𝗯𝗹𝗲𝗺 2 – 𝐂𝐨𝐧𝐭𝐚𝐢𝐧𝐬 𝐃𝐮𝐩𝐥𝐢𝐜𝐚𝐭𝐞 (𝐋𝐞𝐞𝐭𝐂𝐨𝐝𝐞 217) Continuing Day 3 of Array + Hashing with one of the question highlights the power of HashMap for efficient lookups 👇 🔍 𝐏𝐫𝐨𝐛𝐥𝐞𝐦 𝐒𝐭𝐚𝐭𝐞𝐦𝐞𝐧𝐭: Given an integer array nums, return true if any value appears at least twice, and false if all elements are distinct. 💡 𝐀𝐩𝐩𝐫𝐨𝐚𝐜𝐡 (𝐔𝐬𝐢𝐧𝐠 𝐇𝐚𝐬𝐡𝐌𝐚𝐩): • Traverse the array once • Store each element as a key in HashMap • Before inserting, check if it already exists • If it exists → duplicate found → return true ⚡ 𝐓𝐢𝐦𝐞 & 𝐒𝐩𝐚𝐜𝐞 𝐂𝐨𝐦𝐩𝐥𝐞𝐱𝐢𝐭𝐲: • Time Complexity: O(n) • Space Complexity: O(n) 🧠 𝐊𝐞𝐲 𝐋𝐞𝐚𝐫𝐧𝐢𝐧𝐠𝐬: • HashMap provides O(1) average lookup time • Optimizes brute force from O(n²) → O(n) • Common problem in Array + Hashing pattern 📸 𝐒𝐨𝐥𝐮𝐭𝐢𝐨𝐧 𝐒𝐜𝐫𝐞𝐞𝐧𝐬𝐡𝐨𝐭: Attached. 🔥 Small problems, big learning. Consistency builds confidence! #DSAPatternSeries #DSA #LeetCode #Java #CodingJourney #ProblemSolving #100DaysOfCode #Tech #DSAPattern_Day4 #containsDuplicate #P_Pranjali

A “small bug” once cost almost a full day. Not because it was complex. Because it was invisible. Everything looked fine: • API responses were correct • database had valid data • no errors in logs But users were seeing wrong results. After hours of tracing, the issue was: A single condition checking the wrong type. Python if status == "1": The actual value was an integer. So the condition silently failed. No crash. No warning. Just wrong behavior. That day changed how I write backend code. Now I double-check: • data types • implicit conversions • assumptions Because real bugs are rarely dramatic. They’re subtle. What’s the smallest mistake that caused the biggest issue for you? #PythonDeveloper #Debugging #BackendBugs #SoftwareEngineering #DjangoDeveloper #RealWorldCoding #DevLife

Most developers say HashMap operations are O(1). That’s not always true. And this misunderstanding shows up in interviews and real systems. Let’s break down what actually happens inside a HashMap: Internally, HashMap uses an array of buckets: Node<K, V>[] table (default size = 16) Each bucket stores a structure like: class Node<K, V> { int hash; K key; V value; Node<K, V> next; } When you insert a key-value pair: 1.Hash value is calculated from the key 2.Bucket index is found using: hash % capacity 3.Entry is placed in that bucket Now the critical part: What if multiple keys map to the same bucket? 👉 Collision happens Entries are stored as a LinkedList using the next pointer If collisions increase → performance degrades Worst case: 👉 All keys land in same bucket → O(n) To handle this, Java introduced optimizations: Load Factor = 0.75 → When no. Entries > capacity * 0.75 → rehashing happens → Capacity doubles → reduces collisions Treeify Threshold = 8 → If a bucket has more than 8 entries → LinkedList converts into Red-Black Tree Now complexity improves: 👉 From O(n) → O(log n) So the reality is: Best case → O(1) Worst case → O(n) Optimized worst case → O(log n) Challenge: So what is Internal structure of LinkedHashMap ? Let’s see how you think about internal design 👇 #Java #BackendDevelopment #SoftwareEngineering #SystemDesign #HashMap #JavaDeveloper

Stop the Race: Solving Data Inconsistency in Concurrent Systems Building a "working" application is easy. Building a reliable one is hard. I recently spent time diving into the world of Concurrency and Data Integrity using Python and SQL. One of the most common (and dangerous) bugs in software is the "Race Condition"—where two processes try to update the same data at the same time, leading to "lost updates" and corrupted balances. I simulated a high-traffic banking system to see how data inconsistency happens and, more importantly, how to stop it. The Solution: A Two-Pronged Defense  Application-Level Locking: Using Python’s threading.Lock to create "Mutual Exclusion" (Mutex). This ensures that only one thread can access the critical "Read-Modify-Write" logic at a time.  Database-Level Integrity (ACID): Moving the logic into a relational database (PostgreSQL/SQLite) to leverage Atomicity and Isolation. By using BEGIN, FOR UPDATE, and COMMIT statements, the database acts as the ultimate gatekeeper for data truth. Key Takeaways: Transactions are Non-Negotiable: If it’s not Atomic (all-or-nothing), it’s not safe. The "with" Statement is a Lifesaver: Using context managers in Python ensures locks are released even if the code crashes, preventing deadlocks. Scalability Matters: While local locks work for one server, ACID-compliant databases are essential for distributed systems. Check out the snippet of my GitHub Codespaces setup below! https://lnkd.in/eguenR7g #Python #SoftwareEngineering #SQL #Database #Coding #DataIntegrity #BackendDevelopment #GitHub

🚀 Day 86 — Prefix Sum Pattern (Introduction) Today I started learning the Prefix Sum pattern — a fundamental technique for array problems where decisions at a given index depend on the sum of previous elements. Unlike sliding window, prefix sum handles negative numbers gracefully. 📌 What is Prefix Sum? At index i, the prefix sum is the sum of all elements from the start up to i-1. It stores “historical information” to make efficient decisions. 🧠 Why Prefix Sum > Sliding Window for Negatives? Sliding window fails with negatives because removing a negative actually increases the sum — breaking the logic of expanding/shrinking. Prefix sum remains effective. 📊 Four Categories of Prefix Sum Problems: 1️⃣ Left‑Right Comparisons (e.g., Pivot Index) → Can often be solved with simple variables (no extra arrays). 2️⃣ Exact Sums (Subarray Sum = K) → Requires a HashMap to store and lookup previous prefix sums. 3️⃣ Shortest Window with Sum ≥ K (with negatives) → Needs a Deque (double‑ended queue). 4️⃣ Range Sum Queries → Advanced techniques like Merge Sort on prefix array. 🔧 General Template: Initialize data structure (variable, array, or HashMap). Loop through the array, updating prefix information. Check problem‑specific condition. ⚡ Optimization Insight (Pivot Index Example): Instead of storing both prefix and suffix arrays, use: Total Sum = Left Sum + arr[i] + Right Sum → Right Sum = Total Sum - Left Sum - arr[i] This finds the pivot using only O(1) space. 💡 Takeaway: Prefix sum is a pattern, not just an algorithm. Recognizing when to use it — especially with negative numbers — unlocks efficient solutions for subarray sum problems. No guilt about past breaks — just adding another powerful pattern to the toolkit. #DSA #PrefixSum #ArrayPatterns #CodingJourney #Revision #Java #ProblemSolving #Consistency #GrowthMindset #TechCommunity #LearningInPublic

𝐃𝐚𝐲 12/30: 𝐅𝐢𝐥𝐥𝐢𝐧𝐠 𝐔𝐩 𝐭𝐡𝐞 𝐃𝐚𝐭𝐚𝐛𝐚𝐬𝐞 𝐖𝐢𝐭𝐡 𝐑𝐞𝐚𝐥 𝐂𝐨𝐦𝐩𝐚𝐧𝐢𝐞𝐬 🏢 𝘛𝘰𝘥𝘢𝘺 𝘐 𝘢𝘥𝘥𝘦𝘥 19 𝘤𝘰𝘮𝘱𝘢𝘯𝘪𝘦𝘴 𝘵𝘰 𝘮𝘺 𝘰𝘯𝘭𝘪𝘯𝘦 𝘥𝘢𝘵𝘢𝘣𝘢𝘴𝘦. 𝐖𝐡𝐚𝐭 𝐈 𝐝𝐢𝐝: Wrote a quick Python script that created company names, job listings, and passwords for each one. This gives me real-looking data to test with, instead of empty pages. 𝐓𝐡𝐞 𝐬𝐭𝐫𝐮𝐠𝐠𝐥𝐞: Took a few tries to get it right. My database structure is strict, so if anything was missing or in the wrong spot, it rejected the whole thing. 𝐋𝐞𝐬𝐬𝐨𝐧: Test data is a lifesaver. It shows you problems before real users do. But your data has to follow the rules exactly, or the database won’t accept it. #30DaysOfCode #BuildingInPublic #Database #Python #TechJourney #Typescript #react #supabase #fullstack