See exactly what you get for ₹99

Say this: "[1] then [1, 2]. The default value is evaluated once, when the function is defined — not on every call. So both calls append to the same list object, and the second one sees what the first one left behind."

Say the fix without being asked — that's what scores: "The fix is to default to None and build the list inside the function."

def add(item, items=None):
    if items is None:
        items = []
    items.append(item)
    return items

Follow-up: "Which defaults are safe, then?" → Immutable ones — a number, a string, a tuple, None. Never a list, dict or set.

Follow-up: "Why does Python work this way?" → Because the def line is executed once, like any other statement, and the default is just an expression evaluated at that moment. It's consistent — it only surprises you when the object is mutable.

Don’t say: "[1] then [2]." That assumes a fresh list per call, and it's the single most-asked Python fresher trap — the interviewer is watching for exactly this answer.

Say this: "__init__ — but strictly, two things happen. __new__ creates and returns the instance first, then __init__ initialises it, receiving that instance as self along with the argument. In everyday code I only write __init__; I'd override __new__ for a singleton or when subclassing an immutable type like tuple."

Follow-up: "So is __init__ the constructor?" → Most teams call it that and it's accepted. The precise answer is that __new__ constructs and __init__ initialises — and saying that one line puts you above most candidates.

Follow-up: "What's __str__ versus __repr__?" → __str__ is the readable form for users, used by print(). __repr__ is the unambiguous developer form, used in the REPL and inside containers. If only __repr__ exists, print falls back to it — so if you write one, write that.

Don’t say: "__call__." That runs when you call an instance like a function — obj(), not Student(...).

Say this: "Both, really. When I run a .py file, Python first compiles the source into bytecode — that's what the .pyc files in __pycache__ are — and then the Python Virtual Machine interprets that bytecode. So there is a compile step, but it produces bytecode, not machine code, and it happens automatically. I never invoke a compiler myself the way I would with C."

Follow-up: "Then why is Python called slow?" → Because the PVM interprets bytecode instruction by instruction instead of running native machine code, and every value is a full object with dynamic type lookup. PyPy adds a JIT that compiles hot code to machine code, which is why it can be several times faster on tight loops.

Follow-up: "Is Python dynamically typed or weakly typed?" → Dynamically and strongly typed. Dynamic means a variable's type is known at runtime, not declared. Strong means it won't silently coerce — "5" + 5 raises TypeError, unlike JavaScript.

Don’t say: "It's interpreted line by line." That's the schoolbook answer and the follow-up is always "then what is __pycache__?" — mention bytecode and the PVM and you've already answered the next two questions.

Say this: "A list is mutable — I can append, remove, sort in place. A tuple is immutable once created. Because a tuple can't change, it's hashable, so it can be a dictionary key or a set member, which a list can never be. Tuples are also slightly faster to create and use a bit less memory. I use a list for a collection of similar things that grows, and a tuple for a fixed record — coordinates, a row from a database, a function returning two values."

Follow-up: "Is a tuple always hashable?" → No. A tuple containing a list isn't — hash((1, [2])) raises TypeError. Hashability is recursive; the tuple is only as hashable as its contents.

Follow-up: "What is (1)?" → An integer. The comma makes the tuple, not the brackets — (1,) is the one-element tuple. That's a real bug source when a function is meant to return a single-item tuple.

Don’t say: "A tuple is a read-only list." It suggests they're interchangeable. The interesting part is why immutability matters: hashability and intent.

Say this: "== compares values — it calls the object's __eq__. is compares identity: whether both names point to the same object in memory, the same id(). So a = [1]; b = [1] gives a == b True but a is b False — equal contents, two different objects. In practice I only use is for None, True and False."

Follow-up: "But a = 5; b = 5; a is b gives True — explain." → CPython caches small integers from −5 to 256 and interns short strings, so both names happen to point to the same cached object. It's an implementation detail, not a language guarantee — try it with 1000 in a script and it may be False. That's exactly why is must never be used for value comparison.

Follow-up: "Why if x is None and not if x == None?" → Identity is faster, and there is exactly one None object, so it can't be fooled by a class that overrides __eq__ to return True for everything.

Don’t say: "They're the same thing." It's the single most common trap in Python screening rounds and answering it wrong ends the language section early.

Say this: "[1, 2, 3, 4]. b = a doesn't copy anything — both names point to the same list object. And += on a list is an in-place operation, it calls __iadd__, which is basically extend. So the one shared list is mutated and a sees it."

Follow-up: "Change it to b = b + [4]." → Then it prints [1, 2, 3]. + builds a brand-new list and rebinds b to it; a still points at the original. That asymmetry between += and + only exists for mutable types.

Follow-up: "What about a tuple or a string?" → They're immutable, so += can't mutate — it always creates a new object and rebinds the name. Same operator, completely different behaviour depending on mutability.

Don’t say: "b is a copy of a." Assignment in Python never copies. To copy, say b = a[:], list(a) or copy.copy(a).

Say this: "A shallow copy — a[:], list(a), copy.copy(a) — creates a new outer container but the elements inside are the same objects. A deep copy, copy.deepcopy(a), walks the whole structure and copies the nested objects too. So for a flat list of numbers the two are identical in effect; the difference only shows up when the list holds other mutable objects."

m = [[1], [2]]
s = m[:]              # shallow
s[0].append(9)
print(m)              # [[1, 9], [2]]  -- the inner list is shared

import copy
d = copy.deepcopy(m)
d[0].append(7)
print(m)              # unchanged

Follow-up: "When would you avoid deepcopy?" → It's slow on large structures and it copies things you may not want copied — open connections, big caches. Often the cleaner fix is to build a fresh object rather than deep-copy an old one.

Follow-up: "How does deepcopy handle a cycle — a list containing itself?" → It keeps a memo dictionary of already-copied objects, so it handles cycles without infinite recursion.

Don’t say: "a[:] makes a full copy." It makes a new list of the same inner objects — that's the whole point of the question.

Good answer hits: int, float, str, tuple, frozenset, bytes — and that list, dict and set are the mutable ones. Immutable objects can be dict keys because they're hashable.

One-liner: "Numbers, strings, tuples and frozensets are immutable; lists, dicts and sets are not."

Follow-up they add: "Is a tuple always hashable?" → No — not if it contains a list.

Good answer hits: A float, 0.5 — / is true division in Python 3, regardless of the operand types. // is the one that floors and gives an int for int operands.

One-liner: "float — / is always true division in Python 3; // is floor division."

Follow-up they add: "And in Python 2?" → It returned 0, which is the single most famous 2-to-3 difference.

Good answer hits: is — it compares object identity, the same id(). == compares value by calling __eq__. Use is only for None, True and False.

One-liner: "is for identity, == for value — and only ever is None."

Follow-up they add: "Why does a = 5; b = 5; a is b give True?" → Small-integer caching, an implementation detail you must never rely on.