Python for Coding Interviews: It's 30x Slower. Your Interviewer Doesn't Care.

You've heard it. Maybe you've felt it: the creeping guilt of using Python for coding interviews while the candidate in the next virtual room is presumably writing blazing C++. They have a keybinding for std::priority_queue. You just type words.

Python is 30x slower than C++. That's a real number from a real USENIX study. Surely that matters.

It mostly doesn't. Here's why, and where the edge cases actually live.

What "30x Slower" Actually Means

The USENIX ATC '22 paper on managed language runtimes found CPython runs applications 29.5x slower on average than equivalent C++ code. That's a weighted average across six real-world applications covering compute intensity, memory access patterns, network I/O, and concurrency. Legitimate benchmark.

But look at what it's measuring: applications. Full programs that spend thousands of lines doing things in Python loops. The gap widens when your code is tight integer arithmetic in a hot loop. It narrows, sometimes to nothing, when the work is delegated to libraries written in C.

CPython's slowness is about interpreter dispatch cost per bytecode instruction. Every Python operation, even x + 1, goes through the interpreter loop: load the object, check its type, look up the __add__ method, call it, allocate the result. That overhead is real. But it only applies to code you write in Python.

When you call sorted(arr), CPython hands control directly to Timsort implemented in C. When you call Counter(s), the hash table operations run in C. When you call heapq.heappush(h, x), that's C. The experienced Python interviewee writes Python control flow around C-speed operations. The interpreter is the frame. The work is C.

Your Interviewer Is Not Running a Benchmark

In an actual coding interview at Google, Meta, or Amazon, no one is timing your function's wall-clock execution. Your interviewer is typing notes in a Google Doc. They're watching whether you think out loud. They're definitely not pulling up a profiler.

The "does it run in time?" question is answered by you, verbally, when you explain the time complexity. Big-O is the language of interviews. An O(n log n) solution in Python and an O(n log n) solution in C++ score identically on the algorithm dimension.

What you get penalized for is writing an O(n²) solution because you were fumbling with Java's PriorityQueue syntax instead of just typing heapq.heappush. The language that lets you think fastest wins. For most engineers, that's Python.

The interviewing.io dataset consistently shows that algorithm score is far more predictive of hiring outcomes than any language choice. Fluency in your chosen language matters more than the language itself. If you can't remember whether HashMap in Java takes <K, V> or <V, K> under pressure, switch.

Python is slow meme - but nobody panic

Every year, someone "discovers" Python is slow. Every year, Python developers nod and continue shipping.

Three Traps That Change Complexity Class

Python's advantages are real, but there are three places where the language will genuinely hurt you if you aren't ready.

The recursion limit. CPython defaults to 1000 frames. If you write a recursive DFS on a path graph with 10,000 nodes, you get a RecursionError. Not a wrong answer. A crash.

Python has no tail-call optimization (Guido explicitly rejected it, on the grounds that readable tracebacks matter more), so every recursive call consumes a real OS stack frame. Setting sys.setrecursionlimit(200_000) doesn't give you 200,000 frames safely. It just postpones the crash until the OS says no.

import sys
sys.setrecursionlimit(10_000)  # safe for most interview tree/graph problems

The cleaner fix for DFS on large graphs is an iterative stack. Same algorithm, stack lives on the heap instead of the call stack, and you can grow it to millions of entries without issue. If you use Python for interviews, have that conversion ready.

list.pop(0) is O(n). This one bites hard in BFS problems. A Python list is a contiguous array. Removing the first element shifts every remaining element one slot left. For a list of a million items, that's a million copies.

# This is O(n) per pop. Your BFS is secretly O(n²).
queue = []
queue.append(node)
next_node = queue.pop(0)  # bad

# This is O(1) per operation.
from collections import deque
queue = deque()
queue.append(node)
next_node = queue.popleft()  # correct

collections.deque is implemented as a doubly-linked list of fixed-length blocks. popleft() is O(1). The practical performance difference is roughly 40,000x for large queues. 40,000x. That's not a rounding error. That changes the complexity class of your BFS from O(n log n) to O(n²), and in an interview you will not notice until the interviewer says "what's the time complexity?" and you stare into the middle distance.

The max-heap negation trap. Python's heapq only implements a min-heap. The standard idiom is to negate values to simulate a max-heap.

import heapq

max_heap = []
heapq.heappush(max_heap, -5)
heapq.heappush(max_heap, -3)
heapq.heappush(max_heap, -7)

