Overcoming Confusion in Spring Boot with Curiosity and AI

I thought becoming a software engineer would be about learning more code. It hasn’t been. It’s been about learning how to think differently. Since starting my first real dev role, I’ve realized growth isn’t just: → learning Java → learning Spring Boot → fixing bugs → shipping features It’s also learning how to: → stay calm when something breaks → solve problems you’ve never seen before → ask better questions → take ownership → keep going when you feel behind Coding matters. But mindset has mattered just as much. The biggest surprise of this journey is that becoming an engineer feels just as mental as it does technical. Still learning every day. What surprised you most when you started your career? #SoftwareEngineering #CareerGrowth #Java #BackendDevelopment #LearningInPublic

🚀 How to Get Hired in 2026 as a Fresher (Real Talk) Stop building basic CRUD apps. Start building systems that feel like real products. If I had to restart in 2026, I’d focus on THESE 3 projects 👇 🔥 1. AI-Powered GitHub PR Reviewer (like CodeRabbit) 👉 Build a system that behaves like a senior engineer: • Auto reviews PRs in real-time • Understands full repo context (not just diff) • Suggests improvements, bugs, optimizations ⚙️ Tech: MERN + RabbitMQ (repo indexing & async jobs) + Redis (caching reviews) RAG + LLM + Pinecone (vector DB) Webhooks (GitHub events trigger) WebSockets (live review updates on PR) 💡 What makes it powerful: This shows AI + distributed systems + event-driven architecture → Exactly what modern startups are building 🔗 Reference: https://lnkd.in/gBQKttxQ 🔥 2. LeetCode / Codeforces Clone (But Actually Scalable) 👉 Don’t build a clone… build the ENGINE: • Users submit code → goes into queue • Code runs in isolated containers • Multiple test cases executed in parallel • Real-time leaderboard updates • Contest mode with timers & rankings ⚙️ Tech: MERN + Redis (leaderboard, caching, rate limiting) RabbitMQ (submission queue & async execution) Docker (secure code execution sandbox) WebSockets (real-time leaderboard & contest updates) 💡 What makes it stand out: Shows system design at scale: • Queue-based processing • Horizontal scaling (workers) • Isolation (Docker) • Real-time infra 🔗 Reference: https://lnkd.in/gdN8-XyG 🔥 3. API Monitoring SaaS (Underrated Gold Project) 👉 Build something companies ACTUALLY pay for: • Monitor API uptime (cron jobs / workers) • Track response time, status codes • Alert system (email / webhook / Slack) • Logs + analytics dashboard ⚙️ Tech: Node.js + Express + MongoDB/Postgres Redis (caching + rate limiting) Cron Jobs / Workers (scheduled monitoring) WebSockets (live dashboard updates) Docker + CI/CD (production-ready deployment) 💡 What makes it powerful: Shows DevOps + backend + reliability engineering → This is real SaaS thinking 🎯 Reality Check: ❌ 10 basic projects = ignored ✅ 2–3 deep systems = shortlisted 💡 What Recruiters Actually Look For: • Can you design scalable systems? • Do you understand async processing (queues)? • Can you handle real-time systems? • Can you think like a backend engineer? If you build these 3 projects deeply, you’re already ahead of 95% of freshers. 💬 Want full roadmap (step-by-step build plan)? Comment “ROADMAP” #2026Hiring #SystemDesign #FullStack #MERN #WebSockets #AI #Freshers #Backend

🚀 Backend Learning | Mistakes I Made (And What They Taught Me) While working on backend systems, I realized that some of the best learnings come from mistakes. Here are a few that helped me grow: 🔹 1. Ignoring Edge Cases → Learned that real-world systems fail at edges, not happy paths 🔹 2. Not Thinking About Scalability Early → Refactored later when traffic increased 🔹 3. Overusing Synchronous APIs → Caused delays, later shifted to async processing 🔹 4. Poor Logging → Debugging production issues became difficult 🔹 5. Skipping Proper Error Handling → Led to unpredictable system behavior 🔹 What I Learned: • Think beyond just working code • Design for scale and failure • Logging & monitoring are as important as logic Mistakes are not failures — they are design lessons in disguise. 🚀 #Java #SpringBoot #BackendDevelopment #SystemDesign #LearningInPublic #SoftwareEngineering

