Before getting into how to prompt AI about this, it helps to have a quick mental map of the usual suspects. Most problems you'll run into fall into one of these buckets.

Constant time, O(1): The code does the same amount of work no matter how big the input is. Grabbing an item from an array by index is the classic example.

public int getFirst(int[] arr) {
    return arr[0]; // Doesn't matter if arr has 5 or 5 million items
}

Space here is also O(1), since we're not creating anything that grows with input size.

Logarithmic time, O(log n): The work cuts down by half each step, so it barely grows even as input gets huge. Binary search is the textbook case.

public int binarySearch(int[] arr, int target) {
    int low = 0, high = arr.length - 1;
    while (low <= high) {
        int mid = (low + high) / 2;
        if (arr[mid] == target) return mid;
        else if (arr[mid] < target) low = mid + 1;
        else high = mid - 1;
    }
    return -1;
}

Time is O(log n), space is O(1) since we're just tracking a few variables, not creating new structures.

Linear time, O(n): One pass through the input, doing a fixed amount of work per item. Most simple loops fall here.

public int sumArray(int[] arr) {
    int sum = 0;
    for (int num : arr) {
        sum += num;
    }
    return sum;
}

Time is O(n), space is O(1), since we're only using one extra variable regardless of array size.

Linearithmic time, O(n log n): Common in efficient sorting algorithms, where you split the problem repeatedly and still touch every element.

public void mergeSort(int[] arr, int left, int right) {
    if (left < right) {
        int mid = (left + right) / 2;
        mergeSort(arr, left, mid);
        mergeSort(arr, mid + 1, right);
        merge(arr, left, mid, right);
    }
}

Time is O(n log n), and space is O(n) because merge sort needs extra arrays to merge things back together.

Quadratic time, O(n²): Usually shows up when you've got a loop inside another loop, each one running roughly n times.

public boolean hasDuplicates(int[] arr) {
    for (int i = 0; i < arr.length; i++) {
        for (int j = i + 1; j < arr.length; j++) {
            if (arr[i] == arr[j]) return true;
        }
    }
    return false;
}

Time is O(n²), space is O(1), since nothing extra is being stored, just compared.

Exponential time, O(2ⁿ): This is the one that gets scary fast. Every extra input roughly doubles the work. Naive recursive Fibonacci is the go-to example.

public int fibonacci(int n) {
    if (n <= 1) return n;
    return fibonacci(n - 1) + fibonacci(n - 2);
}

Time is O(2^n) because every call branches into two more calls. Space is O(n), though, since that only tracks how deep the recursion goes, not how many total calls happen.

Here's all of that side by side, since seeing it in one place tends to make the differences click faster:
 

Complexity	Example	Time	Space
O(1)	Access array by index	Constant	Constant
O(log n)	Binary search	Logarithmic	Constant
O(n)	Sum of array	Linear	Constant
O(n log n)	Merge sort	Linearithmic	Linear
O(n²)	Nested loop duplicate check	Quadratic	Constant
O(2n)	Naive recursive Fibonacci	Exponential	Linear

Ask It to Explain the Growth, Not Just Name It

A lot of people ask AI "what's the Big-O of this" and stop there. That gets you a label, but a label doesn't teach you anything. What actually helps is asking it to show how the runtime grows as input size grows, so the notation stops feeling abstract.

• Ask for actual numbers: Have it compare runtime at, say, n=10 versus n=10,000. Watching the gap grow (or not) makes the notation feel real instead of theoretical.
• Ask what's causing the growth: Is it the loop, the recursion, a hidden call inside a library function? Naming the actual cause matters more than memorizing the label.
• Ask it to compare two complexities side by side: Seeing O(n) next to O(n²) on the same input size makes the difference obvious in a way the notation alone never does.

Try something like:

"Here's my nested loop function in Java. Don't just tell me it's O(n²), show me how the number of operations changes if n is 10 versus 1,000 versus 100,000, and explain exactly which part of the code is causing that growth."

That kind of answer sticks a lot better than a one-line "this is quadratic."

Ask It to Compare Your Code to a Faster Version

