by Alex Xu23 Apr 2021 ★★★★★
Why I read it: I participate in system design interviews as an interviewer from time to time. And unfortunately this is one of my weaker skills. I thought maybe reading a book about system design interviews would help me to understand the nuances of the exercise better and become a better interviewer.
Since the book consist of multiple different design exercises I read it one chapter per week. Read the intro part first, spent some time figuring out my take on the design and then read the solution and reflected a bit why I have taken different paths and things I forgot to consider.
Why I read it: This is a really good reference book. Each design explanation is easy to read, well illustrated, have links for relevant resources. It covers most of the typical design exercises + short introductions to scaling and back of the envelope estimation. There is a list of additional resources and engineering blogs at the end.
I have expected this exercise I planned for myself to be really gruelling. But the easy and approachable style of the book made it quite easy and quick (I’ve spent around an hour on each).
It gave me a little ego boost as I realised I am already familiar with part of the technologies and solutions mentioned in the book.
What I disliked: I think I got out of it a lot less than I’ve expected. I only read what was in the book, did not follow up on the references. I would have liked it more if the chapters were more detailed and forced me to think more when reading (instead of hoping I won’t be lazy and do the extra work of looking up references).
The book was not very well suited for the kind of exercise I designed for myself. When reading the intro it wasn’t always clear when I should stop to not see any spoilers (though usually it was ok to stop after the example exchange of the candidate and interviewer). The solutions didnt follow a consistent pattern (e.g. high level design, api, database schema etc.) so sometimes after doing a practice design I’d see I went in a completely different direction. (Though I do understand why the book was written this way, as different designs were there to illustrate different problems and it did not make sense to follow the same pattern.)
My main take away from the exercise: ‘Never ASSUME… it makes an ASS out of U and ME’. Or in other words: I noticed I tend to skip things I see as ‘obvious’ and jump to the places I consider interesting or problematic but a lot better common ground (and system design) can be reached when starting simple and voicing out all the assumptions made.