Cracking The Coding Interview Github For Mac

Cracking The Coding Interview Solutions with Automated Unit Tests

Cracking-the-coding-interview java algorithms data-structures interview-questions careercup. Solutions for Cracking the Coding Interview 6th Edition by Gayle Laakmann McDowell. Pull requests pertaining to Java solutions should be submitted to the main CtCI-6th-Edition repo.

✅ C++ Solutions
✅ Python Solutions
✅ Automated Unit Tests
✅ Active Development
✅ Multiplatform Support: Mac, Linux, and Windows

Introduction

This repo contains C++ and Python solutions for Gayle Laakmann McDowell's Cracking the Coding Interview 6th Edition.Admittedly, there are other GitHub repositories with solutions for this book. Buthow do you know that their code is actually correct? If it's untested, then you don't!

In this project, every C++ solution has unit tests using the C++ Catch framework,and every Python solution has unit tests using the Python unittest framework.We enforce test correctness automatically using continuous integration serversensuring that the solutions are made of living code that gets executed and tested on every single commit. To my knowledge, this isthe Internet's only solutions repository with this level of testing rigor: >90% automated test coverage means you canreference and contribute solutions with confidence.

C++ Solutions:

Chapter 1 - Arrays and Strings: 9 / 9 complete.
Chapter 2 - Linked Lists: 8 / 8 complete.
Chapter 3 - Stacks and Queues: 4 / 6 complete.
Chapter 4 - Trees and Graphs: 11 / 12 complete.
Chapter 5 - Bit Manipulation: 7 / 8 complete.
Chapter 6 - Math and Logic: 0 / 10 complete.
Chapter 7 - Object Oriented Design: 0 / 12 complete.
Chapter 8 - Recursion and Dynamic Programming: 8 / 14 complete.
Chapter 9 - System Design and Scalability: 0 / 8 complete.
Chapter 10 - Sorting and Searching: 10 / 11 complete.
Chapter 11 - Testing: 0 / 6 complete.
Chapter 12 - C and C++: 10 / 11
Chapter 13 - Java: N/A
Chapter 14 - Databases: 0 / 7 complete.
Chapter 15 - Threads and Locks: 0 / 4 complete.
Chapter 16 - Moderate: 11 / 26 complete.
Chapter 17 - Hard: 1 / 26 complete.
Miscellaneous Exercises: 2 complete.

C++ Total: 81 solutions complete.

Python Solutions:

Chapter 1 - Arrays and Strings: 9 / 9 complete.
Chapter 2 - Linked Lists: 8 / 8 complete.
Chapter 3 - Stacks and Queues: 6 / 6 complete.
Chapter 4 - Trees and Graphs: 11 / 12 complete.
Chapter 5 - Bit Manipulation: 7 / 8 complete.
Chapter 6 - Math and Logic: 0 / 10 complete.
Chapter 7 - Object Oriented Design: 0 / 12 complete.
Chapter 8 - Recursion and Dynamic Programming: 11 / 14 complete.
Chapter 9 - System Design and Scalability: 0 / 8 complete.
Chapter 10 - Sorting and Searching: 1 / 11 complete.
Chapter 11 - Testing: 0 / 6 complete.
Chapter 12 - C and C++: N/A
Chapter 13 - Java: N/A
Chapter 14 - Databases: 0 / 7 complete.
Chapter 15 - Threads and Locks: N/A
Chapter 16 - Moderate: 2 / 26 complete.
Chapter 17 - Hard: 3 / 26 complete.

Python Total: 58 solutions complete.

Grand Total: `139` unique solutions complete.

Building:

Mac:

Mac usage requires installing the package managers Homebrew and Pip which is done for you in the Makefile:

Ubuntu:

Windows:

For Windows users, I recommend developing this project using the Windows Subsystemfor Linux (WSL) featureof Windows 10 and then following the Ubuntu build and testing instructions inside WSL.This recommendation is due to the use of Ubuntu, CMake, and makefile based build and executionsystems on the servers that automatically test changes to the code. For more on Windowsdevelopment, see the Appendix section at the end of this page.

Testing:

Testing is the most important part of this project: onlythe unit tests define the problem being solved. In the rootdirectory, execute the following to run all tests in Python and C++:

make test is the command I use most while developing this project. My workflow follows:

I read a problem and encode the problem definition by implementing its unit tests.
I execute make test to see where the project fails to satisfy the unit tests.
I add to the implementation of the problem solution until make test succeeds.

