In my day job, I have to consult customers on AWS services and design architectures on AWS. That means I have to have a basic understanding of almost every AWS service and be ready to dive deep into any of them on short notice. For that, I have a method for learning an AWS service in the most efficient way possible.
Read the product page.
Read the product FAQ.
Read the concept section(s) of the documentation.
Ask yourself key questions about this service.
Watch YouTube videos.
Follow a hands-on workshop.
Let’s assume that you need to learn AWS Lambda quickly, here is how you would do it:
(Right-click on the picture and select Open image in new tab to see the diagram in full size.)
After some recent discussion with a friend on note-taking methods, I decided to document my current productivity system for future reference. It is a combination of note-taking, time management, TODO list, project management, and writing combined. It has evolved over the years so I find it interesting to take a snapshot and look back a few years later.
I’ve conducted many system design interviews in the past. Whenever I brought up the topic of database sharding, the candidates almost always shout out “Yes, yes I know! Consistent hashing!”. If you probe them further, they will draw this classic ring diagram on the whiteboard.
…, this particular approach (Consistent hashing, as defined by Karger et al.) actually doesn’t work very well for databases, so it’s rarely used in practice (the documentation of some databases still refers to consistent hashing, but it is often inaccurate).
Then why is every system design interview study guide tell you otherwise? Let’s dive into this topic in this post.