At one of the big tech companies I worked at, we had comprehensive documentation around code review best practices & coding style guides. This documentation has been open sourced and is publicly available (see code review best practices, java style guide etc). The standards incorporate best practices across coding languages/code reviews and are updated fairly frequently to incorporate new features as languages evolve. The big tech companies have a bunch of pretty smart folks coming up with these guidelines. However, like most things in software development, there is a caveat — the standards are ultimately a set of recommendations and can sometimes be subjective. For e.g. should the standard be to use tabs or spaces? (who are we kidding, tabs are clearly superior).

However, in spite of them seeming somewhat draconian at times, the standards go a long way in ensuring that code at these big tech companies is consistent, well structured and well reviewed. Most of all, it provides guidance to junior engineers who are still figuring out how to write clean, readable code.

Going from Google to Lyft, I observed two issues around code reviews on my team:

1. PR iterations often took over a day to get reviewed
2. Code reviews were shallow — they were either nit-picky or simply rubber stamped without the reviewer doing due diligence

This impacted my team’s velocity as well as code quality. To help mitigate these issues, I came up with some code review standards/guidelines for the team. These guidelines were developed by leveraging suggestions from my teammates, my own personal experience as a software engineer as well as various online resources. Feel free to use some or all of these guidelines for your own teams or projects, or to distribute them freely:

On approvals

• Approve a PR if the change is safe to ship as-is.
• Lean towards granting approval if all of your comments are nits/suggestions for improvements. Not giving an approval implies that the author must change their code in order to get the approval.
• If the change is not safe to ship as-is (e.g. if it may cause an outage/SEV), lock the PR to prevent an accidental merge.

On review timeliness

• Establish an SLO on the time between a code review being requested and reviewed. It’s important to get buy-in from your team so that expectations are documented and aligned. At Lyft we established an SLO of 3 working hours. Once tagged for code reviews, it was expected that reviewers would be able to perform the review within 3 hours. For e.g. if the reviewer was tagged at 1 pm, they were expected to review the change by 4 pm. If they were tagged at 5 pm, they were expected to review it by 12 pm the next working day.
• If the reviewer is unable to meet the SLO, they should leave a comment on the PR, setting expectations with the author.
• If the SLO is breached, the author should feel comfortable pinging or retagging the reviewer. Note that the SLO wasn’t enforced via any tool but served as the north star to align on best practices for code reviews.

On authoring a PR

Do:

• Assume competence and best intentions.
• Provide sufficient context for the change by adding a description, links to relevant JIRA tickets or tech specs. Fill out the PR template. It’s the author’s responsibility to help the reviewer understand what the PR is trying to accomplish.
• Review your own code before asking reviewers to take a look.
• Keep your changes small. Smaller PRs are faster to review & have a higher probability of reviewers catching bugs. Aim for a PR which is 250 lines (including tests). A study demonstrated that the brain can only effectively process so much information at a time & beyond 400 LOC, the ability to find defects diminishes.
• When disagreeing with feedback, articulate why you disagree and provide artifacts (coding style guides etc) explaining the advantages of your approach.
• Retag your reviewers if the review SLO is breached.
• Loop in the approving reviewer if you’ve made substantial changes after the approval was granted.

Don’t:

• Rely on your reviewer to catch bugs. You are ultimately responsible for the quality and correctness of your code.
• Include unnecessary changes unrelated to what you are trying to accomplish in the PR. It might be tempting to refactor a class which is unrelated but will likely confuse your reviewers or require them to context switch.

On reviewing a PR

Do:

• Assume competence and best intentions.
• Ask for clarification when you don’t have sufficient context for the code that you are being asked to review.
• Ask the author to break down the change into smaller PRs if the PR is longer than 250 lines.
• Focus on overall correctness & substance of the PR rather than being nit-picky. Clearly prefix your review comment with the term “nit” if you are making a suggestion that is nit-picky to help the author understand your expectations.
• Proofread doc-string comments.
• Positively reinforce PRs/changes that are well written and uphold the team’s standards by letting the author know that they did a good job. This will help foster a more positive team culture.
• Reviewer a PR within the defined SLO. If you are swamped/busy, let the author know that the review might be delayed.

Don’t

• Approve the change if the change is not safe to ship as-is.
• Ask the author to change code just because you prefer code being written a certain way. Instead, provide artifacts (code review guidelines, written standards) that rationalize your comments. When possible, link to the relevant section in the style guide.
• Make reviews personal. Criticize the code rather than the author. For e.g. don’t say “why are you making this more complex?”. Instead, prefer to word your comment as “introduction of Gevents here is adding complexity without any performance gain because…”
• Lock the PR unless the current state of the PR is clearly not acceptable to be merged, or the changes are dangerous. Locking is a blocking action and should be used with caution. If you do need to block a PR, clearly explain the issue and work with the author on resolving it.

By establishing these standards, my team was able to reduce the code review time from over a day to ~ 3 hours and we were able to establish a code reviewing culture that was more positive and thorough.

How does your team do code reviews? Anything in this article that you agree or disagree with? Feel free to leave your thoughts in the comments below.

Follow me to be notified whenever I publish an article like this one. If you are interested in interviewing, you might also want to check out my article called “The LeetCode Phenomenon” or “Why Microsoft didn’t love me back”.

I was pretty baffled when I first learnt about Netflix’s philosophy of hiring exclusively senior software engineers. What? No room for my beloved new grads or mid level engineers? How very square of them!**

I recently left my job as an engineering manager at Lyft. As I’m mulling over my last 2 years in engineering leadership, I’ve come to obsess over what I call the “inverted triangle” team composition problem in tech. One of the challenges that engineering managers face is building a team composed of engineers at the right level of seniority. But let’s not get ahead of ourselves! Before we dive into team composition, let’s talk about the seniority bands in tech companies.

Roughly speaking, seniority in engineering spans across 4 bands. We have the mighty staff engineers (SE) who are experts in the fields and are responsible for setting the technical vision and overseeing multiple projects on the team. Then we have senior engineers (SR) who will typically lead a large, complex project and are expected to be able to run the day to day operations of the team (if summoned to do so). Mid level Engineers (M) have typically been in the industry for 2–5 years and work on sub-features of projects. For e.g. a senior engineer responsible for building the purchase flow for Crypotokittens may break up the project into several features (and example of a feature may be to fetch the available token balance) which can be picked independently by a mid level team-mate. Junior Engineers are typically new to the industry and operate on tasks rather than projects or features. For e.g. to display the available token balance, one of the tasks might be to make an API call that returns the available tokens.

Here is another fun fact — the senior engineer level is considered to be the “terminal” level at many tech companies. What this means is that every junior or mid level engineer is expected to get promoted to the senior level within a recommended timeline. At Lyft, the recommendation is 24 months for a junior engineer to get promoted to mid-level and 30 months for a mid-level engineer to get promoted to the senior level. Once an engineer reaches the senior level, they can choose to stay there indefinitely (if that’s what they wish to do).

Finding the right makeup of a team is complex since it depends on factors such as the technical complexity of the team’s domain, as well as the motivations/ambitions of your team. For e.g. a team that owns projects/products in a highly technical space is likely to thrive with an inverted triangle composition (high ratio of senior to junior engineers). This is in contrast to the “classic triangle” team composition — more junior and mid level engineers than senior/staff engineers. The “inverted triangle” team composition is common at companies like Microsoft. Since Netflix hires only senior engineers, the team composition can be seen as a square:

The reason why the classic triangle composition works pretty well is because it allows for a diverse set of team skills. Entry level engineers work on simpler tasks, mid level engineers work on features and senior/staff engineers work on a project or multiple projects. Tenured engineers grow by learning to mentor and delegate and junior engineers improve by following the examples set by more senior engineers. This dynamic keeps the entire team motivated — the senior/staff engineers on your team can focus on harder, ambiguous problems while more junior engineers focus on well defined tasks or features which are challenging for them but might feel more mundane to senior engineers.

The antithesis of the “classic triangle” is the “inverted triangle” (the “square” composition is just another flavor of this). The engineering team I inherited (and managed) at Lyft was, at one point, composed of 3 staff engineers, 4 senior engineers and 2 mid level engineers. Problems in the inverted triangle manifest if the top of the triangle is highly motivated by promotions/career growth and there aren’t enough complex problems to solve. This will typically happen on teams that are bloated — there are bound to be ego clashes and interpersonal conflicts. In the worst case, it leads to prioritization of unnecessary projects to invent scope to appease the top of your triangle. Or you may run into what is infamously known as “terrain grabbing” where you try to take on projects that don’t naturally belong in your team. To put it bluntly, shit gets political and it’s not a good place to be as an employee or a manger. At Lyft, in spite of my team being low ego, I saw many symptoms of bloat and scope grabbing.

Having said that, I’ve been in teams where the “inverted triangle” worked pretty well- when I worked as a software engineer at Google, my team was composed of 4 senior engineers and 2 junior engineers, all working on the same problem (rewriting of our funds transfer backend). Even though it’s been many years since (and the project has long been deprecated), I have fond memories of the rewrite-it’s been one of my favorite projects as I learnt a lot from the seniority around me. The team composition worked in spite of being top heavy because the team was low ego, the problem space was large and complex enough, and 3 of the 4 senior engineers weren’t fixated on getting a promotion- they were simply in it to solve cool technical problems.

Here’s another rebuttal of the “square” team composition via a rather flippant hypothetical: Let’s say that I’m a mighty Pharaoh and I hand you a thousand gold coins to commission you to build me the Pyramids in a year. Would you hire just 20 architects (think staff engineers) who demand wages of 50 coins a year? Or would you just hire 2 architects to come up with the blueprints and plans and use the remaining 900 precious coins to hire laborers of various skill sets? Think junior laborers, mid level laborers and maybe some foremen (senior laborers)? How ineffective it would be to have your architects with highly specialized skills spending 90% of their time laying down stone blocks in a straight line when an entry level laborer could do that job just as well.

Switching over from effectiveness to principles- I believe that the rich, capable talent in the tech industry has developed to a large extent from teams that follow the classic triangle composition — new grads emulate the patterns and styles of more senior engineers and in time grow into capable mentors themselves and the fruitful wheel of wisdom and good unit testing continues. By hiring only senior engineers, Netflix doesn’t contribute to this cycle of training Padawans and contributing to the enrichment of our industry (although they may argue that they help build jedi grand masters out of jedi knights).

The “inverted triangle” composition is actually a fairly common dynamic that cuts across the industry. I’ve experienced it first hand at big tech so be aware of the possibility of this dynamic creeping into your team and factor the team composition when weighing whether to join a team!

**It seems like Netflix has deviated from trend and has, in recent times, opened up more roles for junior/mid-level candidates. I hope that this trend continues!

If you enjoyed this article, you may also want to check out The Leetcode phenomena. Follow me on Medium to be notified whenever I publish a new article.

This is the final part of a 4 part series on cracking the system design interview. Part 0 provided an overview of this article series, part 1 focused on the content you need to master to nail the interview and part 2 focused on the format you should follow during your system design interview.

In this final part I’ll provide a real life example of a system design problem — designing a donation app. I lifted this problem from this discussion on Leetcode. Here is the problem statement:

• You are required to design a donation app for a 3 day charity event across the US where you are expecting 3 million donations.
• You should accept details like customer name, credit card details etc.
• No pay specific knowledge is required (presume that you’d integrate with a 3rd party pay provider like Stripe or Braintree).

If you are a visual learner like me & prefer videos to words, you can skip ahead to watching the video (it’s listed at the bottom of this post) and then come back to the article. I do recommend reading through the entire article as it covers some key concepts that I didn’t cover in the video.

Understanding requirements/goals

Focus on understanding the requirements to establish the bounds of the problem. Focus on the functional requirements (these would typically be specified in a PRD) as well as the non functional requirements.

For functional requirements, some of the questions you can ask are — Will the users be logged in? Will they be using an app? What’s the user experience if the payment fails or succeeds? Can the user view their past donations?

Note that if you are a senior candidate, you are expected to own the problem & it’s preferable that you come up with your own assumptions rather than expecting the interviewer to define constraints for you.

For this problem, I’ve chosen to focus on donations and largely ignored how details about the charity are surfaced in the app.

The non-functional requirements will typically help establish the bounds/constraints of the problem. Use back of the envelope calculations to get the RPS (requests per second). 3 million donations over 3 days translates to 10 RPS. The shape of the traffic should be a consideration — e.g. most of the traffic for the donation app will come during the day time, and there might be further spikes in case of celebrity endorsements. For scale, we should build a system that can handle 100 RPS. To wrap up this section, you should comment on availability (improved via redundancy), latency (not super important here), throughput (improved via partitioning), consistency (eventual, read after write).

Data modeling & APIs

The main entities are User, PaymentMethod, Donation, PaymentAttempt which represent different micro-services (i’ve ignored Charity to reduce the scope). Draw out the entities & establish the relationship between them.

Note that Donation & PaymentAttempt could be tables within a single micro-service which would allow us to leverage on the ACID properties of relational databases & provide us with transactionality. However, it’s common to follow the single responsibility principle & have the Donation service be separate from the PaymentAttempt service. This is justifiable if the PaymentAttempt service would be called by services other than the Donation service (e.g. a Shopping service). If we create a PaymentAttempt micro-service, it would be important not to leak donation related information into the PaymentAttempt service. For e.g. the donation_id would be renamed to something more generic like auxiliary_id (the id is called the donation_id in the video and needs to be corrected).

The biggest challenge in micro-service architecture is eventual state consistency. For e.g. if the payment attempt succeeds, we’d need to notify the Donation service so that the status of the Donation entry can be updated. If the webhook/event never reaches the Donation service, we risk being in an inconsistent state.

System architecture (component diagrams)

I recommend calling the 3rd party payment provider when the user is “in-session” (in-session means that the user is online & attempting to make the donation live). In the happy path the client would receive a status of 200 with donation status SUCCEEDED in real time. However, to design a system that is robust, we should enqueue retries if the 3rd party provider is unavailable & we receive a transient failure response. Retries can happen offline & we’d need to keep the overall state of the donation in sync with the status of the latest payment attempt.

Failure scenarios

Failure can happen at multiple points. Network blips can cause timeouts or databases can go down. We should also monitor for data inconsistencies. We should also rely on idempotency to ensure that a single donation does not result in multiple payment attempts.

Leader nodes can fail & one of the replicas will need to be promoted to be primary. Scenarios like split-brain should be prevented and replication lag should be monitored for.