Optional: Generating a Test Coverage % Report Locally (Python support only):

This will show exactly which lines are not covered by tests in each Python source file:

Contributing

The goal of this project is to write a tested Python and C++ solution for every problem in the 6th edition of the textbook.I definitely need help, so PRs are welcome. There is much to do because each solution needs its ownsmall dataset and infrastructure in order to be tested. Here are some ways you can help:

Fixing bugs 🐛.
Solving or improving solutions to problems in either language (see the completion progress in the table of contents).
Adding more unit tests to increase the test coverage %.
Implementing automated C++ test coverage measurement using gcov.
Integrating automated test coverage % reporting for both Python and C++ via Coveralls.
Adding prose solution descriptions for problems that don't have them.

If you have any contributions, please make a PR to the master branch. Feel free to message me for clarification on any ofthe above items.

Appendix: Windows Development

On my own Windows machine, I develop using CLion runningnatively in Windows and test the code using make test in a WSL terminal window.For users who do not want to use WSL, I have developed the build and test methodology below:

Building

The project can be developed purely on Windows without WSL by using Visual Studio 2017.First clone the code:

Then, install Python3 and numpy using your method of choice. I prefer installing Python3 and pip3 fromthe official website then installing numpy via pip:

Then, open the project in Visual Studio 2017 which has CMake support.I've found that best the workflow is to use Visual Studio to edit code and use debugging functionality. Beforebuilding the code, you must follow these instructionsto tell Visual Studio to download PDBs it needs. Additionally, this articledescribes Visual Studio CMake support in more detail if you're interested. A CMakeSettings.json file in the root projectdirectory sets the location of the Visual Studio build folder to be inside the root folder of the project.

Testing

Running the tests and seeing their output is best done from a PowerShell window since VisualStudio in CMake modedoes not allow the console output of the tests.exe and tests.py files to remain visible even when pressingCTRL + F5 as described in this post which applies to'normal' Visual Studio use. I am monitoring the situation re: Visual Studio, and when I find better solutionsI will implement them or post them. If you know of something better, please contact me.

In the meantime, from the project root directory, you can run the Python tests using ..

.. and you can run the C++ tests using ..

This is for those of you out there who are about to start your job search and who may be worried that you can’t land a top-tier tech job without a Stanford CS degree. Someone told you that you’re not good enough to get a job at Microsoft or Facebook.

But I’m here to tell you that you can get that job. Here’s how I landed my dream job at Twitter.

Read more about my courses here to learn how I prepared.

You can read about my experiences after a year at Twitter here.

What this article covers:

My background
How I landed interviews with top tech companies in the world: Facebook Google, Amazon, LinkedIn, Microsoft, Twitter, Pinterest, Snapchat, and others.
How I landed multiple offers as a full-time software engineer
Lessons from my interview experience
Subscribe here for more article updates from me

If you prefer to watch my story instead, I made a video here:

Background

I did not graduate from an Ivy league school. I went to a community college in Idaho for two years, and then finished my CS degree at a small Catholic university.

I started learning computer science in my junior year of college, because it sounded fun to me at the time. The only thing resembling a computer I had growing up was a Chinese copycat of the Nintendo SNES. Even then, it would break every time I put a cartridge in it.

To support myself through college, I took multiple part-time jobs like cleaning floors and working stand-up concessions.

Best fonts for brochure design statistical fonts for mac. When I graduated, I didn’t have a job lined up. I applied to as many big tech companies as I could, and had the good fortune of landing a few phone interviews.

At this point, I didn’t have a single notion of what a technical screen would be like, much less how to prepare for it. I headed into these interviews thinking that the interviewer would ask me what a linked list or binary tree was.

I didn’t pass any of those interviews.

Moving forward

I didn’t delve too much into whether I was good. I knew that I could learn things fast. I just needed an opportunity.

As the saying goes, cast your net far and wide. So that’s what I did.

What I did next is something I’m particularly proud of. I wrote a simple Python script that scraped job listings on Craigslist with titles containing keywords from a list, and collected the emails in a spreadsheet. For the actual war story, you can read the article here.

It wasn’t the smartest solution, but people who post on Craigslist are surprisingly accurate with their titles.

Craigslist, however, didn’t like people scraping their website. To work around this, I ran my script through a VPN, and had a timer that would pause the script every few minutes or so. It wasn’t perfect, but it worked well enough.

