Ryan Peterman

7 famous GitHub repos to help you pass software engineering job interviews:

1. System Design Primer (252k stars): https://lnkd.in/g6yMEsGv
2. Coding Interview University (282k stars): https://lnkd.in/gWnd3n6C
3. Awesome Interview Questions (66.4k stars): https://lnkd.in/gY-AYpQk
4. Front End Interview Handbook (39.9k stars): https://lnkd.in/gpZpC_ZX
5. Javascript Algorithm Implementations (182k stars): https://lnkd.in/g9V7d-Ya
6. Python Algorithm Implementations (178k stars): https://lnkd.in/g7hv9ShZ
7. Tech Interview Handbook (109k stars): https://lnkd.in/gU6kk5eN

Covers algorithms, system design, data structures, and more.

If this post was helpful, react/share/comment for reach so more people can benefit

Any other top resources I'm missing?

8 GitHub repos to help you pass software engineering job interviews:

1. https://lnkd.in/g6yMEsGv
2. https://lnkd.in/gWnd3n6C
3. https://lnkd.in/gnXrP2fp
4. https://lnkd.in/gpZpC_ZX
5. https://lnkd.in/g9V7d-Ya
6. https://lnkd.in/g7hv9ShZ
7. https://lnkd.in/gU6kk5eN
8. https://lnkd.in/gY-AYpQk

Covers algorithms, system design, data structures, and more.

Any other good resources I'm missing?

19 vetted company engineering blog posts that will help you become a better engineer:

Tech Stack Upgrades:
1. Airbnb: React Native at Airbnb https://lnkd.in/dgdbxSw2
2. Pinterest: The Case Against Kotlin https://lnkd.in/dN6G2YgU
3. Stripe: Migrating millions of lines of code to TypeScript https://lnkd.in/dgcYskit
4. Airbnb: Rearchitecting Airbnb’s Frontend https://lnkd.in/d8x-HxBw
5. Meta: Rebuilding our tech stack for the new Facebook.com https://lnkd.in/d5Tb-CsW

Scaling Backend Services:
6. OpenAI: Scaling Kubernetes to 7,500 nodes https://lnkd.in/dQup2TXr
7. Pinterest: Sharding Pinterest: How we scaled our MySQL fleet https://lnkd.in/dnhBz46w
8. Instagram: Sharding & IDs at Instagram https://lnkd.in/dm3VvYqz
9. Figma: The growing pains of database architecture https://lnkd.in/dwAesfXN
10. Dropbox: Finding Kafka’s throughput limit in Dropbox infrastructure https://lnkd.in/dvYEG99y
11. Instagram: Open-sourcing a 10x reduction in Apache Cassandra tail latency https://lnkd.in/dmknxd2Q

Online Migrations:
12. Stripe: Online migrations at scale https://lnkd.in/dHd8YSbe
13. Netflix: Migrating Critical Traffic At Scale with No Downtime https://lnkd.in/d4XCkq8b

Debugging Stories:
14. Netflix: Life of a Netflix Partner Engineer — The case of the extra 40 ms https://lnkd.in/dbD-tCkz
15. Github: Debugging network stalls on Kubernetes https://lnkd.in/dm2avMEq
16. Reddit: You Broke Reddit: The Pi-Day Outage https://lnkd.in/d7dgqFme
17. Netflix: Linux Performance Analysis in 60,000 Milliseconds https://lnkd.in/dQ5tFTvB

Build Systems:
18. Stripe: Fast builds, secure builds. Choose two. https://lnkd.in/dExJhSNx
19. Pinterest: How a one line change decreased our clone times by 99% https://lnkd.in/dDZrNkYe

Any other helpful posts I missed?

Software engineers don’t hate meetings.

They hate:

• Sitting through status updates that could’ve been an async message.

• Focus time interruptions for discussions that could wait.

• Attending meetings with vague agendas.

• Sitting through meetings with tons of attendees who don’t need to be there.

• Scheduling that fragments all their focus time.

Clear, focused meetings that are scheduled well are actually a good thing.

Make the most out of every meeting.

3 reasons why meetings are especially bad for software engineers:

1. Writing code requires deep focus - It takes hours of continued focus to make any meaningful progress

2. Context switching is expensive - It takes a fixed amount of time to start writing code. Each time you switch you pay that cost

3. Fragments your time - Meetings chunk up your calendar into smaller fragments of time that aren't as useful for making progress

Not to mention that many meetings aren't even necessary. How often have you attended a meeting only to realize it wasn't worth the time?

9 company engineering blog posts that will help you improve at system design & learn Kubernetes:

1. OpenAI: Scaling Kubernetes to 2,500 nodes https://lnkd.in/gxPJUkhZ

2. OpenAI: Scaling Kubernetes to 7,500 nodes https://lnkd.in/dQup2TXr

3. Netflix: Kubernetes And Kernel Panics https://lnkd.in/g23pEvf9

4. Airbnb: A “Krispr” Approach to Kubernetes Infrastructure https://lnkd.in/gSxf8gkh

5. Airbnb: Dynamic Kubernetes Cluster Scaling at Airbnb https://lnkd.in/gN37eXmW

6. Stripe: Railyard: how we rapidly train machine learning models with Kubernetes https://lnkd.in/gJ9ZZcGM

7. Spotify: Designing a Better Kubernetes Experience for Developers https://lnkd.in/gjvbDDTP

8. Palantir: Kubernetes at Palantir https://lnkd.in/gUiGHAKZ

9. Pinterest: PinCompute: A Kubernetes Backed General Purpose Compute Platform https://lnkd.in/gxZ5A5J8

Any other good engineering blog posts that you think I should add to this list?

You're a senior engineer when:

- You become the “go-to“ person for a given component/system
- You influence others for higher implementation quality
- You solve problems regardless of who is in charge
- You set the direction for your team and self manage projects

What else did I miss that's a sign of a senior engineer?

A friend of mine got promoted to Staff (IC6) at Google by 28 in an unusual way.

He said he worked <40 hours a week even with that career trajectory.

Main takeaway from chatting with him was that what you work on >> how hard you work.

Two skills you need to develop to make the most of this:

1. You need to understand what results your org cares about most and which work drives the biggest impact

2. You need to have the soft skills to say “no“ to less impactful work without causing thrash

If you're curious to learn more, I wrote my full thoughts from chatting with him about this in this week's newsletter:

Don't ask for permission to make the codebase better, just do it.

Your team often won't prioritize the work since it's hard to quantify the benefits compared to feature work.

Over time, the codebase will build technical debt which will slow down your team.

Set aside some time to clean up the codebase as you go. Always leave the code in a better state than when you found it.

If your team has a culture of doing this, it will pay off in faster dev speed and less breakages.

Of course, if you plan a major refactor that'll impact others then you should discuss it first. But for small improvements, just go for it.

How does your team deal with technical debt?

IC9 Distinguished Eng ($3,000,000 TC) desk setup: