Karan Goel

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

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

I’ve interviewed to 500+ candidates combined in the last 7 years of my journey at Amazon, Cars24, and now Nielsen…(150+ in the last 1 year alone) This is the best guide I can give you on how to pass technical interviews and what 90% of candidates often forget while interviewing. (Btw, I also used this to switch jobs 3 times in my career) [1] Don’t rush to code, talk through the problem first Many candidates fail because they panic and try to impress with fast coding but the right move is to slow down and talk out loud. Break the problem into conditions, use a whiteboard or pseudocode if needed. Even a simple question becomes easy once you write the logic in plain English. [2] Think before you type Take your time to understand the requirements before you touch the keyboard. Rushing leads to bugs. Thoughtful implementation shows maturity. Even if you know the answer, show structured thinking and clear decision-making. [3] Always explain your choices, even if they’re wrong Interviews are less about the correct answer and more about your thought process. Prefer saying something logical than staying silent. For example: “I’m using a regular for loop here because it gives me better control.” [4] Practice talking while solving Most people freeze not because they lack skill  but because they don’t rehearse speaking + thinking. Get used to explaining your logic out loud while coding. Follow the rule: ABC – Always Be Chatting (not just coding). [5] Don’t sit in silence when you're stuck Silence kills momentum. If you get stuck, ask questions: “Should I print this line-by-line or return a result array?” Showing that you can stay calm under pressure matters more than getting it perfect. [6] Prefer readable, scalable solutions over clever tricks Avoid language-specific shortcuts (e.g., JS type coercion). Use modulo instead of overcomplicating divisibility logic. Interviewers prefer clean, maintainable code that works across languages. [7] Optimize code for simplicity and future changes If new conditions are added (like printing something for multiples of 7), your code should be adaptable. Use a variable-based solution instead of nested `if-else` trees. Think like an engineer, not just a coder. [8] Know your basics (like Big-O) Be ready to talk about time complexity. Even if the problem is trivial, say something like: “We’re iterating 100 times, so technically O(n), but since it's a fixed 100, it simplifies to O(1).” Technical interviews are not just a test of memory or speed. They’re also a test of clarity under pressure, structured thinking, and communication.

138

11 Comments

Not supporting the Meta layoffs but after going through the memo by Alexandr Wang wherein he explains the reason for downsizing is to give more opportunity to individuals to make an impact, it makes sense if I look at from my own experience. Companies where I have made the most impact and also stayed longer usually I led projects end to end and took responsibility of making sure the project and the team succeeds. What most executives don't understand that hiring a talented individual is not another cog in the wheel and if they are not given the necessary ownership and power to lead a project along with all the components there is a high chance those individuals will make lower impact than expected. Whenever I led other engineers I made sure they are given the entire responsibility of one particular area with all possible components instead of assigning fractional tasks to multiple devs.

24

Stop treating Load Balancers and Reverse Proxies as the same thing. In System Design interviews (and production incidents), the distinction matters more than you think. As we move from SDE1 to SDE2, we stop asking "How do I make this code work?" and start asking "How does this system scale and survive failure?" Here is the deep dive on two critical components that often get conflated. 1. The Load Balancer (The Scaler) Primary Goal: Availability & Horizontal Scaling. The Job: Spreading traffic across multiple compute resources to eliminate Single Points of Failure (SPOF). The SDE2 Nuance: You need to know the difference between Layer 4 (Transport) and Layer 7 (Application) balancing. L4 is fast; it forwards packets based on IP/Port without looking inside. L7 is smart; it terminates the connection, reads the HTTP headers/path, and routes /api differently than /images. 2. The Reverse Proxy (The Shield) Primary Goal: Security, Unification & Offloading. The Job: Sitting in front of backend servers to hide their topology and IP addresses. The SDE2 Nuance: SSL Termination. Decrypting HTTPS handshakes is CPU-intensive. A Reverse Proxy handles this heavy lifting at the edge, allowing your backend application servers to focus purely on business logic (and communicate via HTTP inside the private VPC). The Reality Check 💡 In modern architecture (and cloud environments like AWS ALB or tools like NGINX), the lines blur. We often use a single component to perform both roles simultaneously—terminating SSL (Reverse Proxy) and then distributing the request to a pool of instances (Load Balancer). But knowing which function you are tuning—and why—is what separates a mid-level engineer from a senior one. Questions for the network: Do you prefer handling SSL termination at the Load Balancer level or strictly on the application server for end-to-end encryption? #SystemDesign #SDE2 #SoftwareEngineering #Scalability #DistributedSystems #DevOps

