Ayush Mishra’s Post

0ms. 100% Beats. Thinking outside the box. There is nothing quite like the feeling of seeing your code hit a 0ms runtime. Today’s win was the "Delete Node in a Linked List" problem. At first glance, it feels impossible—how do you delete a node when you don't have access to the head of the list? The Solution: Instead of trying to "delete" the node in the traditional sense, I just copied the data from the next node into the current one and skipped the next node entirely. The Result: * Runtime: 0ms (Beats 100.00% of Java users). * Logic: O(1) Time and Space complexity. * Efficiency: 41/41 test cases passed instantly. In software engineering, we often get stuck trying to solve a problem the "standard" way. This was a great reminder that sometimes, the best solution is to reframe the problem itself. One optimization at a time. Do you prefer clever "hacks" like this, or do you stick to standard procedural logic? Let’s discuss in the comments! 👇 #Java #LeetCode #SoftwareEngineering #CodingLife #DataStructures #Optimization #TechCommunity

🚨 Potential Bug Identified in LeetCode Execution Time Calculation 🚨 I recently noticed an issue with how LeetCode calculates and displays code execution time. By adding a simple static block with a shutdown hook, it is possible to alter the displayed runtime of a submitted solution. This indicates that the execution time can be influenced outside the actual algorithm logic, which should ideally not be possible. Below is the code snippet that demonstrates this behavior: static { Runtime.getRuntime().addShutdownHook(new Thread(() -> { try (FileWriter writer = new FileWriter("display_runtime.txt")) { writer.write("0"); } catch (IOException e) { e.printStackTrace(); } })); } This suggests a bug on LeetCode’s end, where execution time tracking may be relying on artifacts that can be manipulated during JVM shutdown. Sharing this for awareness and hoping the LeetCode team can look into it to ensure fair and accurate performance measurement for all submissions. hashtag #LeetCode #Java #TimeComplexity #Algorithms #CompetitiveProgramming #SoftwareEngineering #Programming #BugReport #DeveloperCommunity #TechLearning

𝑷𝒐𝒕𝒆𝒏𝒕𝒊𝒂𝒍 𝑩𝒖𝒈 𝑰𝒅𝒆𝒏𝒕𝒊𝒇𝒊𝒆𝒅 𝒊𝒏 𝑳𝒆𝒆𝒕𝑪𝒐𝒅𝒆 𝑬𝒙𝒆𝒄𝒖𝒕𝒊𝒐𝒏 𝑻𝒊𝒎𝒆 𝑪𝒂𝒍𝒄𝒖𝒍𝒂𝒕𝒊𝒐𝒏  I recently noticed an issue with how LeetCode calculates and displays code execution time. By adding a simple static block with a shutdown hook, it is possible to alter the displayed runtime of a submitted solution. This indicates that the execution time can be influenced outside the actual algorithm logic, which should ideally not be possible. Below is the code snippet that demonstrates this behavior: static { Runtime.getRuntime().addShutdownHook(new Thread(() -> { try (FileWriter writer = new FileWriter("display_runtime.txt")) { writer.write("0"); } catch (IOException e) { e.printStackTrace(); } })); } This suggests a bug on LeetCode’s end, where execution time tracking may be relying on artifacts that can be manipulated during JVM shutdown. Sharing this for awareness and hoping the LeetCode team can look into it to ensure fair and accurate performance measurement for all submissions. #LeetCode #Java #JVM #CompetitiveProgramming #SoftwareEngineering #Performance #Debugging LeetCode

That 2ms runtime feeling. I just optimized the Delete the Middle Node of a Linked List problem. While it’s a standard challenge, hitting that near-perfect efficiency mark is always a great reminder: Clean logic beats heavy code every single time. The Breakdown: * The Approach: Used a "Fast and Slow" pointer strategy to find and remove the middle in a single pass. * The Result: 2ms runtime, beating 99.68% of Java submissions. * Consistency: All 70/70 test cases passed. In software engineering, it's easy to get lost in complex frameworks. But mastering these fundamental data structures is what truly sharpens your problem-solving "intuition." One step at a time, one optimization at a time. #LeetCode #Java #DataStructures #SoftwareEngineering #ProblemSolving #CodingLife

From writing code to solving problems: The journey from Coder to Programmer.  There is a big difference between a "Coder" and a "Programmer." A coder writes instructions that a computer understands, but a programmer designs efficient solutions that solve problems effectively.📈 Over the last 45 days on LeetCode and GFG, I’ve been focused on making that transition. It’s no longer just about getting a "Success" message; it’s about the shift in how I think. Mastering patterns like Sliding Window, Two Pointers, and HashMaps has completely changed the way I look at an array. It’s not just a list of data anymore; it’s a puzzle waiting for the most efficient O(n) solution.  🥸Sliding Window & Two Pointers: Replacing nested loops with optimized logic.  🤓Java Collections: Leveraging HashMaps, HashSets, and ArrayLists for O(1) lookups and structured data.  😎Optimization: Moving from "just making it work" to trading space for time complexity. 37 problems down, and the foundation is getting stronger every day. Java is my tool, and DSA is my blueprint. #SoftwareEngineering #Java #DSA #LeetCode #CoderToProgrammer #ProblemSolving #Consistency