In the end I collected about 500 emails from around San Francisco, Portland, Spokane, and Seattle. I filtered the results by how specific and recent they were, and kept improving it by adding more and more features.

As it turned out, there were a few bots in the market already that crawled Craigslist and sent out automated emails. These were mostly offshore companies that were looking to pitch their company to the US market.

One of my workarounds was that I crafted emails that used keywords from their listings in the title of my emails. I then added more details using the body of the postings to make it seem more personable. I did a quick A/B test, and the replies I received had increased quite a bit from around 2–3% to 10%.

Out of the 500 or so emails, I received about 50 replies, and landed phone screens with a small percentage of those. I stopped at 500 because I was short on time and needed to finalize a job as soon as possible. I was optimizing for results rather than reach at that point.

As luck would have it, I finally landed a job at a startup in Seattle as a junior software engineer. The startup was located in Kirkland at the time, so I had to take a 45-min bus ride to make it in time for the interview.

I then stayed there for the next 3.5 years, where I learned a great deal of stuff like Amazon AWS, EC2, DynamoDB, SQS, and Docker. I grew a lot during this period. I learned how to write modular, maintainable code. I learned how to reason about software design. And I learned how to handle people problems.

I was working next to a group of smart people who held jobs at Microsoft, Amazon, and LinkedIn, and I tried to be the “sponge” in the group. I absorbed anything and everything they threw at me. I believe this made a huge impact in my career.

Startup Days

During my stint at the startup, I worked almost exclusively on backend development, with some dev-ops in between. I started out writing some functions to add/modify a feature that were mostly small in scope. But it was a great opportunity to understand the codebase and get some code reviews.

A year into it, I started owning parts of the codebase, and then I was tasked with turning a set of features into a service. That was the start of the SOA phase for the startup. We started turning various components of the site into services, and that’s how I started learning more about RESTful services, authentication, AWS services, pub-sub, distributed systems and so forth.

The interesting part here is that I didn’t learn about any of these through books or formal education. Rather, I needed to get that set of features done and there were the bottlenecks.

So I thought, let’s go solve it!

There were many times where I was stuck in analysis paralysis — a state where I over-analyzed scenarios and ended up not able to make progress.

Those trying times were the greatest learning opportunities. I started to learn feature scoping, negotiations, monitoring, alerting, and documentation. Each step of the process revealed more things I needed to learn. I grew the most during these 2–3 years, both as an individual and software engineer.

How I prepared for my interviews

After suffering through my first job search, I told myself that I must be prepared in future interviews.

I started preparing for interviews by charting out an overview of what I was good at, bad at, and where I could improve. I broke it down into three categories: data structures, algorithms, and system design.

Having worked in PHP for most of my professional career, and C++ in college, I wanted to try something a little simpler and less verbose for interviewing.

For this reason, I picked Python. It is a great language to learn, easy to pick up, supports many data structures out of the box, and can be written quickly on the whiteboard. I learned Python by going through YouTube tutorials like these, and also reading their documentation. I prefer Python 2.x, but you can go for either 2.x or 3.

Also, another reason why I picked Python is that it’s highly readable and easy to write on a whiteboard. Here’s a trivial comparison between C++ and Python.

A C++ program to sort in descending order: Micro niche finder for mac free.

Compare that with Python’s version:

I’ve received feedback from interviewers to err on the side of brevity in an interview. In a 45-minute interview, you want to use most of your time solving the actual problem.

Pro tip: pick a language that’s less verbose so that you can write the code more quickly on the whiteboard.

Preparation mode

I spent about a week going through simple challenges on LeetCode, HackerRank, and Project Euler to familiarize myself with their interfaces, and to get used to writing code in Python.

The first week gave me insights into my competence level at certain programming languages. I spent another week going through some design challenges like “design X” and went as wide and deep as I could.

This was a lot of fun for me, because I often looked at iOS apps and tried to figure out how they did it. For example, how would you build Instagram from scratch? (I was asked this at Facebook.)

My background is in API designs and service-oriented architecture, so I took this opportunity to show how I would design my own version of Instagram. And because I have some iOS programming experience from my side-projects, I could talk a little bit about callbacks and push/long-polls here.

I started the conversation with some features I’d like to have on my own version of Instagram: likes, upload a photo, and a simple timeline. Feature scoping enabled me to build a very solid API because I know these scenarios well.

