Zheyu Li

Signs and wonders If there was ever any doubt in the last month about the changing nature of our industry and the role of an engineer within it, those have been cast aside. The Seattle Times published this article today https://lnkd.in/gpSetTJ3. LeadDev asserts that interviewees might be penalized for not using AI https://lnkd.in/ggNsGqSx.  All of this points to such a drastically changed landscape from even 2 years ago that we all have to loop AI into our processes as we look for work and query those in a hiring position.  I don't necessarily see these positions as new, or very eye opening from opinions I have been forming over the past month. And certainly there are no lack of opinions surrounding AI. But they do buttress the idea that, as job seekers, we are hobbling ourselves if we don't know how to use these new tools. LeadDev even says we will have a hard time getting in the door.   One quote stuck out to me in that Times' article though. "Writing code is more fun than reading code". This points to the assertion that we still need that developer in the loop; we still need that head check to make sure what our AI is spitting out is still workable. As I have been working on new projects & side hustles this month, I spent some time vibe coding and put up https://lnkd.in/g7W3J4WJ. It's a fun remix studio that remixes your audio mp3s in the styles of several iconic producers: J.Dilla, Steve Albini, Scott Burns. It's an idea generator for your mixes if they sound flat or you are just trying to get them to sound different and don't know which way to go.  But and so anyway, AI mostly did that. And AI mostly messed it up. From not understanding memory management, to screwing up the integration from the front end to the backend. Were it not for the developer in the loop there would be just a bunch of UI that doesn't go anywhere and a bunch of backend code that errors out. It is hard to not get frustrated with a tool that gets you 70% of the way to a working solution, but chokes on the last 30%. Keeping in mind though that if I were to have done this from the ground up without AI, that solution would have taken more than a week of dilligently coding and researching. And whereas that seems like the way to get to a holistic solution where bugs are found early and workarounds are smoothed out to actual paths, the payoff; the proof of concept would have been a long way off. With AI it took 4 hours. What is missing here though is the high level thinking of the solution. For instance, as developers our coding always always always generates more ideas. What other ideas did I miss in letting AI take control?  

7

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

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

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

80

Imagine you just joined Google as an SWE. It’s your first week, and you’re overthinking everything. You’re surrounded by world-class engineers, new systems, and an overwhelming urge not to mess up. The pressure to prove yourself is real, and so is the anxiety…so what should you do? Over the years, I’ve moved across orgs, teams, and sometimes, entire companies. Here’s exactly what I did (and still do) to ramp up faster and enjoy the process without letting anxiety win → Don’t let yourself stay stuck. If you’re blocked for more than 30 minutes, ask for help. Share what you’ve tried, show initiative, and intent. → Read way more code than you’re assigned. Dive into related modules, historic PRs, and old design docs. The context you gain helps you spot patterns and avoid mistakes. → Ask about the story behind the system. Find out why things are built a certain way, what’s failed before, and what’s on the roadmap. Understanding the “why” beats memorizing the “what.” → Volunteer for unglamorous work. Take ownership of tests, docs, or nagging integration bugs. This is where you quietly learn the most and build your internal network. → Offer help before you’re an expert. Chime in when you see questions, review PRs, or share a script. Even small contributions get you noticed for the right reasons. → Connect with skip-levels and cross-team leads. Set up short intros to learn about the broader vision and team priorities. You’ll spot opportunities to add value beyond your immediate tasks. → Document what you learn as you go. Share notes, update READMEs, or post quick how-tos in team channels. Your future self and your teammates will thank you. → Shadow someone during incidents or launches. Sit in on debugging sessions or war rooms, even if you’re just observing. You’ll see how senior folks think, react, and communicate under pressure. → Keep a running list of “how did that break?” moments. Every time you see a system fail or a hotfix go live, dig in. Reverse-engineering past problems is the fastest way to understand the architecture. → Show up with curiosity and intent, every day. Don’t just tick off JIRA tickets. Look for the bigger picture. People notice when you genuinely want to learn and contribute, not just “do your job.” Some orgs assign mentors, some don’t. Either way, these habits put you in the driver’s seat. Ramping up is less about brilliance, more about consistent intent. And the ones who learn this early end up leading teams later.

709

51 Comments

The Question That Changed How I Approach Technical Decisions Early in my career, I thought being a senior engineer meant writing the best code. I was wrong. At Amazon/IMDb, I learned that senior engineers are measured by the quality of their decisions, not just their code. And one question has become my North Star: "What would it take to reverse this decision 6 months from now?" This simple question has saved our team from countless bad architectural choices. Here's why it works 👇 It forces you to think in terms of: ✅ Reversibility - Can we undo this without a full rewrite? ✅ Cost - What's the migration effort if we're wrong? ✅ Risk - Are we betting the farm or experimenting safely? Real example from IMDb: We were choosing between two state management approaches for our micro frontend platform. One was cutting-edge, one was boring and proven. The cutting-edge option was tempting. But answering the reversibility question made it clear: Migration cost: 6 months of team effort Risk: High (unproven at scale) Reversibility: Extremely difficult We chose the boring solution. Six months later, our requirements changed significantly. Because we'd chosen the reversible option, we adapted in 2 weeks instead of 6 months. The framework I now use: One-way doors (hard to reverse): Spend 80% of your time here. Get alignment. Prototype. Test assumptions. Two-way doors (easy to reverse): Move fast. Learn by doing. Don't overthink. Being senior isn't about always being right. It's about making decisions that keep your team moving forward, even when you're wrong. 💬What frameworks or questions guide your technical decisions? Drop them in the comments - I'm always learning.

