DEV Community: Ameer Abdullah

Why Python Developers Fail Default Mutable Argument Questions in Interviews

Ameer Abdullah — Sun, 05 Jul 2026 05:00:00 +0000

Why Python Developers Fail Default Mutable Argument Questions in Interviews

There is a Python behavior that has ended more technical interviews than almost any other single concept. It appears in entry-level screens at startups and senior-level loops at FAANG companies alike.

It is the default mutable argument trap.

Here is the classic version:

def add_item(item, items=[]):
    items.append(item)
    return items

print(add_item("a"))
print(add_item("b"))
print(add_item("c"))

Before reading further, write down what you think this prints.

Most people write:

['a']
['b']
['c']

The actual output is:

['a']
['a', 'b']
['a', 'b', 'c']

If you got it wrong, you are in good company. If you got it right, this article explains why it works this way and what variations interviewers use to trip up people who know the basic version.

Why This Happens

In Python, default argument values are evaluated once when the function is defined, not each time the function is called.

That single sentence is the entire explanation. The list [] in def add_item(item, items=[]) is created once when Python parses the function definition. It is stored as part of the function object itself. Every call to add_item that does not pass an explicit items argument shares that same list object.

You can see this yourself by checking the function's internal attributes:

print(add_item.__defaults__)
# After three calls, this outputs: (['a', 'b', 'c'],)

The default value lives inside the function and mutates with each call.

The Trace Table for This Problem

A trace table helps visualize how the state changes across executions.

Call	item	items (default object)	After append	Returns
`add_item("a")`	"a"	`[]`	`["a"]`	`["a"]`
`add_item("b")`	"b"	`["a"]`	`["a", "b"]`	`["a", "b"]`
`add_item("c")`	"c"	`["a", "b"]`	`["a", "b", "c"]`	`["a", "b", "c"]`

The key column is the third one. The default object does not reset between calls. It carries its state forward.

How Interviewers Make It Harder

Once you know the basic trap, interviewers add layers. Here are the three most common variations:

Variation 1: The dictionary default

Same behavior, different data structure.

def update_config(key, value, config={}):
    config[key] = value
    return config

print(update_config("debug", True))
print(update_config("verbose", False))

Output:

{'debug': True}
{'debug': True, 'verbose': False}

Variation 2: The conditional write

The second call does not duplicate because of the conditional check, but the underlying list still persists.

def add_if_missing(item, items=[]):
    if item not in items:
        items.append(item)
    return items

print(add_if_missing("x"))
print(add_if_missing("x"))
print(add_if_missing("y"))

Output:

['x']
['x']
['x', 'y']

Variation 3: The None pattern fix

Interviewers sometimes show you the correct version and ask you to explain exactly why it works:

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

Here, None is immutable. A new, clean list is created inside the function body on each call where items is not provided. The default reference itself never mutates.

What the Interviewer Is Actually Testing

When an interviewer asks a default mutable argument question, they are not testing whether you memorized this specific quirk. They are testing three deeper things:

Interpreter Mechanics: Whether you understand that Python evaluates defaults at definition time, not call time. This requires understanding how the Python interpreter parses and stores function objects.
State Tracking: Whether you can trace through the execution manually without running the code. The ability to predict output by reasoning about state is a fundamental skill that transfers to debugging, code review, and system design.
Best Practices: Whether you know the correct pattern to avoid the bug. The None sentinel pattern is the accepted industry solution. Knowing it exists and explaining why it works demonstrates depth beyond just knowing the trap exists.

How to Practice This Type of Problem

The most effective practice for mutable default argument questions and similar Python traps is dry-run tracing. Reading the code line by line, tracking every variable state in a table, and predicting the output before running it.

I built a free tool called PyCodeIt that generates unique Python tracing problems across this exact category of issues. Each problem is AI-generated so you never see the same question twice, and the explanation after each answer shows you the complete variable trace.

You can try it out at pycodeit.com without creating an account.

Three More Mutable Trap Patterns to Study

If you want to master pythonic edge cases, make sure to look into these next:

Class-level mutable attributes shared across instances
The += operator on lists inside functions (modifies in place versus rebinding)
Generator expressions that close over loop variables

Each of these works on the same underlying principle as the default mutable argument. Once you understand that Python names are references to objects rather than containers holding values, all of these patterns become completely predictable.

Written by the developer behind PyCodeIt, a free AI-powered Python dry-run practice platform for technical interview preparation.

Python String Methods Are Lying to You About What They Return

Ameer Abdullah — Sat, 04 Jul 2026 09:00:00 +0000

