YILANG LI

You are in a system design interview at Google for the L5 Senior Engineer role, and the interviewer leans in and asks: “Why does Spotify keep playing when I drive into a tunnel with no signal, but YouTube Music often stops or buffers? If you were designing a music streaming system, what different design choices would lead to these two behaviors?” Here is how you break it down. 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 We’ve added new features as well:  -Company-specific interviews -In-built interview scheduler  -performance insights & trends — Both apps look like simple music players. Under the hood, they are optimized for very different priorities. [1] Spotify style – Cache first, stream second Idea: The client behaves like a smart offline player that happens to stream. The backend is built to support aggressive prefetching. What happens when you hit play - Client requests the track from a CDN or edge node. - Instead of tiny chunks, it downloads a big buffer ahead of the playhead. - In parallel, it starts pre downloading the next few tracks in the queue. - Data is written to an encrypted cache on disk, not just memory. - Playback reads from that local cache, not directly from the network socket. What this means for tunnels and bad networks - When the network drops, the player already has tens of seconds or entire tracks cached. - Because the next one or two songs are already downloaded, you can be offline for a while and never notice. - Cold start cost is a bit higher. First play might take slightly longer, but then everything feels smooth. - It burns more local storage and possibly more data, because not every prefetched song will be listened to fully. In a design answer, you can mention - Local disk cache with eviction policies (LRU per user, per device). - Background prefetch of N upcoming tracks based on queue. - Download manager that adapts how aggressively it prefetches based on network quality and user settings. - CDN tuned for larger object delivery and range requests. - Explicit offline mode that pins playlists into cache. [2] YouTube Music style – Stream first, cache is minimal Idea: Treat audio like video streams. Cost and bandwidth are optimized first. When you hit play - Player requests audio (and sometimes video) via HLS or DASH-style chunks. - Each chunk is only a few seconds long. - Client keeps a small rolling buffer in memory, not a large queue on disk. - Prefetch of future songs is limited, because video tracks are large and expensive to fetch speculatively. What this means for tunnels and bad networks - If your connection dies, the player only has a few seconds of buffered data. - As soon as those chunks are consumed, playback stalls. - Startup can feel snappy and data usage is controlled, especially for casual listeners. - Works very well on stable networks, feels fragile in spotty coverage.

1,219

38 Comments

𝗧𝗵𝗲 𝗯𝗲𝘀𝘁 𝗔𝗜 𝗰𝗼𝗱𝗶𝗻𝗴 𝗹𝗲𝘀𝘀𝗼𝗻 𝗰𝗼𝘀𝘁 𝗼𝘂𝗿 𝗲𝗻𝗴𝗶𝗻𝗲𝗲𝗿 $𝟲𝟬𝟬 𝗮𝗻𝗱 𝗮 𝗺𝗮𝗿𝗿𝗶𝗮𝗴𝗲 𝗮𝗿𝗴𝘂𝗺𝗲𝗻𝘁. Our VP of Engineering, Xiaofan(James) Luan, was supposed to buy his wife a Dior bag for their anniversary.  Instead, he bought three Claude Code subscriptions and spent the holiday trying to cross-compile 2 million lines of C++. Every fix on one platform broke two others.  $600 later, the only output was "git reset --hard" — and a very cold dinner table.😂 "Make it compile on Windows" is a trap. The real goal was "compile everywhere without hacks" — no AI is going to figure that out for you at 2 am. What worked: constraints before code, review tests not code, bottom-up, one layer at a time. Same task, two days. Then he ran six parallel Claude sessions across three machines with git worktree. The bottleneck stopped being intelligence and started being how fast one person can alt-tab. AI solves exactly the problem you give it. Engineering is in knowing which one to give. His wife is still waiting for that bag. Full story: https://lnkd.in/gtsW_Wvk ——— Follow Milvus, created by Zilliz, for everything related to unstructured data

9

