The Startup
Published in

The Startup

Taking the Edge off of Edge Cases

Identifying Edge Cases in Algorithms and Applications

It's such a joyous feeling when you finally get your solution to an algorithm to work. Or when your web application correctly works the way you want it to. But then… someone asks the questions “but what if I tried to do this?”, “what would happen if we change this”, “how does your solution handle this?”

Edge cases are the worst!

What is an Edge Case?

An edge case (or sometimes called boundary case) is a problem that occurs at the extremes of your operating parameters. To expand that definition to explain how it's normally used in tech, an edge case is a situation (might be rare) where the inputs or outputs are out of the ordinary or for what was originally planned for. They may be unlikely but they can cause your system to fail, or provide incorrect results.

Basically, it's the opposite of your happy path. The happy path is usually the one you are on when starting to code. I want this and this to take me here and here. It's the path of least resistance. It's the ideal conditions for everything to work as it should. We like the happy path; we don't like the edge cases.

See Also: Corner Case

Why Live on The Edge?

So, why is it important to think about edge cases? Whether it's an application or simply an algorithm during a technical interview, thinking about edge cases will create a more robust end product.

It can be common in the software industry to get caught up working on the happy path, especially with additional time constraints or with newer developers. However, without consideration for edge cases, useability issues may arise. By keeping simple edge cases in mind you can return more correct results and handle errors gracefully.

Looking for the Edge

So how do we find these pesky edge cases? Well, unfortunately, the most efficient way to do it is to just think of them. Sorry, no shortcuts here. Identifying edge cases is still largely done by humans. It's a large part of designing self-driving cars and one of their major hurdles. This article explains further.

But how can you learn to expect the unexpected? It requires high attention to detail and almost a malicious mindset. You are looking for ways to make the code fail, and find all the gaps. But don't worry, it comes with practice. After training your brain, you will begin to see patterns on where these edge cases lie. Additionally, you will never be able to find ALL the edge cases… there could be an infinite number of them!

When do we look for these edge cases? During both the development/ planning phase and during the testing phase.

Planning properly during the development phase can help identify many important edge cases. Start by thinking about ways the code could fail and why. Make sure you understand the programming language and algorithms used. What are their weaknesses? Think on the extremes, think on different scales, different media, different use cases, think outside the box!

The second most crucial step for identifying edge cases is the testing phase. Both unit-testing and user-testing can be helpful here. Simply writing out good unit tests will force you to start thinking about edge cases. And getting other users to start playing around with the code can help catch some gaps. Users can be very unpredictable sometimes…

Technical Interviews/ Algorithms

Coming up with edge cases while trying to complete a technical interview can be challenging, but it will most definitely impress your interviewee. Remember to ask lots of clarifying questions and always step through your code with examples and edge cases. Make sure your solution holds up to the edge cases considered. The following list shows some types, data structures and scenarios, and corresponding edge cases to consider:


  • String: null, empty string, length 1, spaces, upper/lower cases, all same character, long string, Unicode string (special characters), odd/even length string
  • Numbers: 0, dividing by zero, leading 0s, Min/MaxInt, negative/positive
  • Sort algorithm: empty input, null input, 1 element, very long input, duplicate elements (sort on a second condition?), odd/even length input
  • Linked List/Tree: null values for head/root
  • Stack/Queue: removing elements from empty stack/queue
  • Loops: while loops running forever (properly incre./decre. pointers)
  • Web Apps: file upload too large, the user entered too much or too little content, desktop vs mobile elements, support on older technologies
  • Generally: empty inputs, one element inputs, super long inputs, null values, unexpected data structures or types, trash in a collection, inputs violating assumed invariants, are we guaranteed to find a solution? what happens if there are multiple solutions?

How to Fix Edge Cases? Maybe Just Don’t.

So now how do we fix the edge cases we just identified? If you can’t restructure your logic so that there is no edge case, you have two options: prevention (limit the boundaries) or support the scenario.

You do not have to and nor should you support every edge case. There is an infinite number of scenarios you would run into. Edge cases are impossible to completely avoid. So keep it simple! For example, if you aren't releasing your product internationally, then don't worry yet about translating to different languages.

Especially early in the design, your focus should remain on the happy path as not to get too distracted. Focus on your core functionalities! Every time you support a new edge case, chances are you are adding complexity and bugs. So it's up to you to prioritize the cases with higher risks.


Get smarter at building your thing. Follow to join The Startup’s +8 million monthly readers & +756K followers.

Recommended from Medium

4 factors to consider before outsourcing business development software

Create Advanced Tables in WordPress


Beginning of 60 #LOCAD (Lines of Code A Day) Challenge! (Code example given)

How to build a dashboard with Bootstrap 4 from scratch (Part 2)

Pointers in Python v.s. Pointers in Golang

Serverless CI/CD Solutions Example on AWS (CodePipeline-CodeBuild)

Type 2 SCD — 2 Perspectives

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Sara Khandaker

Sara Khandaker

I love seafood, exploring new cities, board games and learning to love to code.

More from Medium

Dismantling technical debts in the data layer and their impact on growth and profitability

An intro to codegen with AWS Smithy — Setup

Photo by

Job interview for beginners: The money question