Scaling

Partitioning can increase throughput. Partitioning by hash of the user_id is better than partitioning by range as range based partitioning can lead to more hot spots (e.g. imagine that a celebrity tweets and thousands of new users create accounts and start donating — they will all hit the same partition if user_ids are generated in an increasing order).

Video

Hope that you’ve enjoyed the article series & the video (sorry for the scratchy background noise — unfortunately it’s a part of the app I used to record the video).

If you have questions about the solution I presented or if you have suggestions on how this design could be improved please feel free to leave a question or comment. If you found this article useful, please consider following me on medium or reposting this article on social media. You may also be interested in reading my article called the LeetCode phenomenon.

Please read part 0 to get an overview of what to expect in this article series. Part 1 lists out the study material required to nail the system design interview. In this article, we will cover the format you should follow during the system design interview.

Typically system design interviews will focus on a narrow part of a larger problem. For e.g. you are way more likely to be asked to design a service for tracking driver locations rather than to “design Uber”. Interviewers do this because it’s much easier to gauge your performance on a problem that is narrow & well understood by them than something broad (which runs the risk of the interview getting derailed).

Let me start off by saying that you should be leading/driving the system design conversation. If most of the talking is done by the interviewer, you’re probably not doing too well. Your interviewer will often interject & challenge what you say, so be prepared to explain the rationale behind your design recommendations & decisions. Usually there is no single right answer — there are typically many good ways to solve the problem, and it’s about making trade-offs.

The rubric used to assess you

It’s important to keep in mind how you’ll be assessed. Although this will vary to some degree from company to company, by and large the rubric for the system design interview assesses the following:

1. Can you navigate an ambiguous problem space?
2. Are you structured in your problem solving?
3. Do you make the right trade-offs?
4. Do you think through failure cases?
5. Do you identify & address constraints?

Some other companies (e.g. Facebook) might also assess your ability to come up with accurate back of the envelope calculations which you would be expected to translate to the physical resources necessary to make the system work. Other companies might focus more on product APIs and assess your ability to think about how your decisions impact the end user experience.

Structure of the interview

Start your interview by providing an outline of the structure that you intend to follow. This not only provides structure to your interview but also provides a signal to the interviewer that you intend to be comprehensive in your design. I recommend that you follow the following structure:

1. Understanding requirements/goals
2. Data modeling & APIs
3. System architecture (component diagrams)
4. Failure scenarios
5. Scaling

Earlier on I used to draw the system architecture (component diagrams) before outlining the data model/APIs. In one of my design interviews, an interviewer correctly pointed out that the data model reflects your understanding of the problem space and has the ability to influence how services are set up. So the system architecture should follow the data modeling & APIs.

Now let’s cover each section in detail:

1. Understanding requirements/goals

The problem can be sparsely defined and it’s your responsibility to establish the bounds of the problem. You should establish the functional and non-functional requirements separately.

Functional requirements usually relate to product features — in the industry these would be specified in a PRD (Product Requirement Document). For e.g. if the prompt is to design a donation service for a charity campaign, here are some questions you can ask to clarify the functional requirements- Who generates the campaign & how is it generated? Does the user need to be logged in to make a donation? How does the user receive confirmation that their payment was successful? Do we need to build any fraud checks?

In order to dig into the non functional requirements, you’ll need to perform some quick back of the envelope calculations. The back of the envelope calculations will allow you to identify the constraints that might impact your design. Are there memory constraints or can everything be served out of a cache? Are there storage or compute constraints? What is the RPS (requests per second)? Do you need to partition data onto multiple machines to handle very high throughput?

You should memorize the following numbers as it will help you come up with estimates quickly:

• 10⁶ Bytes = 1 Million Bytes = 1 MB
• 10⁹ Bytes = 1 Billion Bytes = 1 GB
• 10¹² Bytes = 1 Trillion Bytes = 1 TB
• 2³² = 4 Billion
• Time taken to read 1 MB serially from memory = 0.25 ms
• Time taken to read 1 MB serially from SSD = 1 ms
• Time taken to read 1 MB serially from disk = 20 ms
• Disk seek = 10 ms
• Same data centre roundtrip = 0.5 ms
• Inter-datacenter roundtrip = 150 ms
• Seconds in a day = 86,400 = 10⁵ (approximated to 100,000)
• 2³² Bytes = 4 Billion Bytes = 4 GB
• Twitter generates 500 M tweets a day with 200 M daily active user (DAU) & 300 M monthly active users (MAU)
• Stack overflow has 5 M DAU
• Wikipedia has ~ 6M articles
• The average size of an image is 3 MB

To illustrate with an example — if you are designing the read path for facebook’s timeline, you can use Twitter’s daily active users to estimate the RPS. You’d start by stating your assumption that facebook has 2X traffic when compared to Twitter (in reality it’s closer to 5X, but the precise multiplier is irrelevant here — what is more important is to demonstrate a consistent and logical chain of thought). So we expect 300 * 2 = 600 M DAU. Let’s also assume that a user opens facebook 5 times a day. This translate to 600 * 10⁶ * 5 requests to fetch the user timeline per day.

600 * 10⁶ * 5 = 30 * 10⁸ requests per day = 30 * 10³ requests per second (we divided by the number of seconds in a day — 10⁵). A single machine running commodity hardware will struggle to handle a throughput of 30,000 RPS so we are better off sharding this traffic across 10–15 machines.

Before proceeding to the data model, you should comment on the availability, latency, throughput and/or consistency requirements. This is important as you’re providing a signal that you think about constraints upfront.

These concepts are covered in detail in Chapter 5 — Replication & Chapter 6 — Partitioning in DDIA (Designing Data Intensive Applications). For a complete list of sources that I recommend, please read part 1 of this article series.

Availability: Most designs will have high availability as a requirement. Replication & redundancy increases availability.

Latency: If there is a latency requirement (e.g. search autocomplete), you should serve reads out of a Redis cluster/CDN.

Throughput: Partitioning improves throughput.

Consistency: Eventual consistency is sufficient for most designs. Read after write consistency might be desirable in most use cases where the user mutates state (e.g. when a user deposits a check and refreshes a page, they should continue to see a pending balance rather than it appearing/disappearing which can happen if the request is served by a replica that has not caught up).

2. Data modeling & APIs

Once you’ve established the bounds of the problem, the next step is to identify the main entities and how they relate with each other. For e.g. for Twitter’s timeline, the entities are User, Tweet & Follower. You should identify the primary keys, foreign keys, indexes & the relation between the entities (one-one, one-many, many-many etc).

Establishing the data model will allow you to recommend the underlying database technology. If joins and/or transactionality are required, relational databases (MySql/AuroraDB/Spanner) are an appropriate choice. If the query patterns are simple (e.g. simple gets & puts), a nosql database like DynamoDB might be appropriate since it can support higher throughput and scales better than SQL databases. Nosql is also great for representing documents with a one-many schema representation forming a tree structure. DDIA’s chapter on Data Models & Query languages is a good resource to help gain familiarity with the various database technologies.

At this step, you should also check with your interviewer if you should define APIs. If the data model is simple, there will be a good deal of overlap between the data model & APIs so you can save some time by skipping the API definition.

3. System architecture (component diagrams)

