🎯 Interview Complexity Estimator
Tick the techniques your solution uses and pick the input-size regime to get a quick, rules-based read on the expected time and space complexity — and whether the problem sits in Easy, Medium, or Hard territory.
🧠 Estimate Time & Space
🎯 Estimated complexity
The estimate is the asymptotically dominant time and space across the techniques you selected — a rules-based read, not a substitute for analysing your specific code.
What is an Interview Complexity Estimator?
It turns the pattern-matching that experienced engineers do in their heads into an explicit, deterministic table. Rather than guessing, you describe the moving parts of your approach — the loops, the sort, the hash map, the recursion — and the estimator combines them into the dominant time and space complexity, then reads off a difficulty band.
It is built for interview prep and quick self-checks: use it to confirm the complexity you would state out loud, to compare two candidate approaches before you commit to coding one, and to recognise when a pattern like backtracking or a nested loop is about to blow up on a large input. Because it runs off a fixed rules table with no AI or network, the answers are consistent and explainable.
❓ Frequently Asked Questions
How does the estimator decide the complexity?
It uses a fixed, documented rules table. Each technique — a single pass, nested loops, sorting, hashing, binary search, divide and conquer, dynamic programming, backtracking, and so on — maps to a representative time and space growth class. When you pick several, the estimate is the asymptotically dominant time and the dominant space among them. There is no AI and no network call.
Is this a substitute for analysing my actual code?
No. It is a fast sanity check and a learning aid that reflects the typical complexity of each pattern. Your real code can differ — an early exit, a bounded inner loop, or a clever data structure can change the exponent — so always confirm against the specifics of your implementation.
Why does the difficulty change with input size?
The difficulty read is driven by the dominant time class, but the input-size regime nudges it: an O(n²) solution is a reasonable Medium for moderate inputs, yet becomes a Hard problem when n reaches the millions, because quadratic work no longer finishes in time. Selecting the large regime reflects that pressure.
Which techniques map to which complexity?
Single pass, two pointers, hashing, and graph traversal are linear; binary search is logarithmic; sorting and halving divide-and-conquer are linearithmic; nested loops and 2-D dynamic programming are quadratic; triple loops are cubic; backtracking over subsets is exponential; and generating permutations is factorial. Space follows the same table — for example a DP table is O(n²) space.