How Constraints Changed the Way I Think About Algorithms

.

The problem itself isn't particularly difficult:

The first constraint immediately tells me that an O(n²) solution is probably acceptable.

After all:

Suddenly there are only 101 possible values. That changes the conversation entirely. Instead of thinking only about sorting, I can start thinking about frequency arrays, counting sort, buckets, and other approaches that take advantage of the limited value range.

The more problems I solve, the more I realize that constraints are often the interviewer's way of nudging you toward a particular solution. They're not just there to define the input. They're there to provide clues.

Consider a few other examples:

Now I'm immediately suspicious of nested loops. I start thinking about hash maps, sorting, binary search, sliding windows, and other approaches that can run in O(n log n) or O(n).

This isn’t a hard rule. It’s a heuristic. A way to quickly determine whether a particular approach is even worth considering. When I see a problem today, I can often eliminate entire categories of solutions before writing a single line of code. That’s a huge advantage during interviews.

Where cThink Fits Into All of This

What's interesting is that this way of thinking didn't come entirely from interview preparation. It came from teaching.

Throughout my career, I've had the opportunity to teach aspiring developers at organizations like The Knowledge House and Change Food for Good. One thing I noticed over and over again was that many students struggled not because they lacked intelligence, but because they approached learning in a way that didn't align with how their brains processed information.

Some learners needed diagrams. Others needed hands-on exercises. Some needed to talk through concepts. Others needed to physically build something before it clicked.

Those observations eventually inspired me to start building , has become another extension of that journey. Creating videos forces me to slow down and explain my thinking. It's easy to convince yourself that you understand an algorithm when you're watching someone else solve it. It's much harder when you have to teach it.

Some of my biggest breakthroughs have happened while recording content and realizing that I couldn't clearly explain why a solution worked. Teaching exposes gaps in understanding And filling those gaps has made me a stronger engineer.

The Bigger Lesson

Today, when I see a coding challenge, I don't immediately think about algorithms.

• I think about constraints.
  - I think about tradeoffs.
  - I think about communication.

Most importantly, I think about learning. The cheat sheet I recently created for mapping input sizes to target complexities isn't just a reference guide. It's a reminder of how much my thinking has evolved. What started as interview preparation has become something bigger.

It's influenced how I teach, how I build software, how I create content, and how I'm designing cThink and if there's one lesson I've learned through all of it, it's this:

Great problem solvers don't start with answers.

They start with questions.