Start simple — no need for drawing out load balancers and partitions at this stage. Draw out the main services & talk about their interactions. Look for parts that can be made asynchronous via queues (queues can handle spiky traffic, reduce jitter & can reduce latency). Zoom in on important parts of the design — How do you handle idempotency? Do you require locks to handle concurrent writes?

4. Failure scenarios

This is the most overlooked part of the system design & is glossed over by most online resources like grokking/system design primer. This is especially relevant for Senior & Staff engineers as consideration for robustness is factored into your levelling.

In modern micro-service architecture, you should design with failure in mind. A system that can gracefully handle failures is superior to a system which is designed to “not fail” because when these systems do encounter failures (and they inevitably do), they tend to be difficult to recover from, or are in some cases downright catastrophic.

You should cover both application level & system level failures. Here are some discussion points — what happens when a request times out & returns a 500? How would your system behave when the database is degraded? What happens if you mutate state and your service is unable to enqueue a message? What if the consumers of your queue fail?

Eventual consistency is typically a reasonable architecture for modern day systems. This comes with its own set of challenges of course — failures can result in two services being in an inconsistent state. How would you detect & fix these inconsistencies? (typically you’d need a healing cron or another offline service which can detect & mitigate inconsistencies).

It’s also worth talking about system level failures. What happens when a node goes down? Can it cause a thundering herd? How does failover happen? Would you use active-active or active-passive modes for redundancy? Bonus points for mentioning how new leaders are elected and what can go wrong when the leader dies (split brain, data loss due to replication lag etc. Read Chapter 5 — Replication from DDIA).

5. Scaling

You should talk about horizontal scaling & how you’d increase throughput via partition and whether you’d partition by range or by hash. You should be familiar with Zookeeper & how the routing tier works. Mention caching (CDNs, Caching servers) which not only decrease latency but also prevent traffic from hitting your application servers. DDIA’s chapter on Partitioning covers this in detail.

Conclusion

Conclude the design by commenting on observability & monitoring. You should also touch on security (SSL/TLS) and data encryption.

If you manage to cover all 5 steps during your interview, you’ve probably nailed it. Time management is an important piece of the interview so keep a stop-watch on your desk.

In my next few articles, I’ll discuss the best tool (e.g. google docs, whiteboard etc) for the interview & go over an example problem following the recommended format.

Follow me on Medium to be notified whenever I publish a new article. If you are preparing for a software engineering interview, you might find this article interesting.

Please read part 0 to get an overview of what to expect in this article series.

This part focuses on the preparation materials required to nail the system design interview. Knowledge alone isn’t sufficient to excel at the system design interview, but a solid theoretical foundation is necessary.

You’ll need to go for depth as much as for breadth. Go slow & really understand the concepts. Don’t spend more than a couple of hours on a single article or video in one sitting. This is a firehose of information & your ability to absorb & retain knowledge diminishes beyond a certain threshold.

Be curious — if the article mentions exponential moving average, spend a few minutes on wikipedia to understand what exponential moving average is about, and what the common applications are in software (trending topics, auto-complete etc). Re-read & revise. For e.g. Raffi Krikorian’s Twitter timelines at scale is a 38 minute video, but I’d expect you to spend 1.5–2 hour on watching it. Pause the video when you don’t understand a concept. Rewind, rewatch. Take notes. Truly internalize it. At the end of the video you should know every little nuance — what does it mean to scatter-gather? What happens when a user’s home timeline falls out of the redis cluster? What trade-offs did twitter make when designing for time-lines at scale (you can’t scroll more than 800 tweets etc). Go the extra mile — grab a pen & paper a couple of days later & reconstruct the design by yourself. That’s how you’ll internalize it.

Here are the resources I recommend covering. I recommend starting with the system design primer but don’t prescribe a specific order for the other resources. Learning isn’t linear. Jump from a video to an article and back to a chapter from Designing Data Intensive Applications. Maybe you’ll read the chapter on Stream Processing and then jump to the video on streaming a million likes a second. Go back and revise what you’ve already covered. Make your own notes that summarize key concepts that you can go over quickly when revising.

The System Design Primer: This one is about breadth rather than depth. Read ALL of it & get familiar with the various technologies (CDNs, caching strategies, RPCs, DNS etc). This source covers the basic building block which will allow you to go really deep.

Designing Data Intensive Applications: This is an excellent book and as you read through it, you’ll understand why the System Design Primer is inadequate. This book will help you become a better engineer and generally improve your understanding of large scale distributed systems. You really need to chew & digest the concepts in here. Underline things that are insightful to you. Make notes that you can refer to later. Although the book is over 500 pages long, there is very little in the book that is not useful and in spite of over a decade of building large scale systems, I learnt a lot. It will help you understand why you’d use NoSQL or RDS or GraphQL, how replication improves redundancy & partitioning improves throughput, what the various levels of transactional serializability are & why distributed transactions are complex and expensive. You’ll also learn about MapReduce, stream processing (Kafka) & Zookeeper. If there is a single thing that I want you to take away from this article, this book is it.

Videos: InfoHQ & YouTube host videos that give you an insider peek into how large scale distributed systems are built around the world. I encourage you to watch these videos even outside of your system design preparation to incorporate good design principles into your own designs. Here are some that I recommend watching:

• Twitter timelines at scale: This is one of my favorite system design videos of all time. You’ll learn about fan-out, making the trade-offs between write time optimization vs read time optimizations, and performance optimizations between polling & fan-out.

Timelines at Scale

• How twitter handles 3000 images per second: Great talk on how to decouple media uploads from tweeting. The learning from this can be applied to many system design problems.

3000 images per second - Henna Kermani

• Scaling Push Messaging for Millions of Netflix Devices: It will help you understand how websockets are implemented at scale & the complexities that can arise during deploys & outages.

• Scaling Facebook Live Videos to a Billion Users: Facebook’s live-streaming infrastructure & the challenges of scaling it.

• Streaming a Million Likes/Second: Facebook’s real-time interaction platform.

Articles: While the videos above go pretty deep, it’s important to understand a breadth of concepts. The following articles will supplement your learnings from the videos above:

• Apache Kafka & Zookeeper
• Figma’s multiplayer technology
• Stream processors & stream joins
• Stackoverflow: Lucene vs Elasticsearch
• Stackoverflow: Websockets vs HTTP

Grokking the system design: This series is mediocre at best. My main criticism is that there is too much hand-waving. While the author has definitely spent some time reading white-papers, it lacks the depth & attention to detail that you’d expect from staff engineers. For example, the article on Typeahead suggestions doesn’t even discuss streaming as a solution to building derived data. In most of the articles, there is little/no emphasis on mitigating failure cases. For e.g. when designing Facebook Messenger, there is no mention of the thundering herd problem which will happen if a node goes down & all clients reconnect to a different node at the same time (this is covered in depth in this talk). Nevertheless, I recommend grokking because it covers the most commonly asked system design problems and it will help guide your high level design. When studying grokking, focus on the details and understand concepts like QuadTrees (for geo-fencing), Bloom filters, Checksums for preventing storage of redundant file chunks etc. As an alternative (or supplement) to grokking, I recommend System Design Interview by Alex Xu as it goes one level deeper than Grokking.

These resources will get you 90% of the way to nailing the system design interview. I’ll repeat what I’ve said before. Don’t be in a rush — you can’t become an expert in a single sitting.

In part 2, I recommend the format you should follow during the system design interview.

Follow me on Medium to be notified whenever I publish a new article.

