How to Never Ever Have a Code Limit

Have you ever noticed that some people can look at a problem and instantly know which algorithm to use? It almost feels like magic—but it’s not! Today, we’ll talk about how you can do it too.

The secret? Pay attention to constraints.

Algorithms aren’t like superheroes or villains—they’re just tools. Whether they save the day or cause disaster depends entirely on the constrains. Nobody would be mad at you if you sort 10-items array even with exponential sort. Once you know how to use constrains to your advantage, you will know exactly where you can slack, and there you should try your harderst.

One Number to Remember: 10⁚

There is a good rule of thumb for competitive programming: computers can handle ~ 10⁚ basic operations per second.

Modern CPUs run at GHz speeds, meaning they can process billions of instructions per second. The prefix "Giga" literally means 10⁚.

Keep in mind, that real-world performance varies depending on factors like cache efficiency, memory access, and CPU architecture.

But number 10⁚ is good enough for back-of-envelope estimations.

This is roughly the number of basic operations your process can handle per second.

Estimating Running Time Using Constraints

Let’s apply this idea to some coding problems.

Example 1: Two Sum

Problem Statement

Given an array nums and an integer target, return the indices of two numbers that add up to target.

Constraints:

  • 2 ≤ nums.length ≤ 10⁴

Before even thinking about an algorithm, check the constraints. The input size is at most 10⁴, and most coding platforms allow 1 second to run the solution.

A quadratic solution (O(n²)) would require ~(10⁴)² = 10⁸ operations, which is less than 10⁚, meaning it should pass just fine.

That’s exactly why this problem is easy—even a simple brute-force approach is fast enough!

Example 2: Longest Substring Without Repeating Characters

Problem Statement

Given a string s, find the length of the longest substring without duplicate characters.

Constraints:

  • 0 ≤ s.length ≤ 5 × 10⁴

If we try a quadratic algorithm, we’d have to do (5 × 10⁴)² = 25 × 10⁸ = 2.5 × 10⁹ operations. Since our computer can handle 10⁹ operations per second, this would take 2.5 seconds—too slow!

That means a quadratic approach is too slow for this problem. We need something better, like an O(n log n) or O(n) solution:

5 × 10⁴ × log(5 × 10⁴) ≈ 8 × 10⁵

Since 8 × 10⁵ is way less than 10⁹, an optimized algorithm will run in time. This is why the problem is medium—brute force won’t cut it.

How to Use This in a Coding Interview

Coding Assessments

This technique is super useful for automated coding assessments, where you need to impress the system, not a human. If your code times out, knowing how to estimate complexity will help you quickly adjust your approach.

Live Interviews: Always Ask About Constraints

Some interviewers intentionally leave constraints vague to see if you ask for them.

Be sure to enquire:

  • How large is the input?
  • How often will this function be called?

This helps you understand what matters most—should you optimize for time, space, or simplicity? With this mindset, you’ll make smarter design choices and impress interviewers.

To help you remember, here’s a fun video for you:

TL;DR

  1. Remember 10⁹—the number of operations per second your computer can handle.
  2. Check constraints first—they tell you what kind of algorithm will work.
  3. Estimate running time—use quick calculations to see if your approach will be too slow.
  4. Use this in interviews—ask about constraints to pick the best solution!

Master this, and you’ll never have to worry about time limits again!