How Constraints Changed the Way I Think About Algorithms

Over the past couple of years, I've spent a lot of time preparing for software engineering interviews. Like many developers, I started my Data Structures and Algorithms journey focused on memorization. I wanted to know every pattern, every trick, every LeetCode solution. If a problem looked like Two Pointers, I'd use Two Pointers. If it looked like Dynamic Programming, I'd try Dynamic Programming.

What I didn't realize at the time was that strong problem solvers aren't just pattern matchers. They're detectives. They look for clues before they write a single line of code.

One of the biggest shifts in my thinking came when I started paying much closer attention to constraints.

Constraints Are Hidden Hints

One of the biggest breakthroughs in my interview preparation came when I started treating constraints as clues rather than restrictions. Recently, I was working through a LeetCode problem called How Many Numbers Are Smaller Than the Current Number.

The problem itself isn't particularly difficult:

For each number, return how many numbers in the array are smaller than it. At first glance, it's easy to start thinking about sorting, hash maps, or brute-force comparisons. But before thinking about the algorithm, I looked at the constraints:

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

After all:

That's not a lot of operations for a modern computer. But it was the second constraint that caught my attention:

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:

This often suggests brute force, recursion, or backtracking may be acceptable.

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).

That's not even a numeric constraint, but it's still a clue. Suddenly binary search and two-pointer techniques become much more attractive.

Instead of asking:

"What algorithm should I use?"

I now ask:

"What are the constraints trying to tell me?"

That simple mindset shift has improved my problem-solving more than memorizing another algorithm pattern.

My Constraint Cheat Sheet

As I practiced more problems, I started building a mental model for matching constraints to target complexities. Something like:

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 cThink, a multisensory learning platform based on the D.A.B. framework:

Draw it. Act it. Build it.

The goal is simple: engage multiple learning styles to improve retention and understanding. The more I work on cThink, the more I realize that my own approach to algorithms has become multisensory as well. When solving problems today, I don't just code.

• I draw arrays.
  - I sketch hash maps.
  - I talk through examples.
  - I write plans.
  - I walk through test cases.
  - I build solutions incrementally.

Without realizing it, I've been applying many of the same learning principles that cThink is built around.

YouTube, Teaching, and Learning in Public

My YouTube channel, Heriberto Codes, 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.