Python for coding interviews

Why Python is a strong default choice

Most coding interviews do not grade language choice, and Python is the most commonly picked language for a practical reason: its syntax overhead is low enough that the code on the whiteboard or editor looks close to the pseudocode in your head. A hash map is a `dict` literal, a set is a `set` literal, and slicing a list needs no boilerplate — which means more of the interview's 30-40 minutes goes to the algorithm and the narration around it, and less to fighting syntax under pressure. That advantage disappears the moment the interviewer's question specifically probes something Python abstracts away (manual memory layout, pointer arithmetic) — rare in most loops, but worth checking if the role is systems-adjacent.

Idioms interviewers expect

Writing idiomatic Python is a small, cheap signal of fluency that compounds across a 30-minute interview. A few worth having genuinely automatic rather than looked-up mid-interview:

# Counting occurrences — idiomatic, not a manual loop with a dict.get default
from collections import Counter
counts = Counter(nums)

# Grouping — defaultdict avoids "if key not in dict" boilerplate
from collections import defaultdict
groups = defaultdict(list)
for word in words:
    groups[key(word)].append(word)

# Enumerate instead of range(len(...))
for i, value in enumerate(nums):
    ...

# Unpacking instead of indexing into a returned pair
first, second = divmod(a, b)

// The direct analogues, for comparison — see /interview-prep/javascript
const counts = new Map();
for (const n of nums) counts.set(n, (counts.get(n) ?? 0) + 1);

const groups = new Map();
for (const word of words) {
  const k = key(word);
  if (!groups.has(k)) groups.set(k, []);
  groups.get(k).push(word);
}

nums.forEach((value, i) => { /* ... */ });

None of these change a solution's correctness or complexity — they change how quickly and cleanly you write it, which matters directly under a time limit.

Standard library complexity gotchas

A complexity claim stated confidently but wrong is worse than not stating one, because it signals you have not actually reasoned about it. A few Python-specific facts worth knowing cold:

• x in some_list is O(n); x in some_set or x in some_dict is O(1) average case. Using a list where membership testing matters is a common, easy-to-miss complexity bug.
• list.pop(0) is O(n) — it shifts every remaining element. For queue-like behavior, use collections.deque, which gives O(1) popleft().
• String concatenation in a loop (s += char) is O(n) per operation in the worst case due to immutability, making a naive loop O(n²) overall; prefer building a list and ''.join(...) at the end.
• sorted() is O(n log n) — worth stating explicitly when it appears in your solution's overall complexity, since it is easy to silently forget it dominates an otherwise O(n) pass.

Common pitfalls

• Mutable default arguments. def f(acc=[]): reuses the SAME list object across every call with no argument passed — a classic Python trap that, if it surfaces in your solution, reads as a real gap rather than a typo. Use None and initialize inside the function body instead.
• Off-by-one in slicing. nums[i:j] is half-open (includes i, excludes j) — state this explicitly when it matters for a boundary condition rather than assuming the interviewer will infer your intent from the code alone.
• Late-binding closures in loops. A lambda or nested function capturing a loop variable captures the variable, not its value at creation time — all closures created in the loop see the loop's FINAL value. Rare in DSA problems, but a real trap if a solution builds a list of callbacks.

Narrating Python code out loud

Python's concise syntax cuts both ways during an interview: a dense one-liner (a list comprehension with a nested conditional, a chained `sorted(..., key=lambda x: (...))`) can look impressive on screen and simultaneously read as opaque if you write it silently. The stronger habit is narrating the intent before or while typing dense syntax — "I'm going to sort by the pair (frequency descending, value ascending) so ties break consistently" — so the interviewer is following your reasoning, not reverse-engineering your code. See Thinking Out Loud for the general version of this skill, independent of language.