66

1 Comment

Ever wondered how #Amazon 's #BarRaisers decide who gets #hired? I’ve been on both sides of that table — as a candidate and as a hiring manager — and here’s what most people don’t realize 👇 Amazon’s Bar Raisers aren’t just checking if you’re smart. They’re testing if you think like an Amazonian. Here’s what they look for: 💡 1️⃣ Clarity in Ambiguity When the question is fuzzy or open-ended, do you freeze... or do you structure it? Bar Raisers love candidates who dive deep, make trade-offs, and reason out loud. Because that’s what real ownership looks like on the job. 🧠 2️⃣ Curiosity in Action Smart isn’t “knowing it all.” It’s knowing what to learn and how fast. They look for people who stay curious and adapt when the ground shifts. 🧩 3️⃣ Depth Over Breadth Are you just executing tasks… or shaping them? Surface-level answers signal compliance. Depth signals backbone — a key Amazon principle. 💬 Reality check: You don’t need perfect answers to impress a Bar Raiser. You need structured thinking, clear ownership, and curiosity under pressure. 💡 Takeaway: Bar Raisers don’t pick the smartest person in the room — they pick the one who can stay calm, think deeply, and own the problem. 👉 Have you ever had an Amazon interview that felt more like a debate than a Q&A? That was probably a Bar Raiser round. #Amazon #Hiring #LeadershipPrinciples #CareerGrowth #Interviews

41

4 Comments

When Claude Code Joined Our Team in the Middle of a Tech Scavenger Hunt Yesterday, our randomly assembled team of four engineers joined an intense tech scavenger hunt at InMobi Encore2025 - packed with coding challenges and technical riddles. The team: Me (Staff Engineer – Frontend) An SDE2 – ML An SDE3 – Backend Another Staff Engineer – Backend One puzzle stopped us cold: two giant parquet datasets (~750K rows each) hiding a riddle about bids, floors, installs, and a “final pattern” buried deep inside. My teammates? Instantly spinning up Databricks, notebooks, pandas. Me? No relevant setup. No DS tools. Just sitting there, watching the clock tick, feeling like dead weight. 💡 The Lightbulb Moment "Why not try Claude Code?" I dropped the datasets and riddle in with few more lines of instructions. And while we were still stuck on the first step, Claude tore through: Filtering down to iOS/Android Checking bid floors Finding the winning ads (render + click + install) Merging on impression_id Revealing a Fibonacci sequence in time_to_install Answer: 34. “Guys, just enter 34.” Suspicious stares. A pause. Then… Correct! That single AI-powered leap saved us 10-15 minutes and flipped the game. From that point on, Claude became our fifth teammate. Takeaways: In tech, the boldest move is often trying what looks unconventional AI can be a genuine partner in problem-solving Resourcefulness > perfect setup And sometimes, success in uncharted territory comes from being willing to try what others dismiss I may not have written a line of pandas, but being open to AI meant I could unlock value my team didn’t expect. PS: We didn’t win the contest, but we came very close — only to be tripped up in the last round that required us to actually run around the office for the answer. Turns out, AI has its limits 😉 #AI #Engineering #ProblemSolving #Teamwork

30

2 Comments

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

A Reddit thread made me invest in 108 apartment units—and start my own company. I have been a software engineer at Meta for four years now; I started my career in 2019. From day one, I wanted to get on the right track and build a career that could create generational wealth for my family. I’m grateful for a path that has taught me discipline, given me mentors, and helped me save. In 2019, I read Rich Dad Poor Dad and thought I’d build a small single-family rental portfolio. I even earned my realtor’s license on Leap Day 2020 to learn the fundamentals and stack a little extra cash. Then a friend sent me a real-estate Reddit thread about syndications. I didn’t know anyone doing it and it sounded too good to be true, so I went deep. For a year I underwrote deals after work, called operators and property managers, asked existing LPs what went wrong, and tried to poke holes in the model. In August 2021, I wired into my first deal: 108 units in Texas. When the first distributions landed and depreciation showed up at tax time, it clicked—scale, professional management, and diversification made more sense for my goals than buying one door at a time. That experience became the blueprint for Clive Capital. I started Clive to help family, friends, and other busy tech professionals co-invest the way I wished I’d known from day one—partnering with strong operators, diversifying across markets and asset types, and treating diligence like a first principle. Since then, we’ve expanded beyond multifamily into other assets, with investors spread across the country. If you’re where I was, curious but cautious, this episode walks through my exact process and what I’d repeat today.  🎧 Full story + playbook: https://lnkd.in/e24ZHhHA

