Python interview questions for freshers

A fresher Python interview is usually three parts: language questions to check you understand rather than recite, a small coding problem, and a few questions about anything on your CV. The language part is where most candidates are filtered.

Interviewers know the standard answers are memorised, so they ask one level deeper. Preparing the second level rather than the first is the single highest-return thing you can do.

This is good news, because the set of questions is small and stable. There are perhaps a dozen topics, and knowing each one level deeper than the common answer covers most of what you will be asked.

"What is the difference between a list and a tuple" gets the answer "lists are mutable, tuples are not" from everyone. The follow-up is what matters: why does that distinction exist, and when does it bite?

Be ready for the mutable default argument — a function with `def f(x, items=[])` that accumulates across calls. It is the most commonly asked Python gotcha, it confuses people who have only memorised definitions, and explaining why it happens demonstrates that you understand when defaults are evaluated.

The unifying explanation is that names are bound to objects rather than to values. Once that is clear, the default argument behaviour, the copy questions and the confusion about passing a list into a function all resolve into the same single idea.

• Why a tuple can be a dict key and a list cannot
• What happens with a mutable default argument, and why
• The difference between `==` and `is`, and when `is` misleads
• Shallow versus deep copy, with an example where it matters

Expect something about the GIL, decorators, generators or context managers. These are the topics where a clear explanation is genuinely distinguishing, because most candidates can name them and few can explain what problem each solves.

Generators are worth real preparation. Being able to say that they produce values lazily so you never hold the whole sequence in memory, and give a case where that is the difference between working and running out of memory, is a better answer than any definition.

The GIL question has a follow-up that catches people: if only one thread runs Python at a time, why is threading still useful? The answer — that the lock is released while waiting on input and output, so threads help for network and disk work and not for computation — is what separates recall from understanding.

Fresher coding problems are usually string and collection manipulation rather than hard algorithms: counting, grouping, deduplicating, reversing, finding a first non-repeating item. What is assessed is whether you write clean, working code and talk while doing it.

Reach for the standard library and say why. Using `collections.Counter` and explaining that you would rather not reimplement it shows judgement; interviewers occasionally ask you to write it by hand afterwards, and knowing both is the strongest position.

Say the complexity without being prompted. Freshers frequently produce a correct answer and never mention that it is linear, and volunteering it costs one sentence while signalling that you think about cost as a matter of habit.

• State your approach before typing
• Handle the empty input and the single-element case out loud
• Say the complexity of what you wrote, without being asked
• If stuck, narrate what you are considering rather than going silent

Anything on your CV is fair game, and this is where freshers most often come unstuck — not because the project was weak but because they cannot explain a decision inside it.

For each project, prepare one sentence on what it does, one on the hardest problem you hit, and one on something you would build differently now. That last one signals reflection, which interviewers read as the ability to learn from work rather than just complete it.

Be honest about what you used help for. Saying that you generated the first version of something and then had to rewrite part of it because it mishandled an edge case is a completely acceptable answer, and far better than claiming authorship of code you cannot explain.

Stop reading and start explaining out loud. The gap that costs offers is not knowing less but being unable to articulate it under mild pressure, and that only improves by practising the articulation.

Write the mutable default example, a generator, and a small decorator from memory, without looking. Those three cover a disproportionate share of what gets asked, and typing them once is worth more than reading about them five times.

Re-read your own CV projects and open the code. Interviewers ask about specifics — a library choice, a function name, why a file is structured a certain way — and being unable to answer about your own repository is the worst impression available in a fresher interview.