Python in Interviews

"A language that doesn't affect the way you think about programming, is not worth knowing." — Alan J. Perlis, "Epigrams on Programming" (ACM SIGPLAN Notices, 1982)

Perlis was making a point about language design. Interviewers use the inverse of it as a diagnostic, usually without saying so: they are checking whether Python has affected the way you think, or whether you are writing some other language in Python's syntax.

That distinction is the single most reliable signal in a Python interview, and it is visible within about ninety seconds. Two candidates solve the same problem correctly. One writes for i in range(len(items)): and builds a result with result = result + [x]; the other writes for item in items: and reaches for a comprehension, a Counter, or zip. Both answers work. Only one of them says I have internalised this language, and that is what the interviewer is grading — because correctness is table stakes, and how you got there predicts what you will be like to work with for the next two years.

The seven parts behind you were about understanding Python. Part VIII is about demonstrating it under time pressure, to someone forming a judgement quickly with incomplete information. That is a different skill, it is learnable, and this chapter is about what is actually being measured before we get to the questions themselves.

Language-shaped code versus translated code

Here is the ninety-second signal, made concrete.

Both pass the test. The second one also communicates that the candidate knows Counter exists, that str.split() with no argument handles runs of whitespace, that most_common is already sorted, and — most tellingly — that reaching for a standard-library data structure is the first move rather than the last.

The translated version additionally advertises three habits an interviewer will extrapolate from: iterating by index over a sequence, comparing to False with ==, and hand-rolling a sort that is neither stable nor correct on ties. None is a firing offence. All of them together say this person will write Java in our Python codebase, and that is a real, expensive prediction.

The lesson is not "memorise Counter". It is that the standard library is the vocabulary of the language, and fluency means reaching for it reflexively.

The formats, and what each one can see

Different formats sample different things, and knowing which one you are in tells you what to emphasise.

Two practical consequences. In an async or automated screen — increasingly the first round, and the format micro1 and similar platforms use — nobody is there to be impressed by your reasoning. Correctness, speed and clean syntax are everything, and the recovery move of explaining your thinking is unavailable. In a live round the opposite holds: a candidate who talks through a partially wrong approach and adjusts on a hint routinely beats a silent candidate who produces the right answer, because responsiveness to feedback is the thing being sampled.

The take-home is the format people most often misjudge. Four hours of work is not being graded on whether the feature works — it is being graded on everything Part VI and Part VII covered: layout, tests, error handling, a README that says what you chose and why.

The algorithm question is also a Python question

Interviewers rarely ask a pure algorithm question. They ask one where the Python matters.