Why does an E3 level SWE at Meta make only ~190k/year, while an E8 level engineer makes over ~$2M/year, even though both engineers are ICs and spend the same time at work? I have spent the last 5 years at Meta as an IC. I joined with a little over 15 years of experience, and I’ve worked with many solid engineers in this time. Here is how I think about that compensation jump. 1. Same hours, completely different “unit of work” An E3’s unit of work is usually a task or a ticket. An E8’s unit of work is a multi year problem for the company. E3: “Implement this service, fix this bug, write this feature.” E8: “How do we cut infra cost by 20 percent across this product” or “How do we make this platform safe to scale to 10x users.” One person is paid to execute. The other is paid to decide what is worth executing in the first place. 2. Radius of impact E3 usually impacts a file, a service, maybe a small team. E8 shapes whole orgs and product lines. If an E3 ships something great, the impact is great but local. If an E8 ships the right platform, hundreds of engineers become faster and the company saves or earns millions every year. Comp tracks the area of the circle you influence. 3. Risk and downside protection At junior levels, mistakes are usually contained and reversible. At senior staff levels, a bad call can burn tens of millions or damage the brand. E8s are paid for judgment under ambiguity. They decide which bets the company should not make, which migrations can wait, which “shiny idea” is going to kill reliability. You pay more to people whose good judgment protects you from very expensive failures.  4. They scale themselves This can happen in a few ways. 1. Delegation with ownership They define the shape of the problem, then hand large pieces to other senior and mid level engineers while keeping the bar and direction clear. 2. Knowledge that travels They write RFCs, public comments, FAQs, wikis, internal posts. One answer helps hundreds of people who will face the same issue next quarter. 3. Tools over heroics Instead of unblocking people manually all day, they build tools, libraries or guardrails so others can unblock themselves. One well designed tool can save thousands of engineering hours every year. This is what “scaling yourself” actually looks like. The company pays for that multiplier.  5. Ownership of the “uncomfortable problems” Junior engineers usually work inside a well defined box. E8s take ownership between the boxes. They pick up problems that:  Span many teams and no one really “owns”  Require aligning leaders who disagree  Have product, infra, legal and security angles at the same time Most people avoid those because they are messy, political and slow. Very senior ICs lean into them. That is where a lot of value sits. Continued ↓

201

15 Comments

Introducing the M5 The M5 chip brings significant advancements in performance and efficiency across various applications. 1. Massive GPU / AI performance boost The M5 features a next-generation 10-core GPU architecture, with each core equipped with an integrated Neural Accelerator. This results in over 4× the peak GPU compute performance for AI tasks compared to the M4. 2. Stronger CPU and enhanced Neural Engine With up to a 10-core CPU (6 efficiency cores + 4 performance cores), the M5 offers approximately 15% faster multithreaded performance over the M4. Additionally, the Neural Engine has been upgraded to 16 cores, enhancing performance for on-device AI and intelligent features. 3. Higher memory bandwidth / unified memory improvements The M5 provides around 153 GB/s of unified memory bandwidth, which is approximately 30% more than the M4. This unified memory architecture allows all components (CPU, GPU, Neural Engine) to access a larger memory pool, enabling larger AI models to run entirely on-device. 4. Graphics & rendering enhancements The improvements in the GPU also boost graphics performance, including ray tracing capabilities. Apple claims up to a ~45% uplift compared to the M4 in ray-traced workloads, enhancing visual fidelity, rendering speed, and smoothness in demanding 3D and graphics applications. 5. Deployment in new hardware + energy efficiency / environmental goals The M5 will power new devices, including the 14-inch MacBook Pro, iPad Pro, and upgraded Vision Pro, all of which are available for pre-order.

7

If you're a Senior Engineer looking to move up, the next role will likely be a Staff Engineer. And in this guide, Shruti shares tips from her own experience of getting promoted to Staff Engineer at PayPal and Slack. She talks about what Staff Engineers do (and how it's different from Seniors), why you might not be getting promoted, and how to take that next step. https://lnkd.in/g58dnFEG

103

3 Comments

