Priya helps Raj debug API issue, builds team trust

Candidate-1 cracked Amazon. It was very hard for both of them to prepare, because their company’s work culture was hectic. But Candidate-1 prepared smartly for the switch. Here’s what he followed 👇 1. He avoided LeetCode’s “Similar Questions” section ❌. Instead of solving them back-to-back just to inflate his problem count, he spaced them out by 5–6 days for better retention. 2. He didn’t just solve a problem and move on. He explored discussions, challenged himself, and brainstormed 2–3 alternative solutions for deeper understanding. 3. He didn’t waste time on obvious, boilerplate implementations. Instead, he focused on forming the logic in his head and moved on. Real coding practice came from tough, complex implementations. Just avoid wasting time on low-value tasks. It wasn’t luck. It wasn’t talent. It was preparation done smartly.

He has heard the whispers, “he is getting older, who will replace him?” People asking him with a straight face, “when will you retire?” After close to 25 years at Amazon, where each year has been different and amazing, He feels as young as the day he decided to leave academia and join Amazon. The thing about getting older as a developer, is that you have seen a lot and encountered many of the problems younger developers are facing (even if they look a little different on first glance). If you've been around the block as many times as some of us have, you'll have earned battle scars along the way. There are days in war rooms you will never forget. You have experimented a lot, and you have failed more times than you care to remember. You have half-a-head full of what is practical and works. And a quarter of that space has been trained to look for red flags, scanning for things that you know will go wrong. https://lnkd.in/eZegvxFv

You will fail in backend interviews if you don’t know this😞😞😞 Amazon pays 30-40 LPA for SDE-1 role and 60-80LPA for SDE-2 role My friend was asked to design a scalable notification service Flow - Notification API will be called - Then SQS kind of queue. Where you will have multiple priority queue for different type of notifications - Workers will pick event from this queue - Executor will start notifying the users - Once they received acknowledgement they will send the result to AWS Kinesis. - Kinesis uses data streaming so basically to avoid database bottleneck - Datalqke Publisher and DB writer will write result to database - Scheduler a chron job will pick failed events - Again process is repeated How would you avoid webhook taking long time for acknowledgment? #razorpay #notification

10 years at Amazon. Countless post-mortems. Your project didn't fail because your engineers were blocked by code complexity. It failed because:   - Stakeholders not aligned - Unclear product direction - Missing user research - Strategy ignored reality “Developer productivity” isn’t one of your top-5 problems.

⚡ How I learned System Design while working full-time at Flipkart When I joined as a developer, I thought “System Design” was something only senior engineers dealt with. I was wrong. The reality: even as an SDE-1/SDE-2, you need to understand how systems scale, handle failures, and serve millions of users. But here was my challenge: ⏳ I was working full-time. 📚 I didn’t have endless hours for prep. So I built a learning system that worked for me 👇 1️⃣ Learn by building Instead of reading only theory, I picked real problems (URL shortener, notification service, blob storage) and designed them step by step. 2️⃣ Ask “Why” in every code review Whenever a senior suggested using Kafka, Redis, or load balancers → I asked why. Those discussions were gold. 3️⃣ Study patterns, not projects Most systems boil down to patterns: caching, sharding, replication, queues. Once you master patterns, you can apply them anywhere. 4️⃣ Micro-learning 1 hour daily > 6 hours once a week. I treated it like gym workouts — small, consistent reps. The result? I went from “System Design is scary” → to “I can break down any problem into components.” ⚡ Takeaway: You don’t need 8 hours a day to learn System Design. You need consistency, curiosity, and practice. 👉 How are you learning System Design right now — theory, projects, or on the job? #SystemDesign #CareerGrowth #SoftwareEngineering #Flipkart

People keep saying "DSA is no longer relevant" "DSA is outdated" But reality is very different. At Google you solve multiple rounds of algorithmic problems. At Microsoft coding rounds focus heavily on problem solving. Uber, Stripe, Meta, Amazon, Apple and many others continue to test candidates on DSA. Even fast growing product companies like CRED, Nutanix, Salesforce, Oracle, Flipkart put strong emphasis on it. The truth is simple. If you are preparing for top product roles, you cannot afford to ignore data structures and algorithms. Focus on what companies actually test, not on opinions floating around. #CareerGrowth #SoftwareEngineering #DSA #JobPreparation #CodingInterviews #TechCareers