If the system design interview has always been your achilles heel, this article is for you. It definitely used to be mine. Unlike coding interviews which are fairly unambiguous, there isn’t much material on preparing for the design interviews. Google searches on how to prepare inevitably take you to two main sources — the System Design Primer & Grokking the System Design interview. Like most others, I simply relied on these two sources for my preparation. However, no matter how many times I’d read these two, I just couldn’t nail the design interviews (although I did scrape through a couple). While these two sources have some merit & they should play a role in your system design preparation, they are inadequate.

I’m finally at a point where system design interviews don’t cause knots in my belly. There is some nervousness, of course, but also excitement derived from confidence. I can pass roughly 75% of my system design interviews at the T6 (staff engineer) level. I figured it out through a combination of trial & error and thoughtful deliberation.

Let me preface this by saying that acing the design interview will take time & deliberate practice. You just can’t cram your way through. No amount of grokking will let you ace this one (although it might allow you to clear the L4 bar).

Francis Bacon said “Some books are to be tasted, others to be swallowed, and some few to be chewed and digested.”

Translation: some books are to be read only in parts; others to be read, but not curiously; and some few are to be read wholly, and with diligence and attention. For the system design interview, you’ll need to put your molars to good use. There’s going to be plenty of chewing and lots of digesting. You’ll need to read & re-read 100s of pages. You’ll need to watch & re-watch dozens of videos. You’ll need to take notes, revise your notes & become a scholar. You’ll need to understand concepts so deeply that you can recite them in your sleep.

I’ve only gotten to where I am today by failing several system design interviews. It’s hard not to feel disheartened by rejections but rejections are learning moments. I’m a strong proponent of failing-fast and I view failures as opportunities to refine my process. I’ve obsessed over my failed system design interviews for days after- replaying the interview over and over in my head — sifting through my memory for things that I could have done better. Failures have helped me internalize what not to do (that time when I jumped into data-modeling without really establishing the bounds of the problem) and what to do more of (that time I forgot to talk about using locks to prevent concurrent client payment attempts).

This article series is a step by step guide on preparing for (and hopefully nailing) the system design interview. I’m going to cover this in 4 parts. You’re currently reading part 0. Part 1 will list out the materials (books, articles, video series) that you need to “chew & digest”. Part 2 will focus on the right format to follow during the interview & the best tools (pen & paper or google draw?) to use for the job. In the final part, we will incorporate our learnings into a real life interview problem (e.g. design a donations app) & I’ll walk you through my solution.

This article series is relevant for anyone preparing for system design interviews. These interviews typically determine your level and a good systems design interview performance can be the difference between an L5 (Senior) offer and an L6 (Staff) offer. This article series might be especially pertinent for L5 engineers who are at the cusp of L6, but are unable to crack the system design interview.

Do you need real life system design experience to nail these interviews?

The short answer is: probably. If you are interviewing for an L4 role, you might be able to get away without having too much real life experience. For L5 & above, it gets trickier but you can probably interpolate a lot by watching videos/reading articles that I’ll enumerate in part 1.

For further reading, see part 1 of this article series.

Follow me on Medium to be notified whenever I publish a new article.

“And here I was, thinking that I’m the one asking the tough questions” I replied, smiling at him encouragingly.

I was taking a sabbatical from Software Engineering at Google and spending the Fall teaching at the University of Puerto Rico.

Marcus was one of the quietest students in my class and he’d never volunteered to ask a question before. Sometimes, after I’d cracked a joke in class, my eyes would meet his, and he would smile fleetingly before looking away shyly, as if embarrassed that I’d caught him smiling. So I was both surprised and pleased when he walked over after class, patiently waited for me to gather my notes and markers and asked me this question.

I wasn’t a stranger to having students walk up to me to ask questions about being a professional Software Engineer, or about working at Google, or both. Often I’d never even met the students before, but I enjoyed these interactions. I appreciated the warm candor of these questions- the raw inquisitiveness. They likely didn’t have many opportunities to interact with Software Engineers, and were curious about the career they themselves might embark on one day.

Their questions ranged from the frivolous: “Does Google really have a rule about food being within 200 feet from employees at all times?” (no), “Can you really have someone do your laundry at work?” (yes) to the more pragmatic- “Should I join the industry or stay in Academia?” (it depends).

I’d been asked the same questions so many times that I always had an answer or quip ready. But this wasn’t a question I’d been asked before. I paused, contemplating how I could condense my decade long experience into a few pearls of wisdom.

“How about we set up some time to chat about that?” I offered, and Marcus nodded.

Later that night, I opened my laptop and tried to put down my thoughts into words. Not only do I find writing to be cathartic, but anchoring my thoughts into words usually help me build clarity.

Marcus’s question prompted a lot of reflection on my life as a Software Engineer. I’ve worked at a Technology Incubator in Ghana, as a Software Engineer at Microsoft & Google and as an ad hoc Professor at the University of Puerto Rico. I’ve flip-flopped between optimism and pessimism. I’ve been an anti-establishment couch potato and a social justice warrior. I have both hated the man and embraced him.

I decided that I wanted to give Marcus an answer that would be useful to him. I wanted these “lessons’’ to be practical- something that he could be mindful of and get better at as he forayed into the industry. Many of these lessons were learnt from costly mistakes, and I hoped that he could avoid making the same mistakes I did. This blog post stems from my reflections from that night. I hope that you’ll find it useful.

Lesson#1: Reputation compounds

I worked at Microsoft from 2012 to 2016 and at Google from 2016 to 2020.

When I announced my departure from Microsoft in 2016, my boss smiled, thanked me for my work and wished me luck. That was it. There was no counter-offer, no attempt to keep me at the company. There wasn’t even a farewell dinner. Walking away from Microsoft was the easiest professional decision I’ve had to make.

I remember sulking about it to a dear friend and colleague over coffee. “Sounds like Microsoft gave you an Irish good-bye”, he said, winking.

I’ve had plenty of time to think about my mediocre 4 year stint with Microsoft. I can’t honestly say that I accumulated 4 years’ worth of knowledge. Initially, I blamed everyone but myself. I blamed the company (“Microsoft’s a dinosaur!”), my team (“It’s because of the constant re-orgs!”), my management (“It’s because I was punted from manager to manager!”) and the projects (“I was given low impact/uninteresting projects!”).

Since then, I’ve come to realize that reorgs, restructuring and changes in management are inevitable in companies at the Microsoft/Google scale. I’ve also improved at self reflection. “My experience sucked because I wasn’t given good projects” is a bit like saying “I got a speeding ticket because there were a lot of cops patrolling”. Factually correct, but obfuscates the underlying issue. What’s the first principle here? Why wasn’t I given good projects in the first place?

In the fall of 2020, when I told my manager that I intended to move on from Google, he was visibly upset. Both my manager & my director tried their hardest to keep me at the company. They offered me more money and juicier projects. Former colleagues and managers messaged me about my departure, often with offers to join their teams. Walking away from Google was one of the hardest professional decisions I’ve had to make.

The main difference between my tenure at Google and Microsoft was the reputation I had for my craft. And my attitude fed my reputation.

I joined Microsoft in my early 20s and at a stage of my life where my career just wasn’t my priority. I don’t necessarily judge myself for it — I was young, single, hedonistic, living in a new city and making decent money. But I developed a reputation for someone who needed constant guidance- someone who “wanted it easy”. And this reputation was hard to shake off long after my attitude towards my job changed.

