Ruslan Mukhamadiarov’s Post

🧠 LeetCode POTD — From TLE to Optimized Thinking 3488. Closest Equal Element Queries At first, the approach felt straightforward. For each query: 👉 Start from the given index 👉 Expand left and right (circularly) 👉 Find the closest same element ━━━━━━━━━━━━━━━━━━━ 💥 The problem? This works… but doesn't scale. If there are q queries and n elements: → Each query can take O(n) → Total = O(n × q) 👉 This leads to TLE for large inputs. ━━━━━━━━━━━━━━━━━━━ 💡 So what's the issue? We are repeating the same work again and again for every query. ━━━━━━━━━━━━━━━━━━━ 📌 Better Approach: Preprocess the array. 👉 Use a map: value → list of indices Example: nums = [1, 2, 1, 3, 1] → 1 → [0, 2, 4] Now for each query: Get all indices of that value If only one occurrence → answer = -1 Else: 👉 Use binary search to find the closest index 👉 Check neighbors (left & right) 📌 Since the array is circular: Distance = min(|i - j|, n - |i - j|) ━━━━━━━━━━━━━━━━━━━ 💡 Complexity now: → Preprocessing: O(n) → Each query: O(log n) 👉 Total: O(n + q log n) ━━━━━━━━━━━━━━━━━━━ 📌 What I liked about this problem: The solution isn't complicated. The key is realizing: 👉 "This is not a single query problem." Once you see that, the shift from brute force → optimized becomes obvious. ✅ Sometimes optimization is not about faster code ✅ It's about not repeating the same work Curious if someone solved it differently 👀 #LeetCode #DataStructures #ProblemSolving #SoftwareEngineering #DSA #C++ #Java #SDE

Voice Support and Human in the loop: These features are tremendous! HITL is mandatory in an angentic infrastructure. In many case, autonomous agent cannot be deployed. Voice support, in the other hand,... I love letting my agent do my work just talking with it. Call me lazy 😉

𝗠𝗲𝘁𝗵𝗼𝗱 𝗢𝘃𝗲𝗿𝗹𝗼𝗮𝗱𝗶𝗻𝗴 𝘃𝘀 𝗠𝗲𝘁𝗵𝗼𝗱 𝗢𝘃𝗲𝗿𝗿𝗶𝗱𝗶𝗻𝗴 𝘃𝘀 𝗠𝗲𝘁𝗵𝗼𝗱 𝗛𝗶𝗱𝗶𝗻𝗴 💻 𝗠𝗲𝘁𝗵𝗼𝗱 𝗢𝘃𝗲𝗿𝗹𝗼𝗮𝗱𝗶𝗻𝗴 (Compile-time Polymorphism): ▸ Same method name, different parameters ▸ Happens in the SAME class ▸ Return type can be different (parameters must differ) class PaymentService { void pay(int amount) { System.out.println("Paid via cash"); } void pay(int amount, String upiId) { System.out.println("Paid via UPI"); } } 𝗠𝗲𝘁𝗵𝗼𝗱 𝗢𝘃𝗲𝗿𝗿𝗶𝗱𝗶𝗻𝗴 (Runtime Polymorphism): ▸ Same method name, same parameters ▸ Happens in PARENT-CHILD class ▸ Decided at runtime (dynamic binding) ▸ @Override recommended class Notification { void send() { System.out.println("Sending generic notification"); } } class EmailNotification extends Notification { @Override void send() { System.out.println("Sending Email"); } } 𝗠𝗲𝘁𝗵𝗼𝗱 𝗛𝗶𝗱𝗶𝗻𝗴 (Static Methods): ▸ Happens when static method in child hides parent static method ▸ No runtime polymorphism (resolved at compile time) class Parent { static void show() { System.out.println("Parent static method"); } } class Child extends Parent { static void show() { System.out.println("Child static method"); } } #Java #SpringBoot #JavaDeveloper #BackendDeveloper #OOP

Solved LeetCode #237 – Delete Node in a Linked List Today I worked on an interesting linked list problem that challenges the usual way we think about deletion. Problem Insight : Normally, to delete a node in a linked list, we need access to the previous node. But in this problem, we are only given the node to be deleted, not the head or the previous node. Key Idea (Trick) : Instead of deleting the node directly, we: Copy the value of the next node into the current node Skip the next node Delete the next node This effectively removes the given node from the list. Code Explanation (Simple Way) void deleteNode(ListNode* node) { node->val = node->next->val; // Step 1: Copy next node's value ListNode* temp = node->next; // Step 2: Store next node node->next = temp->next; // Step 3: Skip next node delete temp; // Step 4: Delete it } Dry Run Example Linked List: 10 → 20 → 30 → 40 Given node: 20 After the operation: 10 → 30 → 40 We didn’t delete 20 directly. We replaced it with 30 and removed the original 30-node. Learning Outcome : This problem improves understanding of: Pointer manipulation In-place operations Thinking beyond traditional approaches “Focus on progress, not perfection — every solved problem counts.” #LeetCode #DataStructures #LinkedList #Cpp #CodingJourney #ProblemSolving #SoftwareDevelopment #TechLearning #CodingPractice #Developers #100DaysOfCode

