Python interview questions for freshers

Most fresher Python questions have a memorised answer everyone gives and a follow-up almost nobody survives. The follow-up is the actual test.

JobsDart Editorial6 min read

Key takeaways

  • Every standard question has a second level, and preparing that level is the highest-return thing you can do.
  • Mutability sits behind a surprising share of the questions asked.
  • Generators reward real preparation because few candidates can explain what problem they solve.
  • Coding rounds test clean working code and thinking aloud, not clever algorithms.
  • Prepare three sentences per CV project, including what you would build differently now.

How these interviews are structured

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.

Mutability, the question behind many questions

"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
The memorised answer and the follow-up it invites
QuestionWhat everyone saysWhat is actually being asked
List vs tupleOne is mutableWhy tuples can be dict keys
== vs isValue versus identityWhy small integers seem to break it
What is a decoratorA function wrapping a functionWrite one that takes an argument
What is the GILOne thread at a timeSo when does threading still help?
What is a generatorIt yieldsWhat problem does laziness solve here
Shallow vs deep copyOne is nestedShow where shallow bites you

Questions about how Python runs

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.

The coding round

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

Questions about your own project

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.

What to do in the last week

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.

Frequently asked questions

What Python topics come up most for freshers?

Mutability, list versus tuple versus set versus dict, the mutable default argument, `==` versus `is`, generators, decorators and the GIL. Prepare the follow-up explanation, not just the definition.

How hard are fresher Python coding rounds?

Usually string and collection manipulation rather than difficult algorithms. Clean working code, stated complexity and thinking out loud matter more than finding a clever solution.

Should I use built-in libraries in a coding round?

Yes, and say why you chose them. Interviewers sometimes then ask you to implement it by hand, so knowing both the library and the underlying logic is the strongest position.

How do I answer questions about my own project?

Prepare three sentences per project: what it does, the hardest problem you hit, and what you would build differently now. The third one signals reflection and is the one most freshers have not thought about.

If the GIL means one thread at a time, why use threading?

Because the lock is released while waiting on input and output. Threads help for network and disk work and do nothing for computation, which is the follow-up that catches most candidates.

What should I do in the final week?

Explain topics out loud rather than reading, write the mutable default example, a generator and a decorator from memory, and re-open your own project code before the interview.

Further reading

Check this against your own resume

Scan your CV against a real job description, or build a parse-safe one from scratch. Your first scan costs nothing.

Keep reading

All career guides