In 2014, Satya Nadella took over the reigns of Microsoft and orchestrated a shake-up of the prevailing software development process at Microsoft by ruthlessly reducing certain roles. Prior to 2014, most teams at Microsoft were staffed with one quality engineer (called Software Development Engineer in Test or SDET) for every developer. SDETs were responsible for testing the code that developers wrote. In contrast, typical companies in Silicon Valley today have 1 quality engineer per team of 12–20 developers.

As a consequence of the restructuring, majority of the SDETs on my team resigned (or were fired) and the team shrank down to 6 people who were responsible for overall quality. I was the only developer included in this team of former SDETs. I learnt from a mentor that management thought that this team would be a better fit for me since it wasn’t a critical/core team.

It didn’t matter that I had put my act together in the several months leading to this reshuffle & was producing high quality work. The reputation I’d developed overrode what I was actually delivering. Once I’d been assigned to a low impact team, I ended up working on low impact projects and delivering low value to the company. This culminated into what I call the cycle of dispensability, which can be quite detrimental to career growth.

First impressions matter. Once you develop a poor reputation, it takes a disproportionate amount of effort to reverse that. Your first 6 months at a new company will be your most important. The reputation you develop will determine the kind of projects you get to work on, which will further feed into your reputation. Reputation compounds.

By the time I joined Google, I was determined not to make the same mistakes again. I hit the ground running, and those first 6 months were probably the hardest I’ve worked. I taught myself mobile and backend development, learnt about java services and Spanner.

Pretty soon, I developed a solid reputation. Within a year, I was getting the pick of the projects and within a couple more, I was leading the highest impact projects for my team. Yes, there were re-orgs and manager changes but the reputation I’d developed stuck to me, and was almost magically transferred from manager to manager. My reputation gave me leverage to craft the life I wanted. Almost every year, I took a month off to travel. I often worked remotely, from different countries, and got to work on super fun projects.

Work on building a cycle of indispensability. You’ll reap the benefits of it for many years.

This is the first part of a multi-part series where I will discuss the biggest lessons I’ve learnt as a professional Software Engineer. Follow me to be notified whenever I publish a follow-up to this article.

If you are interested in interviewing or programming, you might also want to check out “The LeetCode Phenomenon” or “No comments.”

Credits: Icons in the comic strip made by Freepik from Flaticon

Why Microsoft didn’t love me back was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

“Comments should account for 5% of the total points” my fellow teacher declared.

In the fall of 2019, I was co-teaching an introductory course in computer programming and got into a disagreement on whether the students should be required to incorporate comments into their project submission.

“I want the students to develop good practices early on in their career. Surely, you’ll agree that adding comments improves code quality?” the fellow teacher asked me, almost righteously, a little miffed at my pushback.

I disagreed, and emphatically. Being encouraged to sprinkle comments everywhere is probably the worst programming practice being taught in school. Barring certain cases where comments are justified (I cover that later), adding comments is an anti-pattern, and an excessively commented code-base suggests a need to refactor.

Wait, what is this heresy? Comments can’t possibly hurt. Can they?

Here are the two reasons why I consider comments to be an anti-pattern:

1. They invariably go out of date. People forget to update comments as code gets refactored and features are developed. When this happens, comments become the root cause of the very thing they are meant to avoid — confusion. This is especially true at large companies where there are several people actively changing a common codebase. Imagine the plight of a poor new hire who just can’t wrap his head around why the house has an empathic comment calling it a Palm Tree.
2. Programmers (myself included) write comments that are redundant or poor. I’ve observed this to be the case at every company I’ve worked at and many excellent programmers are guilty of this. On my team at a prominent big tech company, we had a rule that every single protocol buffer definition needed to be preceded by a comment. So we had way too many instances of code that looked like the following:

// Represents a Dog.
message Dog {
    // The id of the dog.
    string id = 0;
    // The name of the dog.
    string name = 1;
    // The breed of the dog.
    string breed = 2;
}

Redundant comments are noise, and can make files twice as long as they need to be.

Allrighty, I see your point. Redundant comments are dumb. But what about the instances where comments are needed to explain what my code is doing?

You can almost always find other ways to convey what your code is doing. A common strategy is to use well named temporary variables or method names to convey intention. Let’s look at a concrete example in code. I’m using python, since it’s most pseudo-code like, but the concept is programming language agnostic.

In this example, we are sending payouts to sellers when certain conditions are met. An example would be a seller on Amazon receiving lump sum payments for their sales on the platform:

# Seller is eligible to be paid under the following conditions:
# 1. It's past 2020/5/1 when we got legal approval to make payouts
# 2. It’s Nov/Dec since those are the only months eligible
# 3. User is not from list of countries that are banned

today = date.today()

if today > date(2020, 1, 1) and (today.month == 11 or today.month == 12) and user.country not in ['Narnia', 'Odan', 'Maldonia']:
    # This function does the actual payout by calling Stripe
    # It saves the response asynchronously.
    payoutHandler()

At first glance, it seems like comments are justified since they do enhance readability. Code is read many more times than it is written and so making code readable is a good thing. In this example, comments convey the following information:

1. The conditions for making a payout. Without the comment at the start, the burden is on the reader to parse the verbose sub-conditions in the if statement to understand if the payout should happen.
2. Why certain constants (2020/5/1, 11, 12 and [‘Narnia’, ‘Odan’, ‘Maldonia’]) are used and what they represent.
3. What the payoutHandler() method will do.

Now let’s look at how this code can be re-written to convey the same information without using comments:

PAYOUT_APPROVAL_DATE = date(2020, 5, 1)
BANNED_COUNTRIES = ['Narnia', 'Odan', 'Maldonia']
NOVEMBER, DECEMBER = 11, 12
ELIGIBLE_MONTHS = [NOVEMBER, DECEMBER]

today = date.today()
is_past_approval_date = today > PAYOUT_APPROVAL_DATE
is_eligible_month = today.month in ELIGIBLE_MONTHS
is_user_from_banned_country = user.country in BANNED_COUNTRIES

if is_past_approval_date and is_eligible_month and not is_user_from_banned_country:
 stripe_payout_resp = callStripeToPayout(user)
 saveResponseAsync(stripe_payout_resp)

You’ll notice that the information that was being conveyed by comments is now being conveyed by using temporary variables (is_past_approval_date, is_eligible_month, is_user_from_banned_country), constants (BANNED_COUNTRIES) and verbs as function names.

Good naming is a powerful tool that can replace comments and help you write self-documenting code. Now this code can be refactored mercilessly without any fear of the house being mis-documented as a tree.

Ok, so is it really never cool to add comments? That sounds draconian.

Here’s my rule of thumb — don’t use comments to explain the what. Instead, use them to explain the why, and only when you can’t convey the why through naming. In most cases you can leverage on good naming to convey the why. For e.g. instead of adding this comment:

# This code removes the invalid control characters because the 
# AS400 processor cannot handle them

name your function

def remove_AS400_incompatible_control_chars():

If you can’t rely on naming to get the message across — for e.g. if your code is doing something subtle/non-obvious, then comments are definitely warranted. Here are some examples of useful comments:
# Prevents a rare but severe race condition which happens when...
# Closing this write transaction before making the RPC to prevent stale locks

