Covering Edge Cases

The tactics are covered in the doc linked above, so this summary will focus on the "meta" context behind this part and additional commentary:

• You should always at least try to cover all the edge cases when building out a product, even if you're a small startup.
  • If you're at Big Tech in particular, you absolutely need to have amazing coverage on edge cases as even an issue affecting just 1% of users could be breaking the experience for 10 million+ people.
• A lot of edge cases are quite easy to cover and are low-hanging fruit. Bad engineers will be lazy and ignore these, supposedly in the name of velocity.
  • Example: You have a login form that takes in email. Instead of no-oping, throwing a generic error, or letting them login with an invalid email, validate the email upon submission and show an error message if it's invalid. This will almost always be a 5-10 minute change.
• There's many "playbooks" of edge cases, so coming up with edge cases isn't rocket science - It's largely a solved problem. Here are some examples:
  • Generic edge cases that apply to any user input:
    • Input is blank
    • Input is overly long
    • Input is very strong
  • Generic edge cases that apply to any content collection:
    • No content
    • A lot of content
    • Content fetch fails
• Being very diligent around edge cases is also crucial for interviews, both DSA and system design, and is often how Big Tech interviewers differentiate the great candidates from the mediocre ones.

You can find the full system design doc here - Feel free to use it as a template for when you're designing systems at your job!