I have seen this bug in production code written by developers with three or more years of experience.

name = "  hello world  "
name.strip()
name.upper()
print(name)

What does this print?

Not "HELLO WORLD". Not "hello world". It prints " hello world " exactly as it started.

Both operations were thrown away.

Why String Methods Never Modify In Place

Strings in Python are immutable. Once a string object exists, it cannot be changed. Every string method that appears to modify a string is actually returning a brand new string object.

The operation ran. The result was computed. But you did not capture it anywhere, so it was immediately garbage collected.

The Correct Pattern

name = "  hello world  "
name = name.strip()
name = name.upper()
print(name)

Output: HELLO WORLD

Or in one line using method chaining:

name = "  hello world  ".strip().upper()
print(name)

Each method returns a new string. The next method in the chain is called on that new string. The original string is never involved after the first call.

Tracing Method Chaining

result = "  Python is Great  ".strip().lower().replace("is", "was").split()
print(result)

Trace each step:

Step 1: " Python is Great ".strip() returns "Python is Great"
Step 2: "Python is Great".lower() returns "python is great"
Step 3: "python is great".replace("is", "was") returns "python was great"
Step 4: "python was great".split() returns ["python", "was", "great"]

Output: ['python', 'was', 'great']

The original string " Python is Great " is untouched throughout. Four new string objects were created and three were immediately discarded.

The Interview Problem

def process(text):
    text.strip()
    text = text.lower()
    text.replace(" ", "_")
    return text

result = process("  Hello World  ")
print(result)

Output: " hello world "

Line by line:

text.strip() runs but the result is discarded. text is still " Hello World ".
text = text.lower() runs and the result IS captured. text is now " hello world ".
text.replace(" ", "_") runs but the result is discarded. text is still " hello world ".
The function returns " hello world ". The strip was wasted and the replace was wasted. Only the lower() result was kept because only that line used assignment to capture the return value.

Five Methods That Beginners Forget Return New Strings

s = "hello"

s.upper()        # returns "HELLO"  -- s unchanged
s.replace("h", "H")  # returns "Hello" -- s unchanged
s.strip()        # returns "hello"  -- s unchanged (no whitespace)
s.center(11)     # returns "   hello   " -- s unchanged
s.encode()       # returns b"hello" -- s unchanged

print(s)         # still "hello"

Compare to list methods that modify in place:

lst = [3, 1, 2]
lst.sort()       # modifies lst in place, returns None
lst.append(4)    # modifies lst in place, returns None
print(lst)       # [1, 2, 3, 4]

Lists are mutable so their methods modify in place. Strings are immutable so their methods return new objects. This asymmetry is the root of most string-related bugs.

Practice output prediction problems at PyCodeIt.

What Does This Python Code Print? 10 Problems to Test Yourself

Ameer Abdullah — Fri, 03 Jul 2026 06:12:49 +0000

No explanations until the end. Work through each one by tracing the code mentally. Write down your answer before you scroll.

This is exactly the format used in technical interviews and university database and programming exams.

Problem 1

x = 5
def change(n):
    n = n + 10
    return n
change(x)
print(x)

Problem 2

a = [1, 2, 3]
def add(lst):
    lst.append(4)
add(a)
print(a)

Problem 3

result = []
for i in range(3):
    result.append(lambda: i)
print([f() for f in result])

Problem 4

def outer():
    x = 10
    def inner():
        x = 20
        return x
    inner()
    return x
print(outer())

Problem 5

data = {1: 'a', 2: 'b', 3: 'c'}
for k, v in data.items():
    if k == 2:
        data[4] = 'd'
print(data)

Problem 6

words = ['hi', 'hello', 'hey']
result = sorted(words, key=len, reverse=True)
print(result[0])
print(words)

Problem 7

def count(start=0, step=1):
    return start + step

print(count(5))
print(count(step=3))
print(count(2, 3))

Problem 8

class Counter:
    total = 0
    def __init__(self):
        Counter.total += 1

a = Counter()
b = Counter()
c = Counter()
print(Counter.total)
print(a.total)

Problem 9

s = "python"
print(s[1:5:2])
print(s[-1::-1])

Problem 10

x = [1, 2, 3]
y = x
x = x + [4]
print(x)
print(y)

Answers

Problem 1: 5
Integers are immutable. The function creates a new local n with value 15. The original x is unchanged.

Problem 2: [1, 2, 3, 4]
Lists are mutable. The function receives a reference to the same list object and appends to it in place. The original list is modified.