Excited to share my Amazon SDE-1 Online Assessment experience. Today, I appeared for the Amazon SDE-1 Online Assessment, and I’d love to share my journey to help others preparing for the same. The OA was structured into 4 sections: ⚫Coding Round (70 minutes, 2 questions) Q1. String Matching & Greedy/Two Pointer Approach (LeetCode Medium) Each engineer (with a required expertise) must be assigned to a compatible workstation in the same order from the expertise and workspace strings. Workstations don’t need to be contiguous. The goal is to maximize the isolation—defined as the largest gap (in indices) between any two consecutively assigned engineers in the workspace string. Q2. Drone Travel on Circular Network (LeetCode Hard) Given a circular/cyclic undirected graph representing hubs connected in a loop with given travel times between adjacent hubs, find the minimum total travel time for a drone starting at Hub 1 to visit a given sequence of hubs in the specified order. The drone can choose the shortest path—clockwise or counterclockwise—between each pair of hubs. ⚫Workstyles Assessment (15 minutes) Behavioral multiple-choice questions focused on Amazon’s Leadership Principles. No preparation required; just answer honestly and consistently. ⚫Work Simulation (60–120 minutes) A virtual simulation of a day in the life of an SDE at Amazon. Tasks included emails, instant messages, and problem statements from managers and peers. You are asked to evaluate multiple possible responses and pick or rank the most effective one. Additional reference material was provided (internal wikis, code snippets, roadmaps). (Focus: Decision-making, prioritization, and customer obsession) ⚫Feedback Survey (5 minutes) A short survey to capture overall experience with the OA. ✨ Key Takeaways: The coding round is challenging (LeetCode Medium/Hard level) and requires strong DSA preparation plus time management. The work simulation tests real-world problem-solving, prioritization, and customer-centric thinking. The workstyles section is behavioral and tests cultural fit with Amazon’s Leadership Principles. 💡 Overall, the assessment was well-rounded—not only testing coding skills, but also mindset, decision-making ability, and leadership principles. This time I couldn’t move forward, but yeah, the experience itself was valuable. It showed me exactly where I need to improve, and that’s a win in its own way. On to the next one :) Good luck to others ❤ #Amazon #OA #OnlineAssessment #SoftwareEngineering #SDE #CodingInterviews #DSA #Leetcode #CareerJourney #InterviewPreparation #JobSearch #TechCareers #SWEJobs #Experience

Google pays around 20–35 LPA for SDE-1, and will always start your process with a DSA round before anything else. Amazon pays around 20–40 LPA for SDE-1, and yes, your first step is always a DSA screening round. Uber, Stripe, and Microsoft all offer between 25-45 LPA for SDE-1. They, too, use a DSA round as the gatekeeper for interviews. Entry to every top company starts with a simple filter: A 45–60 minute DSA round where you solve 2–3 coding problems. That’s it. 80% of people get filtered out right here, not because they aren’t smart, but because they never trained for: – Speed under pressure – Pattern recognition – Clean, explainable solutions Nobody cares how good you could be. They care about whether you can deliver on the spot. That’s why I recommend this DSA Pattern Product, so you know exactly what to study and how to practice, you get ✅ help you track and learn the clues and triggers of different patterns ✅ provide AI-based doubt solving + space to add your own notes ✅ solve 250+ good problems with 5 problems each on 50 patterns ✅ train you on every scenario, so you can solve unseen problems. Check the DSA Product here- https://lnkd.in/e8VVcHJE This is how you give yourself a real shot. Not by guessing. But by prepping the way these companies actually hire.

Pod Pending Forever : CKA taught me: when a pod is pending, look at scheduling constraints. 👉 Hook: Your pod is stuck in Pending. What’s next? 👉 Thought process: 1. Check events: kubectl describe pod <name> 2. Verify resource requests vs. node capacity 3. Inspect node taints/tolerations 4. Review affinity/anti-affinity rules 👉 Takeaway: Pod scheduling failures are usually due to resource requests or node constraints. I am exploring SDE/SRE/Cloud/DevOps/AI/ML roles as a recent grad, happy to connect with peers and professionals. #SRE #DevOps #Kubernetes #CKA #Scheduling

𝗧𝗵𝗲 𝗛𝗶𝗱𝗱𝗲𝗻 𝗖𝗼𝘀𝘁 𝗼𝗳 𝗟𝗮𝘁𝗲𝗻𝗰𝘆 Amazon once calculated that every 100ms of latency cost them 1% in sales. They did not just accept it. They invested heavily in speed: ✅ Optimized how pages were rendered ✅ Moved assets closer to customers via CDNs ✅ Streamlined backend systems to cut bottlenecks ✅ Made “latency budgets” part of engineering culture Because they knew that milliseconds compound into millions. Now think about product decisions. Every delayed choice is a kind of latency too. Waiting weeks to prioritize a feature = lost engagement Debating endlessly on scope = missed market timing Postponing critical fixes = frustrated customers 👉 𝗜𝗻 𝘁𝗲𝗰𝗵 𝘀𝘆𝘀𝘁𝗲𝗺𝘀, 𝗹𝗮𝘁𝗲𝗻𝗰𝘆 𝗯𝘂��𝗻𝘀 𝗿𝗲𝘃𝗲𝗻𝘂𝗲. 👉 𝗜𝗻 𝗽𝗿𝗼𝗱𝘂𝗰𝘁 𝘁𝗲𝗮𝗺𝘀, 𝗹𝗮𝘁𝗲𝗻𝗰𝘆 𝗯𝘂𝗿𝗻𝘀 𝗼𝗽𝗽𝗼𝗿𝘁𝘂𝗻𝗶𝘁𝘆. The lesson is the same: Speed matters. Not reckless speed, but thoughtful, decisive movement. Because just like users abandon slow apps, markets abandon slow products. Where do you see the biggest latency in product teams: decision-making, execution, or feedback loops?