#100DaysOfLeetcode journey 🚀 Day 67/100 — Optimizing Circular Proximity! Today’s Problem: Minimum Circular Distance to Matching Elements 🔹 The Goal: Given an array that "wraps around," find the shortest path from a specific index to any other occurrence of the same value. 🔹 The Insight: A naive search for every query would be $O(Q \times N)$, which is catastrophic for large datasets. The breakthrough here is Spatial Indexing. By pre-grouping the indices of every value and keeping them sorted, we transform a global search into a localized neighbor check. 🔹 The Logic: Value-to-Index Mapping: I used a HashMap to store sorted lists of indices for each unique number. Logarithmic Search: Using binarySearch, I instantly located the query index within its value-group. The "Circular Sandwich": Because the indices are sorted, the closest matching elements are always the immediate neighbors in the list. By checking the left, the right, and the wrap-around (first/last) elements, we guarantee the global minimum in $O(\log N)$ time. ✨ Achievement: Day 67! Successfully applied pre-computation and binary search to optimize a spatial query problem. Understanding that the "closest" element in a circular topology is always an adjacent neighbor in the sorted index space is a powerful shortcut for range-based problems. 🔍 Steps followed: ✔ Map Pre-processing: Clustered indices for constant-time value lookups. ✔ Binary Search Integration: Optimized neighbor identification to logarithmic time. ✔ Modular Distance Logic: Correctly handled the $N - \text{linearDist}$ calculation for circular boundaries. 🔧 Complexity Analysis: Time Complexity: $O(N + Q \log N)$ Space Complexity: $O(N)$ 67 days down! The logic is getting faster, and the problems are getting more interesting. Let's keep the streak alive! 🛠️ #Java #DSA #LeetCode #CodingJourney #100DaysOfCode #SoftwareEngineer #InternshipBound #Programming #ArrayAlgorithms #BinarySearch #Optimization #Day67

#100DaysOfLeetcode journey 🚀 🚀 Day 72/100 — Hamming Distance & Early-Exit Optimization! Today’s Problem: 2452. Words Within Two Edits of Dictionary 🔹 The Goal: Given a set of query words and a dictionary, identify which queries can be transformed into any dictionary word using a maximum of two character replacements. 🔹 The Insight: This is a classic "String Similarity" problem. Since all words are guaranteed to have the same length, the number of edits required is simply the Hamming Distance—the count of positions where characters differ. 🔹 The Logic: Exhaustive Comparison: For each query, we check it against the dictionary entries until we find a match within the 2-edit threshold. The Early Break (Pruning): This is the key optimization. While comparing two words character by character, if the difference count (diff) exceeds 2, we immediately stop and move to the next dictionary word. Short-Circuiting: Once a query word is validated against any dictionary word, we add it to our results and immediately move to the next query, avoiding unnecessary comparisons. ✨ Achievement: Day 72! Moving into the final 30 days of the challenge. Today’s solution highlights how simple logic—like breaking a loop early when a threshold is breached—can significantly improve the performance of $O(N \cdot M)$ algorithms without the complexity of more advanced data structures like Tries. 🔍 Steps followed: ✔ Hamming Distance Logic: Calculated positional differences for equal-length strings. ✔ Threshold Gating: Implemented a diff > 2 check to prune redundant character comparisons. ✔ Order Preservation: Ensured the results followed the original query sequence. 🔧 The Stats: Time Complexity: $O(Q \cdot D \cdot L)$ (where $Q$ is queries, $D$ is dictionary size, and $L$ is word length) Space Complexity: $O(1)$ auxiliary space. 72 days down! The logic is getting sharper, and the finish line is coming into focus. Let’s keep pushing! 🛠️ #Java #DSA #LeetCode #CodingJourney #100DaysOfCode #SoftwareEngineer #InternshipBound #Programming #StringAlgorithms #Optimization #Algorithms #Day72

Small Changes, Big Impact in My Development Journey Today I realized something simple but powerful… It’s not about writing more code, It’s about writing better code. Earlier in my journey: I focused only on completing tasks Ignored code quality and structure Didn’t think much about optimization Now, I try to: Write clean and readable code Understand the logic deeply Improve with every small task One thing I follow: “Every line of code should make sense, not just work.” Still learning, still improving… step by step What’s one habit that improved your coding skills? #SoftwareDeveloper #Java #SpringBoot #Learning #CleanCode #TechGrowth