Problem 3: [2, 2, 2]
Late binding closure. All three lambdas capture the variable i, not its value at creation time. When called, i is 2 (the last value from range(3)). All three return 2.

Problem 4: 10
The inner function creates its own local x = 20. Without nonlocal, this does not affect the outer x. The outer function returns its own x which is still 10.

Problem 5: {1: 'a', 2: 'b', 3: 'c', 4: 'd'}
In Python 3.7 and later, adding a key during iteration does not always raise RuntimeError if the size change is handled carefully. The dictionary gets the new key added.

Problem 6: First line: hello. Second line: ['hi', 'hello', 'hey']
sorted() returns a new list. It does not modify the original. result[0] is the longest word which is hello.

Problem 7:

6   (count(5) = 5 + 1)
3   (count(step=3) = 0 + 3)
5   (count(2, 3) = 2 + 3)

Problem 8: 3 then 3
total is a class variable shared across all instances. After three instantiations it is 3. Accessing a.total finds no instance attribute so it reads the class attribute which is also 3.

Problem 9:
yh (characters at index 1 and 3, stepping by 2)
nohtyp (reversed string)

Problem 10: [1, 2, 3, 4] then [1, 2, 3]
x = x + [4] creates a NEW list and rebinds x to it. y still points to the original list [1, 2, 3] which was never modified.

How many did you get right? If you missed any, the explanation tells you exactly which concept to study.

For more problems like this with AI-generated unique questions every session, try PyCodeIt. Free, no account needed.

The Python Dictionary Trick That Makes Interviewers Smile

Ameer Abdullah — Wed, 01 Jul 2026 05:00:00 +0000

There is one dictionary pattern that separates developers who learned Python from developers who understand Python.

It shows up in grouping problems, counting problems, and graph problems. Every experienced Python developer recognizes it. Interviewers notice when you use it naturally.

Here is the pattern and five problems where it applies.

The Pattern: defaultdict

from collections import defaultdict

groups = defaultdict(list)
data = [("Alice", "Engineering"), ("Bob", "Marketing"),
        ("Carol", "Engineering"), ("Dave", "Marketing"),
        ("Eve", "Engineering")]

for name, dept in data:
    groups[dept].append(name)

print(dict(groups))

Output:

{'Engineering': ['Alice', 'Carol', 'Eve'], 'Marketing': ['Bob', 'Dave']}

Without defaultdict you would write:

groups = {}
for name, dept in data:
    if dept not in groups:
        groups[dept] = []
    groups[dept].append(name)

The defaultdict(list) version eliminates the key existence check entirely. When you access a missing key it automatically creates an empty list. The logic becomes a single line.

Problem 1: Count Word Frequencies

from collections import defaultdict

text = "the cat sat on the mat the cat"
freq = defaultdict(int)

for word in text.split():
    freq[word] += 1

print(dict(freq))

Output:

{'the': 3, 'cat': 2, 'sat': 1, 'on': 1, 'mat': 1}

defaultdict(int) initializes missing keys to 0. Each increment works without any key check. This is the standard Python pattern for frequency counting.

Problem 2: Build an Adjacency List

from collections import defaultdict

edges = [(1, 2), (1, 3), (2, 4), (3, 4), (4, 5)]
graph = defaultdict(list)

for src, dst in edges:
    graph[src].append(dst)
    graph[dst].append(src)

print(dict(graph))

Output:

{1: [2, 3], 2: [1, 4], 3: [1, 4], 4: [2, 3, 5], 5: [4]}

Graph problems in interviews almost always require building an adjacency list first. This is the cleanest way to do it in Python.

Problem 3: Nested Grouping

from collections import defaultdict

data = [("Engineering", "London", "Alice"),
        ("Engineering", "Berlin", "Bob"),
        ("Marketing", "London", "Carol"),
        ("Engineering", "London", "Dave")]

nested = defaultdict(lambda: defaultdict(list))
for dept, city, name in data:
    nested[dept][city].append(name)

print(dict({k: dict(v) for k, v in nested.items()}))

Output:

{'Engineering': {'London': ['Alice', 'Dave'], 'Berlin': ['Bob']},
 'Marketing': {'London': ['Carol']}}

defaultdict(lambda: defaultdict(list)) creates a nested defaultdict on demand. This handles two-level grouping without any key existence checks at either level.

The Interview Follow-Up

Interviewers who see you use defaultdict naturally will often ask: "what happens if you access a key that does not exist in a regular dict versus a defaultdict?"

Regular dict: raises KeyError.
defaultdict: calls the factory function and returns the default value without raising.