I then drew some pictures of a high-level design, of how the client would interact with the backend, and of how the backend would store the data.

I started small, and then added more components where needed and proactively sought where the bottlenecks were. I made educated guesses (read educated, not blind guesses) on what the requirements would be, and how each technology would fit in well. And also equally important, what technologies would not fit well.

For example, why would you use Cassandra over MySQL to store certain information (hint: scale, speed of development, schema reviews), why use OAuth over simple authentication, Redis vs Memcached for caching data, streaming vs batch processing, and so on.

There are many areas you can explore here, so typically a one-hour session is not enough. To do well on these questions, you have to read and learn about trade-offs. Pros and cons of technologies in the industry. For this, I recommend a site like HighScalability.

Take it like a typical brainstorming session with a coworker, so explore as widely and as deeply as you can.

It’s crucial to know that these design interviews are meant to explore how much you know and how well you know it, and it’s an opportunity for you to shine. I watched this YouTube video from an ex-Facebook engineer about how to solve design problems, and it gave me insights that helped me tremendously with my design interviews. My two main lessons from it: drive the design conversation, and show what you know.

I listed out my competency level for: data structures (linked list, hash map, binary tree, binary search tree, heap, array), algorithms (binary search, hashing, dynamic programming, sorting), and language-specific syntax and libraries (like sort, lambda for Python, appending, indexing).

I picked the area I was worst at, and started working on it: algorithms.

Algorithms have never been my forte. It’s been a while since my college days, and I didn’t spend much time doing binary search in my day-to-day career. I had an inkling of how each algorithm would perform, and in what scenarios to use them. But I wasn’t 100% comfortable with writing a binary search in under 10 mins. On a whiteboard. In front of an interviewer.

I also picked up a bunch of fine-point markers from Amazon, which work amazingly well. Perhaps it’s just me, but the fine-point markers in interviewing rooms usually don’t work at all. I’d usually scramble for 2–3 mins looking for a working pen, and that’s 2–3 mins you can’t afford to waste. Plus, fine-point markers allow you to write 5–8 more lines of code on a typical whiteboard vs. thicker ones. :)

Pro tip: Get your own set of fine-point markers.

I got a whiteboard from Costco for $50, some books from Amazon (listed in the tools I recommend section below), and started practicing. I made sure I ramped up on binary search, recursion, dynamic programming, BFS and DFS. A lot of interviewing questions revolved around recursion and binary search or some variations of it.

The best interviewing questions I’ve seen had many different solutions to them, and there’s an additional layer added on top as you progress through.

One Google question I had was related to file-system directories, and how to traverse them (hint: recursion). I solved that relatively quickly, and the interviewer asked how to identify a missing file in that directory. That was a little more difficult, but I got through it. And we then moved into how to rebuild the directory, how to serialize/deserialize it, and we spent a good chunk of time debating how file directories work underneath the hood. It was a very enjoyable session for me.

Interviewing at top-tier companies

It was a nerve-wracking experience, to say the least, and a real roller-coaster.

I allocated my time in the following manner: 20% resume, 20% research and 60% interview preparation.

I spent 20% of my time fixing up my resume, which hadn’t been updated in at least three years. I took a hard look at the stuff I’ve done in the past, and picked projects I handled end-to-end, regardless of complexity.

The reason for doing this is two-fold. Taking a project from start to completion demands discipline and leadership — two of the traits I’d like to be identified with.

Secondly, ownership of a project end-to-end means I can talk about each aspect of the project at length and in depth. This proved critical in helping me navigate my design round at Twitter, where they grilled me hard on not only the designs of my projects, but also the decisions behind them.

20% of my time was used for research. Research in this case meant doing due diligence on companies I was interested in and reaching out for referrals. Having referrals helps with return calls.

From my experience, I sent out 20 or so cold messages to startups and mid-stage companies, and only heard back from a handful. But, almost all the companies I was referred to by an existing employee sent me a message within a week. This is anecdotal, but there’s value to be had there.

I am not that sociable, and I didn’t know many people who’d be able to refer me to a company I was interested in. To solve that problem, I went on LinkedIn. They have a search functionality that I used to search for 1st and 2nd-level connections. 2nd-level connections are people who’re one hop away from your immediate circle. In other words, we have mutual friends who can vouch for my credibility.

This is incredibly important, because cold-calling someone for a job is very, very hard, especially in today’s market. People tend to err on the side of caution when it comes to cold-callers. Using LinkedIn was super helpful for my research phase.