🚀 Backend Learning | Retry Mechanism & Exponential Backoff While working on backend systems, I recently explored how to handle transient failures using retry mechanisms. 🔹 The Problem: • Temporary failures in external APIs or services • Immediate retries causing system overload • Risk of cascading failures 🔹 What I Learned: • Retry Mechanism helps recover from temporary failures • Exponential Backoff increases delay between retries • Prevents overwhelming the system with repeated requests 🔹 Key Insights: • Not all failures should be retried • Add delay and limit retry attempts • Combine with circuit breaker for better resilience 🔹 Outcome: • Improved system stability • Reduced failure impact • Better handling of external service issues Reliable systems are not just about handling success — they are about handling failures gracefully. 🚀 #Java #SpringBoot #SystemDesign #BackendDevelopment #Microservices #Resilience #LearningInPublic

I used to hear a lot about T-shaped engineers. Go deep in one skill, and have a basic understanding of others. Makes sense. But lately, I’ve been thinking in real-world engineering, it’s slowly shifting beyond that. 👉 From T-shaped → to something closer to M-shaped learning Because today, systems are not built in isolation. For example, in backend development : • Going deep into Java and Spring Boot is important • but backend doesn’t work without databases • APIs directly connect with frontend systems • and deployment + infrastructure affect real-world behavior So one depth is often not enough. Not expert in everything , but not limited to just one vertical either. The interesting part is: 👉 The shape doesn’t matter as much as the thinking behind it • Depth helps you solve complex problems • Breadth helps you understand how systems actually work end-to-end • And better understanding leads to better decisions And real-world engineering is full of decisions. Lately, I’ve been trying to balance both: • going deeper into backend systems • while expanding understanding of system design and how different parts connect Still figuring this out, but this feels closer to how modern engineering works. Curious, Do you think being T-shaped is still enough, or is M-shaped becoming more relevant? #softwareengineering #backenddevelopment #systemdesign #learning #developers #decisions

#Day90 Of Problem Solving Solved today’s LeetCode Daily Question and got it accepted — 180/180 test cases passed. This problem was a good reminder that sometimes simple logic, when applied clearly, works best. I used a HashMap to track frequencies and then sorted based on the conditions. Nothing too fancy, but it required careful thinking about ordering. Performance: Runtime: 9 ms Memory: 45.72 MB What I’m learning from these daily problems is consistency matters more than complexity. Showing up every day, solving, and improving bit by bit is what actually builds problem-solving skills. If you're also preparing for SDE roles, keep going — even small progress adds up over time. #LeetCode #DSA #Java #CodingJourney #ProblemSolving #Consistency

LeetCode — But Did You Think About the How? #ContainsDuplicate | NeetCode 150 Most devs solve "Contains Duplicate" - https://lnkd.in/gq84sj37 and move on. But this problem is a great lens for thinking about trade-offs — and that's exactly what interviewers are watching for. Here are my two solutions: Solution 1 — Sort + Linear Scan class Solution { public boolean hasDuplicate(int[] nums) { Arrays.sort(nums); for (int i = 1; i < nums.length; i++) { if (nums[i] == nums[i - 1]) return true; } return false; } } Time: O(n log n) | Space: O(1) (in-place sort) Solution 2 — Stream + Distinct class Solution { public boolean hasDuplicate(int[] nums) { return Arrays.stream(nums).distinct().count() < nums.length; } } Time: O(n) | Space: O(n) My repository - https://lnkd.in/g_Ke_eqR Key Insight: One liner looks cleaner. But it costs you extra memory. The sort-based approach trades time for space — and modifies the original array. Neither is universally "better." The right answer depends on your constraints: → Memory-constrained system? Go with Sort. → Read-only array or immutable input? Stream wins. → Need early exit on first duplicate? Both support it — but stream is lazy, so it does too This is the kind of thinking that separates good developers from great ones in interviews. What's your go-to approach? Drop it below #Java #LeetCode #NeetCode #DSA #CodingInterview #SpringBoot #SoftwareEngineering #ProblemSolving #100DaysOfCode