Saying 'This isn't my problem' is actually the problem

This edition of the newsletter contains

• a write-up to help you grow in your career

• a video I posted

• a paper I read

I have also shared 3 super-interesting articles to read over the weekend. Thank you once again for reading this edition of my Newsletter. Now, without further ado, let’s jump right in.

---

By the way, the admissions for my System Design June cohort are open, and ~8 seats are left. If you are an SDE-2, SDE-3, or above, and looking to build a rock-solid intuition for designing any and every system, you will find my course extremely interesting.

Instead of drawing boxes, we go into the intricate details of every single system and build an end-to-end understanding. The learnings from the course can be applied at your workplace from day 1. If you're looking for genuine engineering discussions or brainstorming, be sure to check out my course.

Course curriculum and other key details: https://arpitbhayani.me/course

---

Saying 'This isn't my problem' is actually the problem

If you want to accelerate your career and make sure you are having a lasting impact at work,

1. do not build a habit of being spoon-fed

2. do not keep asking for help instead of checking the code or the docs

3. do not spend time on easy and low-impact work; fight for high-impact projects.

You must show a high bias for action at work, take ownership, and make an impact. Here are some actions that you can apply right away at work to earn some brownie points

1. waiting for a code review? ping them

2. seeing high error rates? join the thread and help if required

3. outdated docs? update them instead of complaining

4. teammate stuck? help before they ask

5. slow processes? propose a solution and drive adoption

6. no owner for a project? step up and lead

7. recurring issue? proactively automate/document the fix

I think everyone should operate with a high bias for action. It is not just about identifying problems, but also about actively working on solutions.

Instead of waiting for someone to act, you act and lead.

---

By the way,

Being hands-on is the best way for you to learn. Practice interesting programming challenges like building your own BitTorrent client, Redis, DNS server, and even SQLite from scratch on CodeCrafters.

Sign up, and become a better engineer.

---

Here's a video from me

I published a video - How to Protect Your Systems with Throttling & Rate Limiting - 5 Real-World Use Cases

It is a common belief that a rate limiter is always external and is designed to prevent our systems from being abused by the external world, but this is not true.

In this video, I explain rate limiting, throttling, why we need it in the first place, and 5 real-world use cases where external and internal rate limiters are super useful.

---

Here's a paper I recently read

I spent some time reading Detecting Near Duplicates for Web Crawling

One interesting problem that Google had to solve in the early days, and even now, as they crawl billions of pages, is detecting near-duplicates.

First of all, this problem is critical because it has an impact on crawling, indexing, and ranking at scale. Near-duplicate pages look different on the surface but have almost the same content, except for ads, timestamps, or minor wording changes.

Google started with the classic simhash algorithm, which converts high-dimensional document features into compact 64-bit fingerprints such that similar documents get similar fingerprints.

Then, leveraging the Hamming Distance, they quickly find all fingerprints that differ from a given one in at most k bits (typically k=3). To do this efficiently, all you need is a simple multi-table lookup sprinkled with some compression to make the lookups happen in milliseconds.

Some time back, I read this interesting and practical paper by Google on this very problem. The paper covers the approaches mentioned above and, of course, some tuning, nuances, and details around this system.

You can download this and other papers I recommend from my papershelf.

---

Three interesting articles I read

I read a few engineering blogs almost every day, and here are the three articles I read and would recommend you read.

• Machine Code Isn't Scary

• GitLab reduced repo backup times from 48 hrs to 41 mins

• I made a worse search engine than Elasticsearch

---

Thank you so much for reading this edition of the newsletter 🔮 If you found it interesting, you will also love my courses

1. System Design Course for Beginners

2. System Design Course for SDE-2, SDE-3, and above

3. Redis Internals Course

---

I keep sharing no-fluff stuff across my socials, so if you resonate, do give me a follow on Twitter, LinkedIn, YouTube, and GitHub.