Time Complexity —
Read the Big O straight off the code.
Every interviewer eventually asks "what's the time complexity of that?" — and being able to answer instantly, by reading the code's structure, is its own interview skill separate from writing the code itself. Watch operation counts accumulate on LearnBug as loops and recursive calls execute, and learn to read complexity like a habit, not a calculation.
What does "analyzing complexity" actually mean?
It means identifying how the number of basic operations grows as input size n grows, purely by examining the code's structure — no running required. A single loop over n items is O(n). A loop inside a loop, both over the same n items, is O(n²). A function that halves its input each call is O(log n) deep.
Why visualization helps
"Count the loops" is easy to say and easy to get wrong on real code, especially when loops call functions that have their own hidden loops. LearnBug can count actual operations as code runs, so you can verify your mental Big O analysis against the real, observed operation count instead of just trusting your read of the source.
Three questions to ask about any piece of code
How many times does each loop run?
A loop over the full input is n iterations. A loop that halves its range each time is log n iterations. A fixed-size loop (always 10 times, regardless of n) is O(1) — it doesn't scale with input.
Are loops nested, or sequential?
Nested loops multiply — a loop inside a loop, both O(n), gives O(n²). Sequential loops (one after another, not inside each other) add — two separate O(n) loops in a row is still O(n), not O(n²).
Does a recursive call spawn one call, or more than one?
One recursive call per frame (factorial) gives a call count proportional to recursion depth. Two calls per frame (naive Fibonacci) gives exponential growth — unless the subproblems are disjoint (merge sort), which stays O(n log n).
Interview questions about analyzing complexity
How do I analyze code that calls a built-in function inside a loop?
Account for the built-in's own complexity, not just "1 operation." x in some_list inside a loop is O(n) per check (list membership is linear), so a loop doing that n times is O(n²) total — even though it visually looks like "just one loop." The same check against a set or dict is O(1) per check, making the whole thing O(n).
What's the complexity of two separate loops, one after another?
They add, not multiply: O(n) + O(n) = O(2n), which simplifies to O(n) since constants are dropped in Big O notation. This is different from nested loops (one loop inside another), which multiply: O(n) × O(n) = O(n²).
How do I find the complexity of a recursive function?
Write its recurrence relation — T(n) in terms of smaller T(k) calls — then solve or recognize the pattern. T(n) = T(n-1) + O(1) (one smaller call, constant work) gives O(n). T(n) = 2·T(n/2) + O(n) (two half-size calls, linear combine step) gives O(n log n) — the exact shape of merge sort.
Does the size of the input inside a data structure matter, or just the number of elements?
Usually just the count — Big O treats individual comparisons/operations as O(1) unless stated otherwise (e.g. comparing very long strings has its own cost that's sometimes called out separately). For typical interview problems with small fixed-size elements (integers), element count is what drives the analysis.
What should I say out loud while deriving complexity in an interview?
Narrate the same three questions used above: "this loop runs n times," "this one is nested inside it so we multiply," "so this section is O(n²)." Interviewers are usually more interested in hearing correct reasoning than a fast final answer — showing the process is often more valuable than blurting out "O(n log n)" with no justification.
Same problem, two complexities
def has_duplicate(arr):
seen = set()
for x in arr: # single loop -> O(n)
if x in seen: # set lookup -> O(1)
return True
seen.add(x)
return False
def has_duplicate_slow(arr):
for i in range(len(arr)): # outer loop -> O(n)
for j in range(i + 1, len(arr)): # inner loop -> O(n)
if arr[i] == arr[j]: # nested -> O(n²) total
return True
return FalseQuick Reference
Watch the operation count confirm your analysis
Paste your code into LearnBug and verify your Big O reasoning against real execution.