Tip the scale in your favor in interviews

This edition of the newsletter contains two quick write-ups about

1. How to tip the scale in your favor during interviews
2. What is BufferCache in PostgreSQL
3. How DragonflyDB implements transactions internally

I have also shared 3 super-interesting articles I read this week along with a paper that I am reading 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 August cohort are open and only 39 seats are left. So, if you are SDE-2, SDE-3, and above and looking to build a rock-solid intuition to design any and every system, you will find my course super interesting.

Instead of drawing boxes, we go into 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. So, if you are looking for some real engineering discussions, or brainstorming, do check out my course.

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

Tip the scale in your favour during interviews

The final hire call is mostly based on the gut feeling of the hiring committee, and it may seem unfair. But here are a few things that can help tip the scale in your favor.

Ideally, the decision should been based on objective, quantifiable criteria, but that's rarely the case. Each member of the hiring committee uses their intuition to rate you against some rubrics. This rating, although a number, is still subjective and the final decision often comes down to a gut feeling.

Given this subjectivity, here are a few things that will help to tip the scale in your favor.

It always pays to be humble and pleasant during interviews. Make sure you articulate your thoughts well, speak clearly, and put forth your views and understanding in a structured manner. Leaving a good impression will earn you some extra pointers and turn an 8 into a 9.

I do remember interviewing a candidate who was a decently strong engineer (definitely not the strongest) but he was curious, had a great attitude toward work and learning, and was communicating his thoughts very well. The committee felt that this person would be a valuable team player and decided to extend an offer.

By the way, this does not mean you should only focus on your soft skills and ignore the rest. Your tech competencies matter, but in case of a tie or even when you lag a bit, a company will always prefer someone who has showcased the right mindset and a genuine enthusiasm for the role and the company.

You can find this post on my LinkedIn and Twitter; do leave a like.

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.

📹 Video I posted this week

This week I posted How DragonflyDB implements "distributed" transactions in a shared-nothing setup

Transactions are super critical for any database, and once you understand how it works, you can optimize a ton of your workloads. DragonflyDB is a drop-in replacement of Redis and while Txns were easy to implement in Redis, they were not that straightforward for DargonflyDB.

I spent some time to under it end to end and compiled my learnings in a quick 10-minute video. If you love distributed systems, you can draw parallels and understand how any distributed database would have implemented it

This was the second video in the DragonflyDB Internals Series, the next two videos will change the way you look at Data Structures, so stay tuned.

1. DragonflyDB Architecture

What is BufferCache in PostgreSQL?

I spent some time this afternoon going through Buffer Cache in PostgreSQL, and here's the gist of what it is and some interesting details about it

In PostgreSQL, Buffer Cache helps reduce the query response times and reduce time spent in synchronous I/O by caching the recently accessed disk pages in memory. The cache is checked upon every single page access or update.

The background writer process (discussed in the last post) periodically writes modified buffers back to the disk. This ensures the complete durability of the changes and we do not bloat up the Buffer Cache.

Interestingly, PostgreSQL uses a clock-sweep algorithm for buffer eviction. Whenever a buffer is accessed, the usage count in the buffer header is incremented. The clock-sweep algorithm circularly goes through all buffers and decreases their usage counts by one. The buffer that is selected for eviction:

• has a zero usage count
• has a zero pin count (i. e. is not pinned)

Also, a page is considered for eviction only if its usage count is less than the threshold (5). Otherwise, the sweep algorithm moves on.

If you want to explore Buffer Cache deeper. then just install a popular PG extension called pg_buffercache. It helps you examine what's happening in the shared buffer cache in real-time. Pretty amazing. You will get some amazing insights.

You can find this post on my LinkedIn and Twitter; do leave a like.

📰 Interesting articles I read this week

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

• Debugging an evil Go runtime bug
• Instrumenting Python GIL with eBPF
• Dysfunctional options pattern in Go

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.