Akarsh Thodupunuri

You are in a system design interview at Amazon for an SDE-3 role and the interviewer has given you the question to Design Netflix. He then asks a follow up to you: How does Netflix knows when to show: Are you still watching? Is it just time-based? If it were time-based, you would see it every time. So what is actually going on under the hood? Both look like a simple pop-up. Underneath, it is a mix of product thinking, client logic, and backend events. Btw, if you’re preparing for system design/coding interviews, check out our mock interview tool. You can use it for free here: https://lnkd.in/gpCn7t2T [1] Start from the product goals The feature is not only about nagging people. - Save bandwidth and CDN cost if the viewer has slept or walked away - Avoid autoplaying potentially sensitive content in an empty room - Protect kids if parents start a show and leave the TV on - Do all this without annoying active binge watchers So the design must answer one question: "When is the user probably not here any more" [2] Naive design - pure timer Simplest idea: - If playback has been running for 2 hours, show Are you still watching - If user clicks "Yes", reset the timer Why this is weak: - Someone can binge 5 episodes in a row and gets interrupted in the middle of an intense scene - Someone can start a show, walk away after 5 minutes, and the platform will keep streaming for the next 2 hours - It ignores how many episodes were auto played, device type, time of day, user habits  [3] Realistic design - session and engagement signals Think in terms of a "watch session" and "engagement events". Signals the client can track: - Play, pause, seek, volume change - Episode finished and next episode auto started - Remote or keyboard input, UI navigation - Screen on or off events from the device - For mobiles: app background or locked state A common heuristic could be: - Count how many episodes have auto played without any user interaction - Track how long it has been since the last button press or navigation - Only trigger the prompt when both are high enough Example rule: - If 3 episodes in a row have auto played - And there has been no interaction for 45 minutes - Then, before starting episode 4, show Are you still watching This feels much smarter: - Active viewers who pause, skip intro, change volume keep resetting the "engagement clock" - Sleeping viewers do not touch anything, so the next episode is blocked by the prompt  [4] Client heavy vs server heavy design You can talk about two design choices. Client first: - All logic runs inside the app on TV, mobile, or web - Client keeps an in memory session model and decides when to show the popup - It still sends telemetry events to backend for analytics and future tuning Pros: - Works even with flaky network - Highly responsive, no extra server round trip Cons: - Logic must be implemented and updated across many platforms - Harder to quickly roll out rule changes Continued ↓

184

12 Comments

Layoff impacting H1Bs? Steps to take to stand out as an applicant in top tier companies: 🧭 Part 1: Immediate Steps After a Layoff (for H-1B Holders) 1. Know your grace period: You have 60 days (or until your I-94 expires, whichever comes first) to: • Find another H-1B employer and transfer your petition, or • Change to another visa status (e.g., B-2, F-1), or • Leave the U.S. 2. Request documentation from your employer: • Get your termination letter and final pay stub. • Ask for “good faith termination” documentation, since it affects your H-1B transfer eligibility. • Request severance details and COBRA/health coverage info. 3. Stay active in USCIS systems: • You can file a change of employer as soon as your new company files an H-1B transfer — you don’t need to wait for approval to start working. 4. Consider backup status options: • File a B-2 bridge application if you need extra time to job hunt. • Consider F-1 (study) if re-skilling in tech or management makes sense. 🚀 Part 2: Standing Out in Top-Tier Company Applications Top companies get thousands of resumes per role — so you’ll need to stand out both on paper and in person. Step 1: Optimize Your Resume and LinkedIn • Tailor every resume to the role (use the job description’s key phrases). • Highlight impact, not tasks: Instead of “Managed API integration,” say “Reduced API latency by 40%, improving user retention 15%.” • Use clean formatting and quantifiable metrics. • On LinkedIn: • Add “Open to Work” with specific roles and visa transfer status. • Post short, insightful content in your field (e.g., data product insights, AI in telecom, etc.). • Request recommendations from 2–3 former teammates or managers. Step 2: Target the Right Companies and Roles • Focus on companies with H-1B-friendly track records (Google, Meta, Amazon, Microsoft, Apple, Oracle, Salesforce, etc.). • Use tools like myvisajobs.com and trackitt.com to see who actively sponsors. • Also target mid-sized firms (fintech, SaaS, insurtech, healthtech) that are still hiring even when FAANG slows down. Step 3: Network Intentionally • Use referrals — they increase your chances 10x at top firms. Reach out to ex-colleagues or alumni working there. • Join LinkedIn groups like “H1B job seekers 2025” or “Tech workers in transition.” • Attend virtual events and webinars by recruiting teams (especially Amazon, Salesforce, and Meta). Step 4: Upskill and Brand Yourself • Get visible credentials: • Google PM or Data Analytics certification • AWS/Azure/Databricks certifications • For PMs: “Product Strategy” (Northwestern Kellogg or Reforge) • Showcase projects on GitHub or Notion — even small public examples make a difference. • Start writing micro-articles or posts that highlight your thinking (e.g., “3 Ways AI Is Changing Telecom Product Design”). Step 5: Nail the Interviews • Prepare STAR-format examples that quantify results. • Use mock interview platforms (Pramp, Interviewing.io, Exponent)