largest = -heapq.heappop(max_heap)  # 7

This works. But float('inf') negated is float('-inf'), which sorts as the smallest value rather than the largest. In most interview problems you'll never hit this. Know it exists.

Big Integers Are Slower Than They Look

Python integers are arbitrary precision. Every integer is a heap-allocated object stored as an array of 30-bit digits. CPython pre-allocates -5 to 256 as singletons, so small integer arithmetic is cheap. Outside that range, each arithmetic operation allocates a new object.

For most problems this doesn't matter. Where it bites is explicit large-number arithmetic: factorial(1000), combinatorics with huge binomial coefficients, anything involving numbers with hundreds of digits. If a problem says "return the result modulo 10^9 + 7", apply the modulus at each step rather than computing the full intermediate value.

result = 1
for i in range(1, 1001):
    result = (result * i) % (10**9 + 7)

When Python Loses in a Coding Interview

At n = 10^7 or above, a Python O(n) solution may be borderline or failing on a judge with a 1-2 second time limit. At n = 10^6, O(n) is usually fine. At n = 10^8, even O(n) in Python is almost certainly too slow.

FAANG coding interviews rarely have this problem. The problems are designed to be solvable in 45 minutes and evaluated for algorithmic thinking. A graph traversal problem with n = 10^5 will run fine in Python. Nobody at Google is sitting there going "hmm, would this have been faster in Rust?"

Competitive programming (Codeforces, AtCoder) is different. Constraints are set with C++ as the baseline, and Python contestants commonly get 4-5x extra time as an acknowledgment of the gap. Use PyPy there. LeetCode supports it, and it's typically 10-50x faster than CPython for loop-heavy code thanks to JIT compilation.

If a problem's constraints look unusual (n = 10^7 explicitly stated), ask the interviewer which language is expected. That's a legitimate clarifying question, not a sign of weakness.

The Standard Library Is Your Real Advantage

While other candidates are debugging whether their Java LinkedList has O(1) add-at-tail (spoiler: it does, but they're going to spend four minutes convincing themselves), you're done.

Python - it may be slow but it's useful

The standard library is the interview equivalent of bringing a cheat sheet that's completely legal.

collections.Counter(s) builds a frequency map in one line, running in C
collections.defaultdict(list) eliminates every if key not in d guard
heapq.nlargest(k, arr) and heapq.nsmallest(k, arr) are O(n log k) and one line
bisect.bisect_left(arr, x) is binary search on a sorted list in one line
itertools.combinations(arr, k) and itertools.permutations(arr) enumerate correctly without you writing the backtracking

None of these are cheating. They're vocabulary. The interviewer cares that you knew the right data structure and algorithm. Reaching for heapq instead of re-implementing a priority queue from scratch shows exactly the judgment they're testing for.

SpaceComplexity does voice-based mock interviews with rubric scoring. If you're practicing Python solutions, run them out loud. Explaining why you chose deque over list is a scored dimension.

If You Do Hit a Limit

Three clean escalations, in order:

Write the iterative version. If your recursive DFS is about to exceed the recursion limit, say so, then write the iterative version with an explicit stack. This shows you understand the mechanics.
Set the limit explicitly and say why. "Python's default recursion limit is 1000. For a graph with up to 10^5 nodes I'd set this to 100,000 at the top." Demonstrates awareness without apologizing for the language.
Use sys.stdin.readline for judge environments. input() is noticeably slower because it does extra processing. In any contest submission: import sys; input = sys.stdin.readline. Same code, faster I/O.

The Short Version

Python is ~30x slower than C++ on CPU-bound loops. Your interviewer scores your algorithm, not your CPU cycles.
Python's built-ins are C. sorted, Counter, heapq, deque all bypass the interpreter. Write Python control flow around C-speed primitives.
Three real traps: default recursion limit of 1000 (fix with iterative DFS), list.pop(0) is O(n) (use deque.popleft()), max-heap negation breaks on infinities.
At n = 10^7 or above on a judge, Python can genuinely fail. Rare in FAANG-style interviews. Common in competitive programming.
The standard library is a legitimate interview advantage. Use it.

If you're still choosing your interview language, the analysis is in Best Language for Coding Interviews: Fluency Beats Features. And for understanding what your interviewer is actually scoring you on, What Your Interviewer Is Writing While You Think has the rubric breakdown.