One of the best ways to actually understand why something is slow is to see it standing next to something faster that solves the same problem. AI is great at generating that comparison on demand instead of you having to hunt one down.

• Give it your working code first: Something you already wrote, even if it's not optimized. This grounds the whole conversation in something real.
• Ask for a faster version of the exact same problem: Not a generic example, your actual function rewritten.
• Ask what specifically changed: A data structure swap, cutting out a nested loop, memoizing repeated work, whatever it is, name the actual change.

Here's an example:

"Here's my Java function that checks for duplicates using nested loops. Rewrite it using a HashSet, and explain exactly what changed in terms of both time and space complexity."

Seeing your own slow version next to a fixed one, with the reasoning spelled out, teaches you the pattern in a way that sticks around for the next problem too.

Ask It to Explain Space Complexity Separately

Time complexity gets all the attention, but space complexity trips people up just as often, especially with recursive code where it's easy to forget that the call stack itself takes up memory. It's worth asking about this on its own instead of lumping it in as an afterthought.

• Ask what's actually being stored: Extra arrays, hash maps, recursive call stacks- all of it counts, and it's easy to miss the ones that aren't obvious.
• Ask about recursion specifically: Recursive functions often have sneaky space costs tied to how deep the recursion goes, not how much output they produce.
• Ask if space can be traded for time, or the other way around: A lot of optimizations are really just shifting the cost from one to the other, and it helps to see that trade-off explicitly.

Try a prompt like:

"For this recursive Java function, explain the space complexity specifically. Walk me through what's happening on the call stack, and tell me if there's a way to reduce the space usage even if it means the code runs a bit slower."

Treating space as its own question, rather than a footnote after time complexity, is usually where people finally stop overlooking it.

Ask for a Real-World Sense of "Is This Fast Enough"

Knowing the Big-O label doesn't automatically tell you whether your code will actually run fine in production, or fall over the moment real users show up. This is where AI can genuinely help connect the theory to something practical.

• Give it a realistic input size: "This runs on lists with up to 50,000 items" is a lot more useful than talking about complexity in the abstract.
• Ask if the complexity is actually a problem here: Sometimes O(n²) is completely fine if n is always small, and it helps to hear that plainly instead of assuming worse is always bad.
• Ask what would break first if input size grew a lot: This tells you where to focus your optimization energy instead of guessing.

Here's an example:

"This Java function runs on lists that are usually under 1,000 items but could occasionally hit 100,000. Given its O(n²) complexity, is this actually going to be a problem in practice, and if so, at roughly what input size?"

This turns complexity from a purely academic exercise into something you can actually make a decision with.

Conclusion

Look, Big-O sounds way scarier than it actually is. It's usually taught like something you're supposed to memorize and recite, not something you're supposed to actually get. But once you start asking AI to show you real numbers instead of just a label, point out exactly what part of your code is causing the slowdown, and put your version next to a faster one so you can see the difference yourself, it just... clicks. It stops being a term you nod along to and starts being something you can genuinely reason through. And honestly, that's the whole point. Not being able to say "O(n log n)" on command, but actually knowing why it matters, and just as importantly, when it really doesn't.

Frequently Asked Questions (FAQs)

1. Why does space complexity feel harder to understand than time complexity?

Mostly because it's less visible. Time complexity shows up as "this runs slow," but space complexity is often hidden in things like recursive call stacks or intermediate data structures that aren't obvious just from reading the code.

2. Can two pieces of code with the same Big-O actually perform very differently?

Yes, definitely. Big-O ignores constant factors, so two O(n) functions can have very different real-world speeds depending on what's happening inside each iteration.

3.Should I worry about O(n²) code if my input is always small?

Not really. Complexity matters most as input size grows. If your input is reliably small, an O(n²) solution can be completely fine and not worth the extra complexity of optimizing.

4. Is exponential time always something to avoid?

In most real applications, yes, since it becomes unusable very quickly as input grows. That said, some problems genuinely don't have a faster known solution, so it's not always avoidable.

5. How can I actually test if AI's complexity explanation is correct?

Time your own code with a few different input sizes and see if the growth pattern actually matches what it claimed. That's the most reliable way to confirm an explanation instead of just trusting it outright.