Looking back at all the companies I interviewed at, here are my thoughts on each of them:

Facebook/Google — very mechanical. The standard interviewing process, and I didn’t feel any personal connection to them.
Pinterest — not the best interviewing experience, but a cool product and company.
Microsoft — loved the team and especially the manager and her manager. Standard interviewing questions, but very personable. Close-second choice. Your mileage may vary, though — each team at Microsoft interviews differently.
Amazon — standard interviewing process. About 50% of the people love it, the others don’t.
Twitter — incredibly fun and personal. Loved the interviewing process, gave a lot of emphasis on the individual and what I’d done in the past.
Snapchat — cool office in LA, great bunch of people who decided to jump on the startup bandwagon. Felt like things were shrouded under a cloud of secrecy.
Lyft — near to where I live, nice office, standard interviewing process. No strong feelings about it.

Let’s talk about my favorite

In many ways, I’d say Twitter’s interviewing style was hard. But at the same time, it was more interesting and personable than other companies I’ve interviewed at.

Their interviewing process starts with an introductory phone call with an engineering manager. That’s followed up by one or two technical phone screens, depending on how you perform. If you do well, they’ll fly you out to the office you’re interviewing for, which was Seattle in my case. There are three 1-hour-and-15-minute rounds, each with two interviewers.

The first two technical phone screens are the standard, run-of-the-mill technical screens where you solve coding problems on a shared coding doc.

The onsite rounds, however, are much more conversational and feel much less intimidating. The interviewers will ask you in-depth questions about your past projects, and they’ll grill you on what you’ve done in the past. If you claim ownership of a project, you should expect some questions about it. You’re encouraged to use them for references and to bounce ideas off of.

I never felt any pressure to magically come up with a fully working solution, and it felt highly collaborative.

The others

In comparison, interviewing at Facebook and Google felt much more mechanical. They have one or two technical phone screens, and five to six onsite coding rounds. Each round involves some coding on a whiteboard, and you’re expected to come up with a near-perfect solution in a reasonable amount of time.

Facebook has two coding rounds, one design round, and one behavioral round.

I went through an additional shadow round at the end of the day, which didn’t count towards my overall score.

Google had five coding rounds, none of which focused on designs, and not a single interviewer asked about my previous projects. I don’t necessarily think this is bad. But I think it felt very mechanical and didn’t give much opportunity for the engineer to show what they’re capable of. Some people do well in these scenarios, much like some students do well in exams.

I did not enjoy my interview with Pinterest. I think the product itself is interesting, and their engineering team seems to be working on very cool technical problems. But I definitely had a negative experience during my interview there.

Pinterest has three coding rounds and one design round. Of those four rounds, the design round was most disappointing to me. Here’s why:

The interviewer came in late, and he spent a few minutes glancing over my resume before proceeding to draw some APIs on the board. He gave a short description of what he expected the API to do, and asked how I would solve it. We clarified the features of the API, and I started describing my solution using the whiteboard. About 5 minutes into it, I turned around and saw him taking a nap!

Not cool.

I gave the recruiter my feedback in a survey, and I didn’t hear back from them after that.

I won’t delve into specifics of the questions I was asked during all the interviews. Instead, I’ll share some of the insights and useful tips I learned from my preparation process.

What I learned:

Be honest on your resume. Most companies will ask you questions about your resume, and they can tell if you made it up. It’s better to be able to know 100% about one project than to know 10% about 10 different projects.
One-page resumes are recommended. This is especially true for tech companies, and it seems that the wisdom within the tech sphere is that you should reserve two pages and longer for post-doctoral work, or if you’ve done a lot of projects that you know and care deeply about. A friend of mine runs a company called Jobscan that scans resumes and makes specific, actionable improvements on them. They’re pretty awesome, so try them out :)
Socialize and establish a network. There’s a lot of competition for software engineering jobs, and these top tech companies are filtering through thousands of resumes a day. Having a referral will help you get some eyes on your resume.
Nail your pitch. Every company that’s interested in you wants to know why you’re interested in them. A bad answer: I just need a job right now to pay bills. A less-bad answer: I was browsing online and found you guys. Sounds like you’re working on interesting things. A good answer: I know you’re doing some interesting work in X to achieve Y. I’ve done some work in the past and here’s what I learned about A, B, C that might be related to X. I am passionate about Y because blah. (Don’t use this as a template. Instead, you should see the pattern here — do your research, use your background, and show the company why both of you would fit well together.)