It might be worth looking at your codebase to see if you can replace some of your existing comments with self-documenting code.

Follow me to be notified whenever I publish an article like this one. If you are interested in interviewing, you might also want to check out my article called “The LeetCode Phenomenon” or “Why Microsoft didn’t love me back”.

Credits: Icons in the comic strip made by Freepik from Flaticon

Stop Adding Comments to Your Code was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

This is a follow-up to my previous article “The LeetCode Phenomenon”. While the article is targeted at folks who are struggling with converting interviews into offers, I’ve covered several tips/strategies that will be useful to anyone who is in the process of interviewing or curious about interviewing.

In the fall of 2019, I took a sabbatical from Software Engineering and spent a semester teaching interview preparation at the University of Puerto Rico. I co-taught and co-trail-blazed the course with a well loved and competent Professor.

I remember looking into the warm, curious eyes of the 30 students who had taken the elective. In their eyes, I saw excitement and expectation. Surely, there was no instructor better equipped to lead the course than a Software Engineer from Google?

In my first class, I made a mistake. I played this video. Then I told them that the only thing that stood between them and a juicy tech job offer was practice. “Let’s see how many of you can solve over 150 problems on LeetCode by the end of this semester”, I challenged them.

I do love the energy and delivery from the video. The crux of it is in this single line — “when you want to succeed, as bad as you want to breathe, then you’ll be successful”. When I was practicing for a half marathon, and struggling for motivation, the video inspired me. Showing this to a class of students who were already motivated to get better at interview preparation was a mistake. I was telling them to do a million push-ups.

Some students from my class did offers from big tech (Microsoft, Google etc) but many were unsuccessful in spite of having solved over a hundred questions on LeetCode. Friends and colleagues have share similar experiences- they just aren’t seeing success in interviews in spite of having solved hundreds of questions.

I was raised to believe in hard work. My parents worked long hours, and as a kid I saw cause and effect in action. I studied harder than my class-mates and so I did better than them academically. I’ve had a simple mantra — to master something, you need to practice till you are perfect. Do it over and over till it becomes a part of your muscle memory. 10,000 hours was the magic number proposed by Malcom Gladwell in his book ‘Outliers’. Do something for 10,000 hours and you’ll become great at it.

Let’s say that you give me a large log of wood and an axe to chop some firewood. If I don’t know anything about chopping wood, and start chopping the wood against the grain, I’m not going to get you any firewood. I can spend 10,000 hours wielding my axe against the grain, but I’m going to be a lousy woodcutter.

Practice makes perfect is incomplete advice. Practice needs to be done intentionally. Only through reflection will I realize that I need to chop with the grain, and not against it.

So what if you’ve solved 250 questions on LeetCode, and still can’t get an offer? Does that make you stupid? No, it just makes you bad at reflection.

Of course, given infinite time and infinite patience, you can brute force your way through the process by solving hundreds, or thousands of problems on LeetCode. But it’s inefficient. In reality, you’re probably studying or working full-time, and time spent on learning esoteric problems on LeetCode is time that you spend away from other things that are important.

The traditional approach to interview preparation is like this: you practice problems on LeetCode till you decide that you are interview ready. Then you line up as many interviews as you can and start interviewing. Perhaps you’ll take 2 weeks off from work and schedule the interview loops back to back. I call this the waterfall approach.

Rather than going with the traditional waterfall approach to interview preparation, make your interview preparation agile.

Agile interviewing structures preparation in sprints, with reflection at the core. Your objective is to iterate and fail fast. Each sprint should incorporate reflection, intentional practice, mock interviews and real interviews. Repeat this till you get a job that you want. The agile approach is optimal because you end up spending no more effort on preparation than is required to actually get the job that you want.

Not all sprints will be equal. Your first sprint will be the longest, especially if you haven’t interviewed in a while or are out of touch with data structures. Don’t wait to solve a hundred problems on LeetCode before you start interviewing. Don’t line up 10 interview loops over 2 weeks. You’re depriving yourself of a chance to reflect and course correct. You’re probably going to fail your first interview. Heck, you’re probably going to fail several interviews. Stagger interviews over sprints so that you have time to reflect on how you can get better.

Reflection

The objective is to identify gaps in your preparation.

In your first sprint, you’ll need to spend time to understand what you don’t know. When I started interviewing this year, I quickly realized that I needed to brush up on heaps and backtracking.

Second sprint onwards, it’s about looking back at your interviews and identifying areas of improvement. Replay the interviews in your head and write down your insights. Do this soon after the interview when it’s fresh in your head. What could you have done better? Were you too nervous? Did you make some unwarranted assumptions or ignore a large part of the problem? Or maybe you really need to brush up on fundamentals of Graph theory.

Be shameless in asking for feedback.

Most companies will decline your request, but some will be kind enough to offer constructive feedback. For example, Shopify told me that I didn’t spend enough time discussing failure/edge cases during my System Design rounds. Square told me that my coding seemed more reactive than proactive. Feedback is gold, and you should internalize it through intentional practice.

Intentional practice

The objective is to work on your weaknesses and get incrementally better.

How/what you need to spend time on will depend on your reflection but here are some general tips:

Don’t shoot for solving a certain number of problems on LeetCode.

• Instead, go for breadth and solve different categories of problems (backtracking, merging intervals, sorting via heaps, maze traversals etc). Try to solve problems in several different ways. Focus on understanding the various techniques. Look at a couple of top-voted submissions. You’re bound to learn a thing or two.

The coding problem you’ll be asked will be of a medium difficulty.

• Exceptions aside, interviewers aren’t going to expect you to know esoteric algorithms/data structures (e.g. Segment Trees, KMP etc). You won’t be asked to solve LeetCode hard problems in 30 minutes. When interviewing for Google, I used to like asking a very simple problem based on strings.

Skip dynamic programming.

• It’s not worth the time and most interviews will be perfectly fine if you use recursion rather than dynamic programming to solve the problem. My friends at Facebook tell me that they are explicitly asked to avoid asking problems on dynamic programming since they aren’t a good representation of work you’d be doing. The number of times I’ve used dynamic programming at work over the last 10 years is a big fat zero.

Don’t rush, and incorporate “spaced-repetition”

• If you aren’t able to solve a problem, don’t just read the solution and move on. At my interview prep course, I gave my students a list of 40 questions in advance and told them that their midterm quiz would be one of the 40 questions. Students who had simply “read” through the solutions didn’t fare well.
• Whenever you do end up looking at a solution, or discover a new interesting way to solve a problem, you need to revise it at frequent intervals in order to internalize it. You can keep track of what and when you need to revise by simply using a spreadsheet, or by adding events to your Google Calendar. You can use a fibonacci pattern (e.g. revise on day 3, 5, 8, 13, 21 etc). Alternatively, you can use apps like Anki that have spaced repetition built in.

Practice being proactive and thinking through failure cases.

• This is a part of the rubric used to assess your coding. When LeetCoding, think through the edge cases and do a dry run before hitting Submit. Develop the habit of minimizing the tweaks you need to make to your code to get a passing submission.

Mock interviews

The objective is to practice in a simulated but real interview environment. Think of this stage like releasing your feature to a staging/sandbox environment.

Talking out loud or being observed during coding isn’t natural. You need to normalize this so that you can give your best performance and avoid the dreaded “brain-freeze”.