4

With all the recent tech layoffs, I know many talented and experienced engineers are finding themselves updating their resumes, sometimes for the first time in years. It’s not easy, and the job market can feel uncertain. To support anyone navigating this transition, I wrote an article with 5 practical resume tips that help your experience stand out clearly to recruiters and hiring managers. 🔗 https://lnkd.in/gxZPWJf8 Even if you haven’t been directly affected, these tips are useful to keep your resume sharp and ready. You never know when the right opportunity may come your way. Feel free to share it to someone you know that would find it helpful. Wishing everyone the best in their career journeys, keep building, keep growing. 💪 #TechLayoffs #EngineeringCareers #ResumeTips #JobSearch #SoftwareEngineering

23

1 Comment

Entry-level SWE: $80K. Senior (5-7 years): $360K. Staff at FAANG: $500K-$900K+. Whether you started at $70K or $90K won't matter in 5 years. The real cost of holding out: 6 months of unemployment = $31K in lost wages. Holding out for an extra $10K/year while unemployed for 6 months? You're down $21K net. What one year of experience unlocks: Job hoppers see 15% average raises when switching. Some see 20-30%. Start at $80K. Work one year. Switch jobs with a 15% raise. You're at $92K. That's more than the $90K offer you turned down. What to focus on: 1. Get any legitimate SWE role 2. Learn as much as possible in year one 3. After 12-18 months, switch for a 15-20% raise The exception: Don't accept insultingly low offers. If market is $90K and someone offers $50K, walk away. But $75K vs $85K? Take whichever starts sooner. Are you holding out for the perfect first offer, or are you getting started?

53

2 Comments

Here’s my take on AI in SWE. (Finally posting here after some encouragement from friends and colleagues. Time to think out loud. Starting with AI.) In past, we split product engineering into roles like backend, frontend and mroe. With recent advances in AI, that distinction is starting to blur. What I see emerging instead is the need for an AI-native full-stack software engineer. We keep hearing “just 6 more months and AI will replace SWE work.” not sure of exact timeline, but the direction is obvious. A lot of software implementation is already getting automated. The job shift is real. The work becomes: define the vision, understand the problem, set the roadmap, weigh the trade-offs, let AI handle most of the implementation, ship, get feedback from users and product, and repeat. That doesn’t mean fundamentals stop mattering. You still need to understand how things work, how they’re implemented, what alternatives exist, how UIs should look, and how different UX approaches behave. If anything, when AI takes over most of the typing, you finally have time to test different approaches, explore multiple UI options, and compare implementations. On my team, after encouraging juniors to trust AI and delegate more coding to it, a large percentage of the raw code I review is now AI-generated. They spend more time on objectives, UX decisions, reviews, tests, and edge cases. During reviews, they’re ready to explain what they tried, the pros and cons, and why they chose a specific approach. That surface area keeps expanding, especially as agents improve. SWE roles aren’t disappearing. The way we work is. It’s less about a stack and more about how fast you can go from idea to feedback now. So, which skill are you working/building for this shift rn?

21

What I learned about hidden complexity as a Software Engineer at Amazon Engineers, including me, love to build. We get excited about features we could add, new stacks we could try, and all the customers we will serve. That creative energy is a big part of why we love what we do. But here’s the trap: every new creation comes with a hidden price tag. - That extra service we spun up? It needs monitoring, on-call rotations, and upgrades. - That shiny library we added? It’ll break with the next version and someone has to fix it. - That feature you shipped quickly? It now has to be supported, documented, and debugged long after launch. At Amazon, we still support the first-generation Kindle from 2007. Let that sink in! An almost 20-year-old device still has systems and people behind it to keep things running. For each new product or service we build, we have to (or aim to) live with for the long term. In the moment, complexity feels like progress, but in the long run, it shows up as maintenance debt: More work for future teams, slower velocity, and higher risk. Good design isn’t about how much you can add. It’s about how much you can simplify while still meeting the constraints, and how prepared you are to live with it years down the road. 👉 What’s one “hidden complexity” you’ve seen come back to bite a project? --- Hello, I’m Charles, and I am committed to share my two cents on career-related topics for 100 consecutive days. In these uncertain times, I hope to support those facing layoffs or career challenges. Follow me, and let's navigate this together! (52/100) #SoftwareEngineering #SystemDesign #Leadership #CareerGrowth

16

1 Comment