The follow-up to the follow-up: "when would you prefer a regular dict over defaultdict?"

When you want missing key access to be an error, not silently create a value. For example, looking up a user ID that should exist in a database. If the ID is missing you want to know about it, not silently create an empty list.

Practice dictionary tracing problems at PyCodeIt.

PyCodeIt 2.0 is officially here!

I’ve rebuilt your ultimate Python interview sandbox from the ground up. Whether you are a computer science student, a data science graduate, or a developer preparing to ace technical interviews, Python code tracing is a highly tested yet rarely practiced skill. PyCodeIt is built specifically to bridge that gap, and our latest update changes everything.

5 Python List Problems That Catch Everyone Off Guard

Ameer Abdullah — Tue, 30 Jun 2026 05:00:00 +0000

Lists are the first data structure you learn in Python. They are also the source of the most interview mistakes. These five problems test list behavior that most developers misunderstand until they get it wrong under pressure.

Work through each one before reading the answer.

Problem 1: The Slice That Does Nothing

a = [1, 2, 3, 4, 5]
b = a[:]
b.append(6)
print(a)
print(b)

What do both lines print?

Output:

[1, 2, 3, 4, 5]
[1, 2, 3, 4, 5, 6]

a[:] creates a shallow copy. b is a new list object containing the same integer objects. Appending to b only modifies b because integers are immutable and the copy itself is a different object than a.

Problem 2: The Shallow Copy Trap

a = [[1, 2], [3, 4], [5, 6]]
b = a[:]
b[0].append(99)
print(a)
print(b)

Output:

[[1, 2, 99], [3, 4], [5, 6]]
[[1, 2, 99], [3, 4], [5, 6]]

The shallow copy makes a new outer list but the inner lists are the same objects. b[0] and a[0] both point to the same inner list. Mutating through b[0] changes the object that a[0] also points to.

To avoid this you need copy.deepcopy(a).

Problem 3: The Multiplication Surprise

matrix = [[0] * 3] * 3
matrix[0][1] = 9
print(matrix)

Most people expect:

[[0, 9, 0], [0, 0, 0], [0, 0, 0]]

Actual output:

[[0, 9, 0], [0, 9, 0], [0, 9, 0]]

The * operator on a list creates multiple references to the same inner list, not copies of it. All three rows are the same object. Modifying one modifies all.

The correct way to create a 2D matrix:

matrix = [[0] * 3 for _ in range(3)]

List comprehension creates a new list for each row.

Problem 4: The Sort That Returns Nothing

numbers = [3, 1, 4, 1, 5, 9]
result = numbers.sort()
print(result)
print(numbers)

Output:

None
[1, 1, 3, 4, 5, 9]

list.sort() sorts in place and returns None. sorted(numbers) returns a new sorted list without modifying the original. This confusion between the two is one of the most common bugs data science developers introduce when cleaning datasets.

Problem 5: The Remove During Iteration Bug

numbers = [1, 2, 3, 4, 5, 6]
for n in numbers:
    if n % 2 == 0:
        numbers.remove(n)
print(numbers)

Most people expect: [1, 3, 5]

Actual output: [1, 3, 5, 6]

The 6 survives. Here is why. When you remove 2 from index 1, all elements shift left. The index counter advances to 2, which now points to 4 (not 3). 3 is never checked. Then 4 is removed and 6 shifts to index 3, but the counter advances to 4 which is past the end. 6 is never checked.

The safe pattern:

numbers = [n for n in numbers if n % 2 != 0]

Always use list comprehension or iterate over a copy when removing during iteration.

Practice predicting outputs like these at PyCodeIt. Free, no account needed to start.

Now v 2.0 is available. Go and check and give feedback!

How to Read a Recursive Function Without Losing Your Mind

Ameer Abdullah — Sun, 28 Jun 2026 06:59:00 +0000

Recursion is not difficult. Tracing recursion is difficult.

The reason is that most people try to hold the entire call stack in their head simultaneously. You cannot do this reliably for more than three or four levels. Your working memory runs out and you lose track.

The solution is a systematic method that keeps information on paper instead of in your head. Once you have this method, you can trace any recursive function regardless of depth.

The Two-Column Method

Draw two columns on paper before you trace a single line.

Left column: the function call and its argument.
Right column: what it returns.

You fill in the left column going down. You fill in the right column coming back up.

Applying It to a Simple Example

def factorial(n):
    if n == 0:
        return 1
    return n * factorial(n - 1)

print(factorial(4))

Fill in the left column first, going down until you hit the base case:

factorial(4)    |  ?
factorial(3)    |  ?
factorial(2)    |  ?
factorial(1)    |  ?
factorial(0)    |  1   <-- base case, fill right column here

Now fill the right column coming back up. Each row gets the return value of the row below it:

factorial(4)    |  24   (4 * 6)
factorial(3)    |  6    (3 * 2)
factorial(2)    |  2    (2 * 1)
factorial(1)    |  1    (1 * 1)
factorial(0)    |  1

The answer is 24.

The Method on a Harder Example

def mystery(n):
    if n <= 0:
        return 0
    if n % 2 == 0:
        return mystery(n - 2) + n
    return mystery(n - 1)

print(mystery(6))

Left column going down:

mystery(6)    n=6, even, so mystery(4) + 6
mystery(4)    n=4, even, so mystery(2) + 4
mystery(2)    n=2, even, so mystery(0) + 2
mystery(0)    n<=0, return 0

Right column coming back up:

mystery(6)    = mystery(4) + 6 = 6 + 6 = 12
mystery(4)    = mystery(2) + 4 = 2 + 4 = 6
mystery(2)    = mystery(0) + 2 = 0 + 2 = 2
mystery(0)    = 0

Output: 12

The method works because it separates the two phases: descending (making calls) and ascending (returning values). You never have to hold both in mind simultaneously.

The Three Rules That Cover Every Recursive Problem

Rule 1: Always find the base case first. Write it in your right column before anything else. The base case is the only row you can fill in without looking at another row.

Rule 2: Fill the left column completely before touching the right column. Do not alternate. Write every call going down, then turn around and return values going up.

Rule 3: Each right column value is always computed using the values of the rows below it, never the rows above. If you find yourself looking upward in the right column to compute a value, you are doing it wrong.

These three rules prevent every category of recursion tracing error.

The Interview Version

Interviewers sometimes add a twist: asking what prints during the recursion, not just what returns.

def trace_me(n):
    if n == 0:
        print("base")
        return
    print(f"going down: {n}")
    trace_me(n - 1)
    print(f"coming up: {n}")

trace_me(3)

Output:

going down: 3
going down: 2
going down: 1
base
coming up: 1
coming up: 2
coming up: 3

The print before the recursive call fires on the way down. The print after the recursive call fires on the way back up. This pattern appears in tree traversal and many real-world algorithms.

Practice recursive tracing problems at PyCodeIt. The hard difficulty section includes several recursion problems that test exactly this ascending and descending behavior.

Python's += Operator Is Lying to You (And Here's the Proof)

Ameer Abdullah — Sat, 27 Jun 2026 06:00:00 +0000

I want to show you something that has confused developers at every skill level, from beginners to people with years of Python experience.

Run this in your head before you read the answer:

a = [1, 2, 3]
b = a
a += [4, 5]
print(b)

What do you think b prints?

Most people say [1, 2, 3]. The actual answer is [1, 2, 3, 4, 5].

Now run this one:

a = 10
b = a
a += 5
print(b)

What does b print now?

The answer is 10. Unchanged.

Same operator. Completely different behavior. Here is why.

The += Operator Is Not One Thing

Most languages treat += as shorthand for x = x + something. Python does this too, but only for immutable types.

For mutable types like lists, += does something different. It calls __iadd__ which modifies the object in place rather than creating a new one.

This distinction is everything.

Tracing the List Version Step by Step

a = [1, 2, 3]
b = a
a += [4, 5]
print(b)

Step 1: a = [1, 2, 3] creates a list object in memory. Let's call its address 1000. The name a points to address 1000.

Step 2: b = a does not copy the list. It creates another name b that also points to address 1000. Both a and b are labels on the same object.

Step 3: a += [4, 5] calls list.__iadd__([4, 5]) on the object at address 1000. This extends the list in place. The object at address 1000 is now [1, 2, 3, 4, 5]. The name a still points to address 1000.

Step 4: print(b) prints whatever is at address 1000. That is [1, 2, 3, 4, 5].

The mutation happened to the object, not the name. Both names saw the change because both names point to the same object.

Tracing the Integer Version Step by Step

a = 10
b = a
a += 5
print(b)

Step 1: a = 10 points the name a to the integer object 10 at address 2000.

Step 2: b = a points b to the same address 2000.

Step 3: a += 5 tries to call int.__iadd__(5) but integers are immutable. They cannot be modified in place. So Python falls back to a = a + 5, which creates a brand new integer object 15 at address 3000 and rebinds the name a to 3000.

Step 4: b still points to address 2000. The integer 10 at that address was never touched. print(b) prints 10.