There are plenty of free resources that will let you simulate real interviews. Sign up for pramp which lets you practice 1:1 with peers. It’s also a great resource for those who want to follow the sprint model but aren’t able to get many real interviews.

If you are privileged enough to easily get interview calls, you can skip this and go straight to the real interviews.

Real Interviews

The objective is to give it your best shot and collect data for your next sprint. Schedule 2–3 interviews at a time to understand where you stand.

Find the time of day that you’re most in flow. Find what works best for you. Maybe a run or a workout before the interview helps put you at ease.

Once you get an offer that you’re ready to sign, you can try to blitz your way through several more with the goal of obtaining some counter offers. Once you mention to a recruiter that you have an offer and deadline, companies will rush to finish your interview loop.

Build a routine that works for you.

Don’t be rigid with your sprints- the goal is to build the preparation model that works best for you. You might find that it’s best to skip mock interview entirely or you might find yourself jumping from intentional practice to reflection several times within a sprint:

The interview process is a marathon. Depending on where your skill levels are at, the process can take anywhere between 1 month to 2 years. Be patient and learn from your mistakes. At the risk of sounding cheesy, I’ll quote Confucius:

Our greatest glory is not in never falling, but in rising every time we fall.

This article was focused on coding interviews. The system design interview is an entirely different beast altogether, and I plan to cover that next. Follow me on Medium to be notified whenever I publish it.

Be Agile, not Prolific was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the winter of 2015, I was working as a Software Engineer at Microsoft and looking for my next Software Engineering job (here’s why), albeit with little success. I remember expressing my frustration to a friend over a velvety Stout beer at a funky bar in Seattle’s Ballard neighborhood on a cold, rainy November night. I remember his words clearly:

“So, there is this platform which sort of lets you game the System”

That’s when I first heard about LeetCode- a programming platform which has now become the staple for coding interview preparation. The platform consists of interview style coding questions with an integrated, online IDE which lets you submit and verify the correctness of your solution. It also contains a stack-overflow style discussion forum which lets you post and upvote/downvote solutions to the problems.

Today, if you are interview prepping, you’re going to have to spend some late evenings practicing interview problems on LeetCode. In the words of one of my good friends and colleague:

LeetCode is the great equalizer. Whether you are interviewing for an internship, as a fresh grad just out of college, or as a seasoned Engineering Manager, you’d better be LeetCoding.

I crawled home from the bar that November evening and started practicing problems on LeetCode. Over the next few weeks I practiced several dozen problems. Practicing made a huge difference that time and I eventually landed and accepted an offer from Google in 2016.

I’d never seen anything like LeetCode before. Platforms I’d been using for interview preparation before LeetCode had been passive — with information flowing in one direction (from the author to me). There was the quintessential interview preparation book “Cracking the Coding Interview”. Then there was CareerCup/Glassdoor which had user generated content that could be perused to find commonly asked interview questions. The main shortcomings of these platforms are:

1. They don’t really prepare you for interviews because they diverge from how real-world interviews are conducted
2. They are less engaging (due to a lack of a community)
3. It’s harder to internalize concepts/learning due to a lack of reflection. This is because you are offered one (or zero) solution to problems which can typically be solved in many different ways.

There were several programming platforms like TopCoder that were interactive and had a browser based IDE. However, these were optimized for competitive programming where the problem description itself would span multiple pages and you’d spend half the time trying to figure out the right input/output format rather than building actual algorithms.

LeetCode recognized a need and built a platform that was interactive, was closer to how interviews were being conducted in the real world and just worked. LeetCode does its job remarkably well- the problem definitions are succinct, the community is thriving and discussion forums have high quality discussions.

Fast forward to mid 2020, and I was interviewing again. The coding interviews seemed a lot different from 2016, not only because we were in the middle of a pandemic (not the focus of this article), but also because how LeetCode had evolved as a platform.

LeetCoding was a verb now, and the system which barely had 150 questions in 2016 had over a 1000 questions now, with weekly competitions, gamification (you can earn “LeetCoins” for solving problems) and even something which I’ve named the “cheating mode”, which is a compilation of interview questions that have been reportedly asked by the various companies.

Here is a screenshot of questions from the platform, showing interview questions tagged by company name:

For companies I’ve worked at, I’ve often gone through the list of all interview questions tagged for the company and found several of them on the internal interview question list (Some companies try to fight this by “banning” questions that are publicly known to have been asked).

The consequence of the “cheating mode” is that the interview bar ends up being raised — largely because the industry is flooded with self proclaimed “Prolific LeetCoders” who have solved over 1000 questions and are hoping to get interview questions that they’ve already solved before. Here is screenshot from the Blind app (an anonymous forum for Tech Employees), where we have a self proclaimed “Prolific LeetCoder” who has solved 1059 of the 1132 questions available on LeetCode:

I did a little thought experiment to see how long it would take me to solve 1059 questions while having a full time job. Based on my experience, it takes approximately 1–1.5 hours to attempt a solution and then look up/research alternative ways to solve the problem. So, solving 1059 questions would take 1059 hours. Assuming that you are trying to prepare while you have a full-time job, and that you dedicate 1.5 hours a day after work to LeetCoding, and never miss a single day, solving 1059 questions will take you a grand total of 1059 days, or approximately 2 years. 2 years?! Ok, WTF.

Before we get into what you can do to stay competitive, let me point out that trying to solve every single problem on LeetCode with the hope that you will get a question that you’ve already solved has a few issues:

1. It’s ethically very dubious. It’s like practicing for a test with leaked questions.
2. It just doesn’t scale. You probably don’t have that kind of time. And even if you did, it’s not the best use of your preparation time.
3. You’re probably not going to get an interview problem from that list , anyway. This is because what’s tagged is a sub-section of interview questions. And not every company asks LeetCode style questions.
4. Having practiced or seen an interview question might actually work against you. As the interviewers are becoming aware of the LeetCode Phenomenon, they are likely to tweak the problems to add/remove constraints which might throw you off.

Whether you love or hate LeetCode (or what the platform represents), the LeetCode Phenomenon is rampant and pervasive. A few months ago, when I screwed up the coding phone screen interview at Netflix (where I was asked a classic LeetCoding problem that I hadn’t seen before, and was able to solve, just not quickly enough), the empathetic Hiring Manager asked me to brush up on my LeetCoding and to take another shot at the interview in a month or so.

Companies are taking steps to fight the issue of leaked questions:

1. Some companies actively “ban” leaked questions.
2. Some companies are constantly creating new questions. At Square, for example, interviewers are asked to create their own interview questions (which are then approved by a committee to keep the bar consistent).
3. Then there is a set of companies that don’t ask LeetCode style problems at all (my heroes). Stripe and Shopify have a refreshing approach focused on solving problems that are a more accurate representation of the problems you’d be solving day to day (e.g. sorting a list of items based on a certain constraint). Interviews at Twitter (and certain teams at Netflix) tend to be team specific as well, and usually non LeetCode style. Lyft’s onsite consists of a laptop programming challenge which is open-book and you’re encouraged to use any public library.

All right, now what are you supposed to do to stay competitive with the Prolific LeetCoders? Surely, there is a better way than cramming 1059 problems? I cover that my follow-up article — Be Agile, not Prolific.

Follow me on Medium to be notified whenever I publish a new article.

The LeetCode Phenomena was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.