Dev Kashyap

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

When I lived in Hyderabad, one of my favorite restaurants was Chutneys. When they opened a branch in Inorbit Mall, I was genuinely happy because it was closer to where I lived. What surprised me was the scale of their waiting area. In an expensive mall like Inorbit, Chutney’s had invested in a large, comfortable waiting space with luxurious sofas, almost indistinguishable from the actual seating area. I remember thinking the investment must have been huge, but it made the experience feel effortless. People could wait without feeling frustrated, even during peak hours. I experienced something similar in a very different context a year or two ago, while admitting my child to school. For some reason, we reached the admission venue two hours early on a weekday. Only after arriving did we realize we had forgotten our documents at home. We rushed back, we got the folder, and everything worked out. Had we arrived just in time, we would have missed the admission entirely. Given how selective the school was, that would have meant losing a carefully chosen opportunity or creating a lot of avoidable stress. Much later, while reading Thinking in Systems, these two incidents suddenly connected. Donella Meadows talks about buffers as one of the most powerful but often misunderstood elements of a system. A buffer is simply the size of a stabilizing stock relative to its flows. Time, inventory, space, patience, slack, and margin are all buffers. Buffers come at a cost. Maintaining extra capacity, time, or inventory always feels inefficient. Reaching two hours early meant taking time away from something else. Chutney’s waiting area meant higher real estate and furnishing costs. But buffers exist precisely to absorb variability and uncertainty. They prevent systems from failing when reality does not behave as planned. Buffers also reduce oscillations. For example, manufacturing systems that respond to rising demand by aggressively increasing orders, only to be overwhelmed with excess inventory when demand falls. Without adequate buffers, delays and overreactions amplify swings. With buffers in place, the same system becomes calmer, more predictable, and far less stressful to operate. Whether in supply chains, restaurants, or our personal lives, buffers act as shock absorbers. They smooth fluctuations, reduce anxiety, and prevent small mistakes from cascading into major failures. Not everyone can afford large buffers all the time, but Thinking in Systems makes one thing clear: systems without buffers are brittle. Sometimes, all you need is a little margin.

56

6 Comments

When you join a new org or switch teams in the same, it is quite an unsettling and borderline anxious experience. Here are a few things that I did to ramp up faster. 1. I consciously made an effort to remain unblocked 2. I read a ton of code and its history, sometimes even unrelated 3. I asked questions about the past, the present, and the future 4. I took up relatively mundane tasks - cross-team work, tests, and docs 5. I extended a helping hand in whatever capacity I could 6. I proactively met skip-level leaders and managers to understand the vision Some companies do have a culture of pairing up with someone existing in the team, but even if you do not get a mentor, it is important that you still navigate the situation and ramp up as quickly as you can. The above list is not exhaustive, by any means, and hence you can always add things that you find helpful in your context. but the lowest common denominator is to show extreme intent and interest to get output and drive outcomes. Hope this helps.

995

25 Comments

Silicon Valley was built on Indian talent 🇮🇳, and now it’s our turn to create that ecosystem here. Talent alone isn’t enough — India needs stronger R&D funding, better AI infrastructure, and the courage to innovate beyond just copying models. If we get the intent right, “Silicon Valley Bharat” won’t just be a dream — it can be our reality. 🚀

15

1 Comment

Amid new H-1B visa curbs getting implemented this year, the major US tech firms-Facebook (Meta), Amazon, Apple, Microsoft, Netflix, and Google (Alphabet) closed 2025, collectively hiring over 32,000 new employees in India. FAAMNG companies reported an 18% YoY uptick in hiring in specialised roles in India, with another 3,000-5,000 active job openings. https://lnkd.in/gynKeext

20

1 Comment