Some more advice

Technical interviews are incredibly difficult, and sometimes it’s a hit-or-miss. The best opportunities, however, are reserved for those who are prepared.

Prepare early, prepare well. Everyone knows that they should prepare for an interview, but most don’t know how to do it well. As with anything worth doing, it takes deliberate practice to do well at something. And deliberate practice means you need to have a system.
Build a system to practice technical skills. I started by rating myself from 1–10 on how good I was, and worked on the ones I was worst at. I spent days on different types of questions until I fully mastered each concept. And I wrote notes daily on Evernote. I had a note that serves as a brain dump for all things programming. It is full of programming tips & tricks, common errors and misconceptions, frameworks for solving specific types of questions, and much more.

Keep a notebook of the things you’ve learned. I use both Evernote and OneNote to keep track of things. OneNote for technical stuff/code, because I like that I can easily format the note any way I like. I use Evernote for essays/thoughts. The image above shows a note I keep on architecture and system designs.

Jot everything down, even if you don’t think you’ll use it. I tend to forget very easily, so anything that I learn I write it down, including shell commands. I read technical blogs from time-to-time, and if I find anything interesting I jot it down on Evernote right away. I’ll revise it every week or month and reorganize accordingly. This has helped me tremendously over my career.
Get mock interviews. This was definitely very valuable and I highly advise it. I had mock interviews with friends and tried to practice as much as I could. If you can’t find friends to practice with, then I recommend Refdash, which is an Interview-As-A-Service. They have a group of interviewers who work at big tech companies like Google, Facebook, and Microsoft. These interviewers will assess you on your coding and design skills. The best part of it is they’ll give you a score at the end of it with specific actionable items on how to improve.
It’s OK to fail. I failed multiple interviews during this whole process. Sometimes you just have a bad day. It’s not the end of the world if you fail. Companies are biased towards saying no because it’s a lower risk for them. A false positive costs more than a false negative in the long run. The first few rejections definitely stung the most. I failed multiple phone screens when I first started interviewing, and my confidence level sunk. I had doubts in my mind about my abilities and started fearing that my skills weren’t relevant in today’s job market. However, I gave myself a tip: If you fail 10 times, then try 10 times more. All you need is one success. That reassurance gave me a lot of confidence to keep pushing through and when my first offer came through, the other offers came much more easily.

It took me about 2 months of deliberate practice and preparation for my interviews. I spent about 20 hours/week, or 80 hours/month, learning and writing notes on top of a full time job.

To build up my resume, it took 3.5 years of focused, deliberate work. I intentionally picked things that were tough and icky so that I could learn more than anyone else. Even though I don’t have a brand name university or top-tier tech company on my resume, I made up for it with a clear, thorough understanding of the projects I worked on. And this was possible because I researched and wrote down notes of everything I learned, and have a system to review them.

Remember: the strong survives, the tough thrives.

TL;DR: Don’t give up, set yourself up for opportunities, practice a lot, and stay hopeful. Focus on the process, and take a disciplined, dedicated approach to the process.

Tools I Recommend

Designing Data-Intensive Applications: Awesome book for learning about scaling distributed systems! Highly recommended.
Elements of Programming Interviews: Great for solving coding problems.
Cracking The Coding Interview: Great for covering foundational CS coding problems.
Daily Coding Problem.com: This is a free-to-try website that offers free daily coding problems. You can sign up for interesting daily coding challenges, and you can pay for solutions if you want.
Dropbox: I keep all my files, pictures, resume here. Easy access, installed once and available everywhere. Love it ❤️ (If you sign up thru this link, both of us will get free 500MB!
CodeRunner: I love this Mac app! I used this multiple times to run ad-hoc Python scripts/functions and it just works amazingly well. 🔥
Kafka the Guide: I used this book as a reference guide, and enjoyed it for the high-level description.

(I share more resources I personally have used and recommend on zhiachong.com, if you’re interested in learning more.)

Thanks for reading my story! You can find me on Twitter and LinkedIn. I would love to connect and talk more about tech, startups, travel :D

Credits:

Brandon O’brien, my mentor and good friend, for proof-reading and providing valuable feedback on how to improve this article.

YK Sugishita, an up-and-coming Youtube star who left his job at Google to pursue his dreams, for proof-reading and giving critical feedback.