6

2 Comments

I sat down for 2 hours and recalled every coding interview I’ve given in the last 8 years of my career at Google, Meta, Microsoft, Amazon, Hotstar, Dunzo and many other companies... Here are the topics that I was asked about (in order of fundamentals): 1// Category 0 – Absolutely Fundamentals These topics are non-negotiable. If you skip these, you’re setting yourself up for a tough time in every interview, no matter the company. - Dynamic Arrays - String Manipulation - Two Pointers - Grids & Matrices - Binary Search - Sets & Maps - Stacks & Queues - Recursion - Sorting - Linked Lists - Trees - Graphs Master these inside out before touching anything else. 2// Category 1 – Fundamentals+ Once you’re solid on the basics, double down here. These topics show up a lot in interviews, and depth here will help you stand out: - Heaps - Sliding Windows - Backtracking - Prefix Sums - Dynamic Programming - Greedy Algorithms - Topological Sort This is where you move from “can solve problems” to “can solve tough problems quickly.” 3// Category 2 – Going Above and Beyond If you want to really separate yourself, go above and beyond, tackle these topics.  - Monotonic Stacks & Queues - Union-Find - Data Structure Design - Set & Map Implementations - Tries - Graphs (Advanced) - Dynamic Programming (Advanced) - Bit Manipulation - Math Don’t chase 100 topics at once. Start from the core, then build up. When you master the right order, you’ll never feel lost in an interview again.

1,328

63 Comments

Amazon laying off ~16,000 people in 2026 isn’t a surprise. It’s a signal. Amazon has gone through multiple layoff waves since 2022. This one isn’t about a sudden crisis - it’s about structural correction. A few underlying reasons stand out: 1. Post-hypergrowth reality Amazon scaled for a world that assumed permanent pandemic-level demand. That demand normalized faster than org structures did. Headcount inertia is real -markets are not. 2. Management layers grew faster than value creation In large orgs, complexity compounds quietly. Teams multiply, ownership blurs, coordination costs rise. Layoffs often target overhead, not talent - but people still pay the price. 3. AI is changing the cost curve Not by “replacing everyone,” but by reducing the need for parallel roles, support layers, and manual coordination work. Fewer people can now run the same systems - or more ambitious ones. 4. Capital discipline is back Cheap money masked inefficiencies. With tighter capital expectations, companies optimize for return per employee, not headcount as a signal of ambition. 5. Strategy refocus, not retreat This isn’t Amazon shrinking from the future. It’s reallocating bets - doubling down on fewer priorities while exiting others. The uncomfortable truth: Layoffs at this scale are less about performance and more about organizational physics. For professionals, the lesson isn’t “big tech is unsafe.” It’s this: 👉 Resilience now comes from skills, adaptability, and leverage, not logo strength. 👉 Value creation beats role security. 👉 Being close to revenue, customers, or core systems matters more than ever. This isn’t just an Amazon story. It’s the operating model of modern tech resetting in public. #Tech #Leadership #ProductManagement #FutureOfWork #AI #OrgDesign #Amazon

6

1 Comment

Shantanu Narayen’s 18 year tenure as CEO at Adobe is a reminder of how rare long-term stewardship has become in Silicon Valley. During his time with the company, the company’s stock increased more than 6x and its business model fundamentally changed. The most important decision of his tenure was moving Adobe from selling boxed software like Creative Suite to a subscription platform through Creative Cloud. At the time it was controversial. Today, it is considered one of the most successful SaaS transitions in the history of enterprise software, turning Photoshop, Illustrator, and Acrobat into one of the most profitable recurring software ecosystems ever built. The respect he commands across the industry says a lot about how difficult that transformation actually was. Microsoft CEO Satya Nadella even posted publicly congratulating Narayen on a “legendary run,” praising both his leadership and the way he expanded what creators and businesses could do with software. In an industry that is often intensely competitive, that kind of recognition from peers is not given lightly. There are only a few CEOs in the world who truly get to define one era of software and then help set the stage for the next. Narayen did it by turning Adobe into a SaaS powerhouse. However, the next leader will have to answer a harder question. What does a creative software company look like when AI becomes part of the creative process itself? #Adobe #Leadership #SaaS #AI #Technology

10