The Interview Trap Version

def append_to(element, target=[]):
    target += [element]
    return target

print(append_to(1))
print(append_to(2))
print(append_to(3))

Output:

[1]
[1, 2]
[1, 2, 3]

This combines two concepts: the mutable default argument trap and the in-place += behavior on lists. The default list persists between calls and += mutates it each time.

If you trace this correctly you need to track both facts simultaneously: the default object persists, and += modifies it in place rather than rebinding the name.

The Quick Mental Test

When you see x += something, ask one question: is x mutable or immutable?

If mutable (list, set, dict, bytearray): += modifies the existing object. All other names pointing to that object see the change.

If immutable (int, str, tuple, frozenset): += creates a new object and rebinds only the name on the left side. Other names are unaffected.

One operator, two behaviors. Once you have this mental model, it never trips you up again.

Practice predicting output on problems like this at PyCodeIt. The medium difficulty section has several variations of this pattern.

5 Python Recursion Problems That Will Make You Finally Understand Base Cases

Ameer Abdullah — Fri, 26 Jun 2026 05:00:00 +0000

Recursion feels abstract until you trace it. Once you trace it, it becomes obvious.

Here are five problems in order of difficulty. For each one, trace it before reading the answer.

Problem 1 — Countdown

def countdown(n):
    if n <= 0:
        print("done")
        return
    print(n)
    countdown(n - 1)

countdown(3)

Trace it. What prints?

Output:

3
2
1
done

Note that print(n) happens before the recursive call. The current value prints, then the function calls itself with a smaller value.

Problem 2 — Count Up

def countup(n):
    if n <= 0:
        return
    countup(n - 1)
    print(n)

countup(3)

This looks almost identical to Problem 1 but the output is the reverse. What prints?

Output:

1
2
3

The recursive call happens before print(n). The function goes all the way down to the base case first, then prints on the way back up. This is the key difference between head recursion and tail recursion.

Problem 3 — Sum of Digits