Day 101: Clean Code is Scalable Code 🚀 Problem 3741: Minimum Distance Between Three Equal Elements II They say if you solve a problem correctly once, the "Hard" version becomes easy. Today was proof of that. The Strategy: • Reusable Logic: My solution from yesterday handled the transition to Part II perfectly. The core logic of tracking indices in a HashMap and applying a sliding window of three was already optimal. • The "Part II" Test: Even with increased constraints or complexity in the problem description, O(N) frequency tracking and index-gap calculations proved to be the robust way to go. • Efficiency: By isolating only the elements that appeared 3+ times, I kept the runtime minimal and the memory footprint low. It's a great feeling when the architecture you built yesterday is strong enough to handle today's challenge without a single line of refactoring. Day 101 and the momentum is only increasing. ⚡ #LeetCode #Java #Algorithms #DataStructures #ProblemSolving #DailyCode

I hit a strange realization today. Not a new concept. Not a new framework. Just something I’ve already used in production. But still… *I couldn’t explain it cleanly. We often say “I know this.” But do we really? Today’s trigger was a simple API design scenario in Spring Framework: 👉 Upload a file + send structured JSON data in the same request Sounds basic, right? But when I tried to break it down clearly— the *why*, the *how*, the *right annotation*— there was hesitation. --- Then the clarity came back: * `@RequestParam` → key-value inputs * `@PathVariable` → resource identity * `@RequestBody` → pure JSON payload * `@RequestPart` → **multipart boundary where file + structured data meet That moment reminded me of something deeper: > “Exposure creates familiarity. > But only articulation proves understanding.” In real systems, this gap shows up everywhere: * You’ve seen the pattern, but can’t justify it * You’ve fixed the bug, but can’t explain root cause * You’ve used the annotation, but don’t know *why it exists* At scale, this matters. Because senior engineering is not about: ❌ Writing more code It’s about: ✔ Explaining decisions clearly ✔ Designing with intent ✔ Debugging with first-principles thinkin --- **Today wasn’t about learning something new. It was about realizing what I hadn’t fully understood.** And that’s a different kind of progress. #SoftwareEngineering #Java #SpringBoot #SystemDesign #Backend #EngineeringMindset

What is 𝗙𝗮𝗰𝘁𝗼𝗿𝘆 𝗣𝗮𝘁𝘁𝗲𝗿𝗻 ?? Its main goal is simple: 𝐜𝐫𝐞𝐚𝐭𝐞 𝐨𝐛𝐣𝐞𝐜𝐭𝐬 without exposing the creation 𝐥𝐨𝐠𝐢𝐜 𝐭𝐨 𝐭𝐡𝐞 𝐜𝐥𝐢𝐞𝐧𝐭. Instead of 𝐢𝐧𝐬𝐭𝐚𝐧𝐭𝐢𝐚𝐭𝐢𝐧𝐠 𝐜𝐥𝐚𝐬𝐬𝐞𝐬 directly with 𝒏𝒆𝒘, the client asks a 𝐟𝐚𝐜𝐭𝐨𝐫𝐲 to provide the right object. Why this matters: • it reduces tight coupling • it centralizes object creation • it makes the code easier to extend • it improves readability and maintainability A simple example in 𝙅𝙖𝙫𝙖: a 𝙉𝙤𝙩𝙞𝙛𝙞𝙘𝙖𝙩𝙞𝙤𝙣𝙁𝙖𝙘𝙩𝙤𝙧𝙮 can return 𝘌𝘮𝘢𝘪𝘭𝘕𝘰𝘵𝘪𝘧𝘪𝘤𝘢𝘵𝘪𝘰𝘯, 𝘚𝘮𝘴𝘕𝘰𝘵𝘪𝘧𝘪𝘤𝘢𝘵𝘪𝘰𝘯, or 𝘗𝘶𝘴𝘩𝘕𝘰𝘵𝘪𝘧𝘪𝘤𝘢𝘵𝘪𝘰𝘯 depending on the input. The client only works with the Notification abstraction, not the concrete classes. That is the real strength of the 𝗙𝗮𝗰𝘁𝗼𝗿𝘆 𝗣𝗮𝘁𝘁𝗲𝗿𝗻: focus on what you need, not how the object is created. It is especially useful when: • multiple classes share the same parent interface • object creation contains conditions • you want cleaner and more scalable code A good 𝒅𝒆𝒔𝒊𝒈𝒏 𝒑𝒂𝒕𝒕𝒆𝒓𝒏 does not just solve a technical problem. It also makes the codebase easier for other developers to understand and evolve. #Java #DesignPatterns #FactoryPattern #OOP #CleanCode #SoftwareEngineering #BackendDevelopment