The algorithmic insight — trade space for time with a hash map — is half the question. The other half is Python-specific and gets read closely: enumerate rather than range(len(...)), in on a dict rather than a list (Part II's cost table, and the difference between O(1) and O(n)), and a single pass that stores as it goes rather than pre-building the dictionary.

Notice the case list too. Duplicates, negatives, no answer and empty input are exactly the four an interviewer adds after you say you are done, and volunteering them first is worth more than the solution — it says you have shipped code that other people ran.

Say the complexity before you are asked

State the complexity of your own solution before the interviewer asks, and state the trade — "O(n) time, O(n) extra space; if memory were constrained I would sort first and scan, which is O(n log n) time and O(1) extra." That single sentence demonstrates that you know there is a trade, which is the thing being tested. Waiting to be asked converts a demonstration of judgement into a comprehension check.

The idiom vocabulary interviewers listen for

None of these is clever. That is the point — they are the ordinary way to write Python, and an interviewer notices their absence far more than their presence. Reaching for enumerate is unremarkable; reaching for range(len(items)) is a data point.

If you want one thing to practise before an interview, it is these eight until they are automatic under pressure, because pressure is precisely when people revert to whatever they learned first.

Thinking aloud, concretely

Silence is the most common self-inflicted wound in a live round. The fix is a script.

Two beats deserve emphasis because they are the ones people skip. Clarify first — asking whether the input can be empty is not stalling, it is the single most reliable signal that you have written code other people depended on. And verify by hand before claiming you are done, walking one example through your own code out loud; interviewers consistently rate a candidate who finds their own bug above one whose code happened to work.

The other habit worth building: when you do not know something, say "I would check the docs for the exact signature — I believe it is sorted(items, key=...)". Confidently inventing an API is far worse than admitting a lookup, because the interviewer now has to discount everything else you said confidently.

What take-homes actually grade

The number that surprises people is the first row's weight. A take-home that implements the feature and ships no tests, no README and a single 400-line file is a rejection, and the candidate almost always believes they passed — because it worked.

The reliable strategy is to treat the take-home as a small production repository: src/ layout, tests that encode the requirements from the brief, a README with a "decisions and trade-offs" section naming what you deliberately did not do, and errors that a caller could act on. Then do slightly less feature work than you were tempted to, and say why in the README. Respecting scope reads as judgement; exceeding it reads as an inability to prioritise.

Common Mistakes

1. Writing another language in Python's syntax. range(len(items)), == True, manual sorting, result = result + [x]. Correct, and it predicts how you will write in the codebase.
2. Coding before clarifying. Asking whether the input can be empty or contain duplicates is the cheapest credibility you will ever buy.
3. Silence in a live round. The interviewer is grading your reasoning and cannot see it. A narrated wrong approach beats a silent right one more often than candidates believe.
4. Waiting to be asked about complexity. Stating it unprompted — with the trade-off — demonstrates judgement; being asked converts it into a quiz.
5. Inventing an API confidently. "I would check the exact signature" costs nothing. A confidently wrong method name makes everything else you said suspect.
6. Declaring you are done without testing by hand. Walk one example through your own code. Finding your own bug scores higher than the bug not existing.
7. Treating a take-home as a feature request. It is graded on tests, structure, README and error handling; "it works" is a small share of the marks.
8. Gold-plating a take-home. Doing more than the brief reads as poor prioritisation. Do slightly less and explain the choice.
9. Optimising before the naive version exists. Say "the brute force is O(n²), let me improve it" — you bank a correct answer and show the ladder.
10. Preparing only algorithms for a Python role. The differentiating questions are about the language and about production, which is what Parts I to VII were.

Interview Corner

This chapter's Interview Corner is unusual: these are the meta-questions that open and close nearly every loop, and they are marked as strictly as the technical ones.

Summary

• Correctness is table stakes; how you got there is the grade. Two working solutions receive different verdicts because the interviewer is predicting two years of collaboration from forty minutes.
• The strongest signal is whether Python shaped your thinking. enumerate over range(len()), a comprehension over an append loop, Counter over a hand-rolled tally — the ordinary way, reached for reflexively.
• The standard library is the language's vocabulary. Not knowing Counter, defaultdict, zip or sorted(key=) reads as not having written much Python, whatever the CV says.
• Each format samples different things. An async screen sees correctness and speed only; a live round grades reasoning and response to hints; a take-home grades everything Parts VI and VII covered.
• Clarify before coding. "Can it be empty? Duplicates? Sorted?" is the cheapest credibility available and marks someone whose code other people have run.
• State complexity and the trade unprompted. Volunteering "O(n) time, O(n) space; constant space would cost a sort" demonstrates judgement. Being asked converts it into a quiz.
• Narrate in a live round. A narrated wrong approach that adjusts on a hint routinely beats a silent correct one, because responsiveness is what is being sampled.
• Verify by hand before declaring done. Walking one example through your own code and finding your own bug scores higher than the bug never existing.
• A take-home is a small production repository. Tests, structure, README with decisions, deliberate error handling — "it works" is a small share of the available marks, and gold-plating costs points.
• Say "I would look that up". Confidently inventing an API makes everything else you said confidently suspect.

In the next chapter, The Questions That Sort Candidates, we go through the specific questions that separate people who use Python from people who understand it — mutable defaults, the object model, closures in loops, generators versus lists — with the answer that scores, the follow-up that is coming, and what the interviewer is actually checking.