2

Positive thoughts to my ex-colleagues at Amazon. A tough period indeed. The first few days after a layoff feel surreal. The silence after the news can be deafening, and the urge to immediately fix everything is strong. But here’s the truth most people don’t tell you , it’s okay to pause. Rest. Let your brain and body catch up to what just happened. Clarity only comes after you exhale. Once you’ve had time to breathe, start treating the next chapter like a strategic reboot. Use this moment to re-evaluate what kind of work excites you and what kind you never want to return to. The layoff might have closed a door, but it also cleared space for something better aligned with who you are now. When you’re ready to re-engage, AI tools can take a lot of the heavy lifting out of the job search. ChatGPT can help you tailor your résumé for each role and practice interview questions. Tools like Rezi and Teal can optimize your resume for applicant tracking systems. Even LinkedIn’s own AI features can help you write stronger “About” sections or suggest better keywords to match your profile with recruiters’ searches. Use this time not just to find another job, but to redesign your career story. A layoff isn’t the end of your professional identity. It’s a forced pause that can turn into your most creative rewrite yet. #Layoffs #CareerGrowth #AItools #JobSearch #Resilience #LinkedInCommunity

10

2 Comments

For me, the recent AWS DynamoDB outage RCA raises more questions than it answers. For example: The EC2 subsystem went through degradation because it depended on DynamoDB for maintaining leases between DropletWorkflow Manager (DWFM), which manages the physical servers underlying EC2’s instance hosting. This brings up an important question: does DynamoDB itself run components like request routers and storage nodes on EC2 instances? If yes, that would create a cyclic dependency between two of AWS’s core services.  If not, does DynamoDB manage its own physical servers and deploy VMs on top of them, and if so, that would mean DynamoDB operates a parallel physical-infrastructure orchestration layer. 🤔

49

3 Comments