Salim FEKU not able to digest NoSQL databases are converging to PostgreSQL. Setting: A chai ki dukaan (tea stall) in Hyderabad. Salim Feku is holding forth, gesturing wildly with his chai glass. (Salim Feku sips his chai, then puts the glass down with a flourish, looking around at an imagined audience.) SALIM FEKU: Arre bhai, aaj kal ki duniya mein kya chal ra? Sab bolte, "PostgreSQL, PostgreSQL!" Kya hai re usmein? Apun bolta, woh to puraane zamane ka ghoda hai! (He leans in conspirantly, lowering his voice slightly but still loud enough for everyone to hear.) SALIM FEKU: Suno tum meri baat, agar tumko asli data rakhna hai, jo kabhi nikalta nai, jo tezz bhaagta, toh tumko NoSQL hona bhai! Yeh PostgreSQL, woh to apna aadmi, kaisa... sara din join lagate baithta. Ek table se dusra table, dusre se teesra... Arre baba, jab tak woh join lagake data nikalta, apun chai pi ke doosra dhanda kar leta! (He chuckles, shaking his head.) SALIM FEKU: Apun ke paas kya hai? MongoDB! Arre kya cheez hai woh! Tum feko usmein kuch bhi! Document feko, JSON feko, apun ka data, seedha andar. Koi tension nai. Woh PostgreSQL, usko pehle batao 'column' kya hai, 'row' kya hai, 'schema' kya hai. Arre baba, itna sochne mein hi system slow ho jata! (He snaps his fingers.) SALIM FEKU: Aur suno, jab apun ka traffic aata, haan? Croreon log aate, kya karte? Woh PostgreSQL to ek machine pe baitha rehta. Apun ka Cassandra, DynamoDB... yeh log kya karte? "Arre bhai, thoda data tu le le, thoda data main le leta," bolke baant lete. Shaana log! Sab milke kaam karte, isliye apna system kabhi rukta nai, bhai! Woh PostgreSQL ko to pasina aa jata! (He gestures expansively, like he's spreading data everywhere.) SALIM FEKU: Woh bolte, "Hum consistent hai!" Arre haan, theek hai. Lekin consistency ke chakkar mein kya, apna customer wait karte baithta! Apun ka NoSQL? Woh bolta, "Thoda late aaya to kya hua? Aayega to sahi! Customer khush hona, jaldi result aana!" Zara sa "eventually consistent" hua to kya hua? Duniya to chalte rehti na! (He lowers his voice again, for the grand finale.) SALIM FEKU: Toh bhai, agar tumko naya, tezz, bina tension ka system banana hai... toh woh puraane dimaag ke relational ko choro! Apun ka NoSQL, woh hai asli king! Baaki sab to... chillar hain! (Salim Feku takes another proud sip of his chai, looking very pleased with his pronouncement.Just then, his eyes fall on someone approaching the chai stall. His confident smirk vanishes, replaced by a look of surprise, then forced cordiality.) SALIM FEKU: (Suddenly a soft, almost meek tone) Arre! Kaun? Ismail Bhai... PostgreSQL wale!?! (He rushes forward, abandoning his lecture, ) SALIM FEKU: Aao Miya! Kaisa hai tum? Tumhari hi raah dekh raha tha main! Kaisa, sab khairiyat? Woh, woh main to... ...main to bas logon ko bata raha tha ki purani cheezo ki reliability kitni zaroori hai! Haan! Tumhari hi baat kar raha tha, bhai! Maine suna..tum bhi distributed ho gaye!!!

8

There is a quiet habit in many organizations that I believe we should rethink. Calling engineers "resources". At first glance, it may sound harmless. But words shape culture, and the difference between an engineer and a resource is deeper than terminology. A resource is something you allocate. A resource is interchangeable. A resource is planned in spreadsheets and capacity charts. But an engineer is something entirely different. An engineer is a problem solver. An engineer designs systems that didn’t exist before. An engineer takes ambiguity, constraints, and trade-offs and turns them into working reality. You cannot allocate creativity. You cannot schedule curiosity. You cannot spreadsheet innovation. When we call people "resources", we unintentionally reduce them to units of output. When we call them engineers, we acknowledge their judgment, craft, and ownership. The difference shows up in how teams behave. When people are treated like resources: • Work is assigned. • Thinking is minimised. • Ownership is diluted. When people are treated like engineers: • Problems are shared. • Ideas are encouraged. • Systems improve. Great companies are not built by managing resources efficiently. They are built by empowering engineers to think, question, and create. Language matters because culture follows language. Maybe the shift is simple: Instead of asking, "Do we have enough resources?" Ask, "Do we have the right engineers solving the right problems?" Small change in words. Massive change in mindset. #eBay #EngineeringCulture #Leadership #TechLeadership #SoftwareEngineering

103

6 Comments