Why the Amazon Layoffs are a Wake-up Call for Every Engineer The era of "pattern-match engineering" is closing. Recent reports show Amazon cutting thousands of corporate roles as part of a deeper pivot toward AI-augmented productivity. This isn't just about cost-cutting; it's a fundamental shift in what the industry values. Any work that relies on applying matured designs to new cases by following a set pattern is now within the territory of AI. If your value is purely in the execution of these patterns, that value is rapidly depreciating. To remain non-replaceable, we must shift our focus: From Execution to Architecture: Don't just follow the pattern; design the system that leverages it. From Bandwidth to Innovation: Use AI to handle the repetitive "heavy lifting" so you can reclaim your time for new, high-value innovation. From Coder to System Shaper: The most valuable engineers today aren't just writing code; they are directing AI to produce results and solving the complex problems AI can't yet touch. The goal isn't to compete with AI—it's to leverage it to expand your own impact. In an industry that is "right-sizing" through technology, those who use AI as a force multiplier will be the ones who lead the next wave. https://lnkd.in/g2RHA4zr

57

2 Comments

I didn’t stay and grow at Amazon for 5 years just because I could write good code. Plenty of smart engineers can do that every single day. Writing clean code was just the entry ticket. What truly set me apart was taking ownership, even when it wasn’t asked. If I was assigned a bug to fix, I could’ve stopped after the code review. But I would follow it to production, sit with support teams, talk to impacted customers, and make sure the bug was truly gone, and people felt the difference. If I was asked to build a new API, I could’ve stopped after passing the unit tests. But I’d stress-test it with real traffic, set up alerting, write docs, and hop on calls with downstream teams to make sure their integration was smooth. If I noticed on-call alerts going off every night, I could’ve shrugged and marked them as “infra issues.” But I dug into root causes, ran post-mortems, and sometimes pulled late nights re-architecting fragile parts, so the next person on call wouldn’t have to lose sleep. If I wrapped up my sprint tasks ahead of schedule, I could’ve clocked out early. But I’d sit with teammates struggling with blockers, offer code reviews, and even pick up “thankless” chores like improving internal tools or onboarding docs. Ownership isn’t about heroics or working 14-hour days. It’s about caring enough to see things through, to fix the root, not just the symptoms. To ask, “What else could go wrong?” and, “How can I make this easier for the next person?” That’s how you get noticed. That’s how you build trust. That’s how you grow. Don’t just be the engineer who writes code. Be the one who owns the outcome, end to end. That’s what really sets you apart.

296

10 Comments

This was a good discussion about the Principal Engineer role at Amazon! I often say that the Principal Engineer role as it exists at Amazon simply doesn't make sense at smaller companies. To many, the title just means the next highest level of engineering skills. At Amazon, it requires dealing with high levels of ambiguity, business strategy, and organizational influence. If you're at a company with <50 people, the person with that level of influence should be leading the whole technical organization - it requires a significant amount of scale before it makes sense to have an IC role for it. I also personally appreciated Steve's points on internal level progression - or as Gergeley says, "Why being promoted from Senior to Principal at Amazon is one of the hardest jumps in tech." Steve: "Basically, to get from senior to principal, you have to do like two and a half level jump, from L6 to L7. Technically, it sounds like one level, but at some other companies, this might be like, you know, L8, L9 or L8 and a half. [...] I noticed that some of the best engineers that I'd ever worked with were having such problems getting to principal engineer that they ended up moving to Facebook or to Meta or to all these other places where the progression was sane. Now they're senior staff and, you know, principal and distinguished engineer at other companies. And so because we had high standards, we actually had this brain drain." In addition to the level itself being a big jump the promotion process is notoriously arduous and arbitrary. While I was L6, I had multiple managers over several years acknowledge that I was doing L7 work, and even agree that if I was being hired in from outside I would be hired at L7, and it was the internal promotion process that was the barrier. This was not the *only* reason I left Amazon, but it certainly made it very easy to do. Amazon has lost a lot of skilled engineers this way, but it's a difficult problem to fix, since the incentives are fundamentally badly aligned. If an L6 engineer is already doing the work that's needed, it's very hard for a manager to justify spending the 100+ hours of work it takes to advocate for their promotion. And while there have been attempts to make the process less arduous, no one wants to be seen as "lowering standards." I highly encourage engineers in that position to make it clear they will not be continuing to do work that way indefinitely. And I encourage leaders at other companies to learn from the example! https://lnkd.in/guC35n2B

3

4 Comments