Python Interview Questions

Working through a list of two hundred Python questions feels productive and rarely changes the outcome of an interview. This section narrows the field to the handful that recur across phone screens and technical rounds, and shows what a strong answer contains. A small number of language features carry most of the signal.

• Mutable default arguments. Why does def f(x=[]) accumulate values between calls? Defaults are evaluated once, when the function is defined, not on every call.
• Generators versus lists. When does yield beat building a list? When the sequence is large, or when you may stop reading early.
• Decorators. What does a decorator actually return, and why does the wrapper need functools.wraps?
• The GIL. Why do CPU-bound threads fail to scale in CPython, and what do you reach for instead?
• Shallow versus deep copy. What breaks when a nested structure is copied with a slice?
• Identity versus equality. Why testing is against small integers in a shell gives you a misleading result.

Two candidates can give the same correct definition of the GIL and only one moves forward. The difference is usually the second sentence.

A backend engineer interviewing for an L5 role at a public cloud vendor was asked why their service slowed down under load. They named the GIL, then kept going: the hot path was JSON parsing, so threads were the wrong tool, and moving that stage to a process pool restored throughput. Naming the constraint earned partial credit. Connecting it to a decision earned the round.

Build each answer in three beats: what the feature does, why it exists, and when you would avoid it. The third beat is the one most candidates skip, and it is the one that shows judgment. Other pages on coding, behavioral and system design rounds are grouped under interview types.

Reading an answer and saying an answer are different skills, and only one of them is tested. Rehearse out loud, against a clock, in the same words you would use on the call.

• Write your answer to each recurring question as three sentences, then say it without looking.
• Pick two features you use daily and prepare an honest limitation for each. Being able to criticize your own tools reads as experience.
• Bring one real debugging story where Python behavior surprised you and you found out why.
• Practice the applied half separately: dictionaries, sets, sorting with a key function, and string handling cover a large share of screens.

If you want a timed run against an AI interviewer before the real thing, that lives on the mock interview page.

SubcueAI is a native desktop app for macOS and Windows. It captures both sides of the call, transcribes in real time, and shows a scaffold on a floating overlay that stays local to your machine, so it does not join the meeting as a participant or bot. For a Python round, the useful output is a structure prompt, not a finished answer: the specifics have to be yours, because the follow-up question will be about the code you just described.

The honest limits matter more than the capability. If you share your screen, whatever is on that screen is shared. If the round runs on a proctored assessment platform, or on a company-managed device, an assistant is out of scope. Setup and permissions are covered on the tutorial page.