def digit_sum(n):
    if n < 10:
        return n
    return n % 10 + digit_sum(n // 10)

print(digit_sum(1234))

Trace the call stack:

digit_sum(1234): 4 + digit_sum(123)
digit_sum(123): 3 + digit_sum(12)
digit_sum(12): 2 + digit_sum(1)
digit_sum(1): returns 1 (base case, n < 10)

Adding back up: 2 + 1 = 3, then 3 + 3 = 6, then 6 + 4 = 10

Output: 10

Problem 4 — The Tricky Return

def mystery(n):
    if n == 0:
        return 0
    if n % 2 == 0:
        return mystery(n - 1)
    return n + mystery(n - 1)

print(mystery(5))

Trace:

mystery(5): 5 is odd, so 5 + mystery(4)
mystery(4): 4 is even, so mystery(3)
mystery(3): 3 is odd, so 3 + mystery(2)
mystery(2): 2 is even, so mystery(1)
mystery(1): 1 is odd, so 1 + mystery(0)
mystery(0): returns 0

Building back: 1 + 0 = 1, mystery(1) = 1, mystery(2) = 1, 3 + 1 = 4, mystery(3) = 4, mystery(4) = 4, 5 + 4 = 9

Output: 9

Problem 5 — Multiple Return Paths

def count_evens(lst):
    if not lst:
        return 0
    return (1 if lst[0] % 2 == 0 else 0) + count_evens(lst[1:])

print(count_evens([1, 2, 3, 4, 5, 6]))

Each call checks the first element and adds 1 if even, then recurses on the rest.

Elements: 1 (odd, 0), 2 (even, 1), 3 (odd, 0), 4 (even, 1), 5 (odd, 0), 6 (even, 1), then empty list returns 0.

Sum: 0 + 1 + 0 + 1 + 0 + 1 + 0 = 3

Output: 3

For more recursion problems with AI-generated variations and trace explanations, try PyCodeIt. Free, unlimited, unique every session.

Why Your Python Code Works But You Cannot Explain It (And How to Fix That)

Ameer Abdullah — Thu, 25 Jun 2026 05:30:00 +0000

There is a specific type of developer who gets stuck in mid-level roles.

They write working code. Their pull requests get merged. Their features ship.

But they cannot explain why their code works. They cannot predict what happens when something changes. They struggle in code reviews when asked to reason about edge cases they have not tested.

This is not an intelligence problem. It is a practice problem.

The Gap Between Writing and Understanding

When we learn to code, we optimize for output. Write code, run it, see if it works. Adjust if it does not. This is a fast feedback loop and it produces working code efficiently.

But it does not build the ability to reason about code statically. To look at a function and know, not guess, know what it will do with any given input.

That ability comes from a different kind of practice. Reading code without running it. Predicting outputs. Tracing execution mentally. Building a mental model of Python that is accurate enough to simulate the interpreter.

The Practical Test

Open any Python file you wrote in the last month. Pick 20 lines from the middle. Cover the output or behavior. Ask yourself: if I change this one variable, exactly what changes in the output?

If you can answer confidently and correctly, your mental model is calibrated.

If you have to run it to find out, the gap exists.

How to Close the Gap

The practice is the same one professional code reviewers use.

Read code before running it. Form a hypothesis. Run it. Compare the hypothesis to the result. If they match, your model was accurate. If they do not match, find exactly where the divergence occurred.

Do this consistently and your mental model of Python execution becomes more accurate over time. You start catching bugs in code review before they run. You start predicting side effects before they surface in production. You become the developer who can answer "what happens if we pass an empty list to this function" without needing to check.

Where to Practice

If you want structured daily practice with Python tracing problems specifically designed to build this skill, PyCodeIt generates unique problems across all core Python concepts. Easy to Hard. Hints when you need them. Full trace explanations after each answer.

Free. No account required to start.

Python List Comprehensions: Read Them in 3 Steps Without Getting Lost 📋

Ameer Abdullah — Wed, 24 Jun 2026 05:33:24 +0000

List comprehensions confuse beginners because they read backwards from how most people think about loops.

Here is a three-step method that works for every list comprehension you will ever see, including the nested ones that make experienced developers slow down.

The Three Steps

Step 1: Find the output expression (what goes into the list)
Step 2: Find the iteration (where the values come from)
Step 3: Find the condition (what gets filtered)

The structure is always: [OUTPUT for ITERATION if CONDITION]

Simple Example

result = [x * 2 for x in range(5)]

Step 1 — Output expression: x * 2
Step 2 — Iteration: x in range(5) means x takes values 0, 1, 2, 3, 4
Step 3 — No condition

Reading it: for each x from 0 to 4, put x times 2 into the list.

Result: [0, 2, 4, 6, 8]

With a Condition

result = [x for x in range(10) if x % 3 == 0]

Step 1 — Output: x
Step 2 — Iteration: x from 0 to 9
Step 3 — Condition: only when x is divisible by 3

Result: [0, 3, 6, 9]

With a Transformation and Condition

words = ["hello", "world", "python", "is", "great"]
result = [w.upper() for w in words if len(w) > 4]

Step 1 — Output: w.upper()
Step 2 — Iteration: w takes each word in the list
Step 3 — Condition: only words longer than 4 characters

Words with more than 4 characters: "hello" (5), "world" (5), "python" (6), "great" (5). "is" is excluded.

Result: ['HELLO', 'WORLD', 'PYTHON', 'GREAT']

Nested Comprehension (Most People Struggle Here)

matrix = [[1, 2, 3], [4, 5, 6], [7, 8, 9]]
result = [num for row in matrix for num in row if num % 2 == 0]

Read multiple for clauses left to right, outer to inner.

Step 1 — Output: num
Step 2 — Outer iteration: row in matrix gives each inner list
Step 3 — Inner iteration: num in row gives each number
Step 4 — Condition: only even numbers

Result: [2, 4, 6, 8]

The Interview Version

data = [("alice", 85), ("bob", 92), ("charlie", 78), ("diana", 95)]
result = [name.title() for name, score in data if score >= 90]
print(result)

Step 1 — Output: name.title() — name with first letter capitalized
Step 2 — Iteration: unpacking each tuple into name and score
Step 3 — Condition: score must be 90 or above

Bob has 92, Diana has 95. Both qualify.

Output: ['Bob', 'Diana']

The three-step method works because it forces you to identify the structure before calculating values. Most tracing errors happen when people try to evaluate and read structure simultaneously.

Read structure first. Calculate values second.

Practice this on PyCodeIt, the medium and hard problems regularly feature list comprehension variants. Free, no login required.

Link in Bio to read more articles!

I Traced 1000 Lines of Python Without Running It. Here Is What I Learned.

Ameer Abdullah — Tue, 23 Jun 2026 05:00:00 +0000

I spent three weeks doing nothing but Python code tracing. No IDE. No terminal. Just reading code and writing predicted outputs by hand.

Here is what changed.

Week 1 —> Everything Was Harder Than Expected

I started with what I thought were easy problems. Simple for loops, basic string operations. I got roughly 55 percent right.

The failures were not random. They clustered around the same concepts every time.

Negative indexing. I kept miscounting from the end of sequences.

The difference between range(n) and range(1, n+1). Off-by-one errors in every loop trace.

String immutability. I kept expecting string operations to modify in place when they return new strings.

I wrote these down after each wrong answer and practiced only those concepts until I stopped making those mistakes.

Week 2 —> Medium Difficulty Revealed the Real Gaps

Moving to medium problems exposed something I had not expected. I understood each concept individually but struggled when problems combined two or three concepts in a single snippet.

List comprehension with a conditional and a function call inside it. Nested loops where the outer loop variable affects the inner loop range. Dictionary methods used inside a conditional inside a loop.

These combinations are exactly what real interview questions look like. Interviewers never test one concept in isolation. They test whether you can reason about code that uses multiple features together.

The solution was slowing down. I started tracing each line twice. First pass to identify what type of operation it was. Second pass to calculate the actual result.

Week 3 —> Hard Problems and Pattern Recognition

By week three something had shifted. I was not thinking step by step anymore. I was seeing patterns.

A list operation followed by a variable reassignment — I automatically asked whether the original was mutated or replaced.

A function with a mutable default argument — I immediately tracked the state of that default across calls.

A nested function — I automatically noted which scope each variable belonged to before tracing the execution.

Pattern recognition does not come from reading about concepts. It comes from encountering the same underlying structure in hundreds of different surface forms until your brain indexes it as a pattern.

The Measurable Result

I went back to the easy problems from week 1. Accuracy went from 55 percent to 85 percent. Medium problems went from 35 percent to 78 percent. Hard problems, which I could not reliably attempt in week 1, reached 55 percent accuracy.

Three weeks of 15 minutes per day produced a meaningful, measurable improvement.

How to Do This Without Finding Problems Yourself

Finding good tracing problems manually is tedious. Most code you find online is not designed to test edge cases in interesting ways.

I built PyCodeIt to generate these problems automatically. Every session produces a unique problem you have not seen before. Easy, Medium, or Hard. Hints available. Full explanation after submission.

If you want to run the same experiment I did, that is the fastest way to get consistent daily practice without spending time sourcing problems.

What Happens When You Pass a List to a Python Function? Most Developers Get This Wrong.

Ameer Abdullah — Mon, 22 Jun 2026 06:13:04 +0000

def double_items(lst):
    lst = [x * 2 for x in lst]
    return lst

original = [1, 2, 3]
result = double_items(original)
print(original)
print(result)

What does original print?

If you said [1, 2, 3], you are right but possibly for the wrong reason.

If you said [2, 4, 6], you have the most common Python misconception about how function arguments work.

Python Is Neither Pass-by-Value Nor Pass-by-Reference

Every explanation I have seen frames this as Python being "pass-by-reference" for lists and "pass-by-value" for integers. This framing is wrong and it is why people keep getting confused.

Python is pass-by-object-reference. Or more precisely, names are bound to objects. Function arguments receive a reference to the same object the caller has. But what you do with that reference inside the function determines whether the original object changes.

Two Cases That Look Similar But Behave Differently

Case 1: Reassignment:

def modify(lst):
    lst = [x * 2 for x in lst]  # creates a NEW list, rebinds local name
    return lst

original = [1, 2, 3]
modify(original)
print(original)  # [1, 2, 3] — unchanged

Inside modify, lst = [x * 2 ...] creates a brand new list and binds the local name lst to it. The original list is untouched. The local name lst now points to a different object than original.

Case 2: Mutation:

def modify(lst):
    for i in range(len(lst)):
        lst[i] = lst[i] * 2  # mutates the SAME list in place

original = [1, 2, 3]
modify(original)
print(original)  # [2, 4, 6] — changed

Here lst[i] = ... modifies the list object that both lst and original point to. The original is changed because both names reference the same object.

The Mental Model That Makes This Clear

Think of it this way. A Python name is a label attached to an object. When you pass a list to a function, you are giving the function a copy of the label, not a copy of the object.

If the function attaches its label to a different object (reassignment), the original label still points to the original object.

If the function uses its label to modify the object itself (mutation), the original label still points to the same now-modified object.

Why This Matters in Interviews

Interviewers use this pattern to distinguish candidates who understand Python's object model from those who have only memorized surface-level behavior. The follow-up question is almost always "what would you change to make the function modify the original" or "how would you prevent the function from modifying the original."

Both answers require understanding the difference between reassignment and mutation.

For more problems testing this concept and others like it, try PyCodeIt, free.