Not everything should be Optional. And that’s where most developers get it wrong. The industry keeps pushing: 👉 “Avoid nulls” 👉 “Use Optional everywhere” But here’s the architectural truth: Optional is not a replacement for good domain modeling. Yes — it makes absence explicit. Yes — it removes defensive null checks. But “sometimes” Optional is the right choice… not always. 🔍 When Optional makes sense: * When a value is *truly optional* in the domain * When absence is a valid outcome (e.g., `findUserById`) * When you want to force the caller to *think about absence* 🚫 When Optional becomes noise: * DTOs / Entities (adds unnecessary wrapping) * Method parameters (confusing API design) * Internal logic where null is already controlled 💡 Architectural insight: If everything is Optional → nothing is explicit anymore. The real goal is not: “Remove nulls everywhere” The real goal is: 👉 **Model reality correctly** Because in good systems: * Some things MUST exist * Some things MAY exist * And your code should reflect that clearly --- ⚡ **Bonus Insight: map vs flatMap (where most devs slip)** ```java // ❌ Creates nested Optional user.map(User::getEmail); // Optional<Optional<String>> // ✅ Flattens automatically user.flatMap(User::getEmail) // Optional<String> .ifPresent(this::sendEmail); ``` 👉 `map` = transform value 👉 `flatMap` = transform + flatten container Rule:if your method already returns Optional → always use `flatMap` --- ⚡ Optional is a tool — not a rule. #Java #SpringBoot #SoftwareArchitecture #CleanCode #DesignThinking

Agents shouldn’t start from files. Starting from structure is often strictly more efficient. Targeted patch planning: 51.1% token reduction Context bundling: 27.6% token reduction Contract / impact analysis: 21.6% token reduction I built a graph-first harness layer and measured the impact on spring-petclinic: The core idea: let the agent navigate a structural graph of the codebase first, then expand into source only when needed. Instead of treating a codebase as just a file tree, the agent operates over: - graph summaries - call paths - impact information - targeted source slices - scoped edit planning - scoped validation More interestingly, this setup seems to reward better architecture. Codebases with cleaner abstractions, tighter module boundaries, and smaller impact radius compress better and are easier for the agent to reason about safely. Over time, a graph-aware agent implicitly favors better structure, because well-architected systems are simply cheaper and more reliable to operate on. I implemented this as GraphHarness — a Joern-backed graph context layer between the agent and a Java codebase. It’s still a prototype, and there are real limits: - cold start is still expensive - broad rename / refactor planning is weaker than targeted edits - validation can degrade in constrained environments But the direction feels right. Structure first. Source second. Scoped edits. Explicit validation. Measurable impact. Github: https://lnkd.in/gApwYik2 #HarnessEngineering #AIAgents #DeveloperTools #CodeIntelligence #SoftwareEngineering

🚀 LeetCode — Problem 8 | Day 13 💡 Problem: String to Integer (atoi) --- 🧠 Problem: Convert a string into a 32-bit signed integer (like C/C++ atoi). --- 🧠 Approach: - Skip leading whitespaces - Check sign (+ / -) - Convert digits one by one - Stop at first non-digit character - Handle overflow before it happens --- ⚙️ Core Logic: - Build number step-by-step: result = result * 10 + digit - Before adding digit, check: • If result > Integer.MAX_VALUE / 10 • Or result == MAX/10 and digit > 7 👉 Return: - Integer.MAX_VALUE (overflow) - Integer.MIN_VALUE (underflow) --- ⏱ Time Complexity: O(n) 📦 Space Complexity: O(1) --- ⚠️ Edge Cases: - " 42" → leading spaces - "-42" → negative number - "42abc" → stop at non-digit - "abc" → no digits → return 0 - Large values → handled overflow --- 🔍 Insight: Careful parsing is more important than complex logic --- 🔑 Key Learning: - Step-by-step string parsing - Handling edge cases cleanly - Preventing overflow before it occurs - Real-world input validation logic --- #LeetCode #DSA #Java #CodingJourney