Why 90 percent of Kubernetes clusters don’t need Kubernetes Kubernetes is powerful. It is also one of the most misunderstood tools in modern engineering. Over the last few years, I have seen teams adopt Kubernetes the same way people buy a gym membership in January. It feels like progress. Actual results come later, if at all. Most teams do not fail with Kubernetes because it is hard. They fail because they never needed it in the first place. Kubernetes is built for environments where many things are moving at the same time. Many services. Many teams. Many deployments. Traffic that goes up and down unpredictably. Failures that must be handled automatically because humans cannot react fast enough. Now let me describe what I see most often in production. A handful of services. Traffic that barely changes during the day. Deployments once or twice a week. No clear SLOs. No error budgets. One person who “knows Kubernetes” and is permanently on call for it. This is like buying an aircraft cockpit to drive to the grocery store. Yes, it works. No, it does not make your life better. The real cost of Kubernetes is not the cloud bill. It is mental overhead. You now think about pods, services, ingress, networking, RBAC, certificates, rollouts, and why something works in one namespace but not in another. When something breaks, you are no longer debugging your application. You are debugging the platform that runs the application. That is fine if the platform gives you leverage. It is painful if it does not. Many teams believe Kubernetes will fix slow releases, unclear ownership, or fragile systems. It will not. It simply gives those problems more places to hide. For most real workloads, boring infrastructure works better. A managed platform. A clear deployment pipeline. Good logs and metrics. Predictable scaling. Fewer moving parts. Boring systems are easier to understand at 3 a.m. They are easier to explain to new engineers. They break in fewer surprising ways. Kubernetes becomes the right choice when the system itself becomes complicated. When teams start blocking each other. When scaling is no longer obvious. When standardization is required across many workloads. When automation is no longer optional. At that point, Kubernetes stops being an expense and starts being leverage. Kubernetes is not a sign of maturity. It is an amplifier. If your system is simple, it amplifies complexity. If your system is complex, it amplifies efficiency. Use it when you need it. Not when it looks impressive on a diagram. People who have run production systems know exactly what this means. #rajansharma #kubernetes #cloudarchitecture #devops #platformengineering #cloudnative #distributedSystems #softwarearchitecture #engineeringLeadership #scalability #productionSystems #gdg #gdgchandigarh #gdgnewdelhi #gdgahmedabad #gdgnagpur #KCDDelhi #KCDDelhi2026 #Kubernetes #CloudNative #CNCF #CloudNativeCommunity #TechConference

5

Kubernetes makes distributed systems unavoidable. When you build on top of Kubernetes, you are not just shipping application code. You are dealing with failure, coordination, backpressure, latency, and recovery by default. The platform gives you primitives. It does not give you a system. Towards the end of this year, I have been doing some light reading to deepen my understanding of how distributed systems behave when you lean on Kubernetes-native mechanisms. Not to chase novelty, but to reinforce fundamentals that only really show their value once you have operated real systems. This kind of reading lands differently with experience. Concepts stop being theoretical and start mapping directly to production behavior, trade-offs, and failure modes you have already seen. As General James Mattis once said, “If you haven’t read hundreds of books, you are functionally illiterate.” Blunt, but in complex domains like distributed systems, directionally true. You need mental models before intuition becomes reliable. The more complex the systems, the more intentional the reading needs to be.

40

How I Made Decisions at Amazon In 5.5 years at Amazon, I made thousands of decisions. Some were small. Scope tweaks. Deadline shifts. Meeting structure changes. Some were big. Launch calls. Escalations. Resource tradeoffs. Risk acceptance. And here’s what I learned: Indecision is usually more expensive than a wrong decision. Amazon forced me to build a decision framework…not rely on instinct alone. Here’s how I approached it: 1/ I asked: Is this a one-way door or a two-way door? ↳ A one-way door decision is hard to reverse ↳ Long-term architectural changes ↳ Big resourcing bets ↳ Major customer commitments These required deep dive, multiple perspectives, and slower motion. ↳ A two-way door decision is reversible ↳ Pilot launches ↳ Process changes ↳ Messaging experiments These required speed. Most people treat two-way doors like one-way doors. That’s how velocity dies. 2/ I defined the real risk before acting ↳ What’s the worst-case outcome? ↳ How recoverable is it? ↳ What’s the cost of waiting? Often the cost of delay was greater than the cost of being imperfect 3/ I gathered just enough signal…not perfect clarity ↳ 70% confidence was often enough ↳ The remaining 30% came from moving ↳ Over-analysis was a hidden tax on momentum 4/ I wrote my thinking down ↳ Framing the decision in writing exposed weak assumptions ↳ It also made it easier for others to pressure test it ↳ Writing sharpened judgment 5/ I owned the outcome…even when it missed ↳ If a decision didn’t land, I didn’t blame the inputs ↳ I asked: What did I miss? What pattern did I ignore? ↳ Decisions compound…so does accountability The biggest shift Amazon gave me was this: Decisiveness is a leadership trait. But structured decisiveness is a competitive advantage. 📬 I write weekly about clarity, ownership, and high-stakes execution in The Weekly Sync: 👉 https://lnkd.in/e6qAwEFc What’s one decision you’ve been overthinking that might actually be a two-way door?

34

1 Comment