A Copy Constructor is more than an alternative to clone() — it’s a deliberate design choice that brings clarity and control to how object state is replicated. Unlike Cloneable, which hides behavior behind reflection and shallow defaults, a copy constructor makes every replication step explicit: 🔹 precise control over deep vs shallow copying 🔹 predictable object graph boundaries 🔹 compatibility with final fields 🔹 no hidden exceptions or fragile casts 🔹 clean integration with immutable and thread-safe designs In concurrent or state-heavy systems, correctness depends on isolating state without guessing what the clone operation actually did. A well-crafted copy constructor turns state replication into a transparent, deterministic, and debuggable part of your design. This is why architecture-level Java code often avoids clone() entirely — and prefers explicit copying where invariants are preserved by design, not by assumption. Hashtags: #Java #AdvancedJava #OOPDesign #JVM #JavaInternals #Immutability #BackendEngineering #SoftwareArchitecture #CleanCode #Concurrency #HighPerformanceJava #JavaDeveloper #ProgrammingConcepts #DeepWork #TechLearning #EngineeringExcellence

Day 19 of my DSA consistency challenge — solved LeetCode 14: Longest Common Prefix 🚀 Today’s problem looked easy at first, but it teaches an important lesson about string comparison and edge cases. Problem: Given an array of strings, find the longest common prefix among them. If no common prefix exists, return an empty string. Key idea: Start with the first word as the prefix and shrink it step by step until every string starts with it. If at any point it becomes empty, stop — there is no common prefix. What I improved today: • String manipulation skills • Edge case handling (empty array, single word, no prefix) • Clean iterative thinking instead of overcomplicating Time Complexity: O(n × m) n = number of strings, m = length of shortest string Consistency > Motivation. 19 days straight. No skipping. #Day19 #LeetCode #DSA #Java #ProblemSolving #CodingJourney #SoftwareEngineer #InterviewPreparation #100DaysOfCode #Developers #LearningInPublic

One backend habit I’m slowly building: Treating logs as a feature, not an afterthought. Earlier, I thought logs were just for printing errors. But while working with backend applications, I realized logs are often the first place you look when something goes wrong. Good logs help answer questions like: • What request failed? • At which step did it fail? • What data caused the issue? Even simple practices make a big difference: • Logging meaningful messages (not just stack traces) • Adding context like request IDs or user actions • Avoiding unnecessary or noisy logs When systems grow, logs become your best debugging tool. Still learning, but understanding the importance of logging has changed how I write backend code. #Java #BackendEngineering #SpringBoot #SoftwareEngineering #LearningInPublic

While working on a backend task recently, I came across CompletableFuture in a piece of async code. At first glance, I assumed something simple: When this runs, a new thread must be getting created. But when I dug deeper, that assumption didn’t hold. CompletableFuture doesn’t create a new thread every time. It submits work to a thread pool (by default, ForkJoinPool.commonPool()). That pushed me to understand something more important: Async programming in Java isn’t really about “creating threads.” It’s about how tasks are scheduled and executed using thread pools. And that’s where things get interesting. Not all work is the same. 🔹 CPU-bound work Heavy calculations, in-memory processing. For this, thread pool size should roughly match the number of CPU cores. More threads won’t make it faster — they just add context switching. 🔹 I/O-bound work Database calls, HTTP calls, file operations. These threads spend most of their time waiting. Here, you can use a larger pool because threads are often idle. What I realized: ▪️ Async doesn’t automatically mean scalable. ▪️ If CPU and blocking I/O tasks share the same pool, you can create bottlenecks. ▪️ Default pools are convenient, but not always. ▪️ Separating workloads gives much better control and predictability. That small assumption about “new thread per async call” led me to rethink how concurrency actually works in real systems. #Java #Concurrency #Multithreading #BackendDevelopment #SystemDesign #Scalability

𝗪𝗵𝗲𝗻 𝗝𝗮𝘃𝗮 𝗙𝗲𝗲𝗹𝘀 𝗙𝗿𝗲𝘀𝗵 A few weeks ago, I was writing another class just to hold some data. Getters, setters, equals(), hashCode() etc the usual way of doing. I stopped and thought if there was a simpler way or any other way of doing this??? That’s when I started exploring some of 𝗝𝗮𝘃𝗮’𝘀 𝗺𝗼𝗱𝗲𝗿𝗻 𝗳𝗲𝗮𝘁𝘂𝗿𝗲𝘀, and they completely changed how I write code: • 𝗥𝗘𝗖𝗢𝗥𝗗𝗦: Create immutable data objects in a single line. No more endless repetitive code. • 𝗦𝗘𝗔𝗟𝗘𝗗 𝗖𝗟𝗔𝗦𝗦𝗘𝗦: Control exactly which classes can extend a parent. Safer and easier to maintain. • 𝗩𝗜𝗥𝗧𝗨𝗔𝗟 𝗧𝗛𝗥𝗘𝗔𝗗𝗦: Handle thousands of tasks concurrently without eating up memory. Lightweight and practical for high concurrency. • 𝗣𝗔𝗧𝗧𝗘𝗥𝗡 𝗠𝗔𝗧𝗖𝗛𝗜𝗡𝗚: Simplifies complex conditional logic and makes code much cleaner. So Java is not just old and reliable but with its features it keeps evolving. Using these features helps reduce routine code, write safer code, and build applications that are easier to maintain while staying in the JVM enviornment. 👉 Have you tried any of these modern Java features? Which one made the biggest difference in your projects? #Java #ModernJava #JVM #BackendDevelopment #SoftwareEngineering #Programming