I Failed a Python Interview Because I Could Write Code But Not Read It

I want to tell you about the most embarrassing 45 minutes of my developer career.

I had been practicing LeetCode for three months. Easy problems, done. Most mediums, done. I felt ready.

The interviewer shared their screen and showed me this:

x = [1, 2, 3, 4, 5]
y = x
y += [6, 7]

print(x)
print(y)

"What does this print?"

I panicked. Not because the code was complex. Because I had never practiced reading code without running it. I always had a terminal open. I always just hit enter and saw the answer.

I guessed wrong. The interview ended shortly after.

What I Was Missing

Writing code and reading code are two completely different skills.

When you write code, you control every variable. You know what you intended. You can iterate, adjust, and run it to verify.

When you read code, you have to reverse engineer someone else's intentions. You have to simulate the interpreter in your head. You have to track every state change without making a single mistake.

Interviewers test reading specifically because it reveals genuine understanding. Anyone can memorize a sorting algorithm. Not everyone can trace through 15 lines of code under pressure and predict the exact output.

The Answer to That Question

By the way, the output is:

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

Both variables print the same thing because y = x does not create a copy. Both names point to the same list object. The += operator on a list calls __iadd__ which extends the list in place rather than creating a new one.

If the interviewer had used y = y + [6, 7] instead of y += [6, 7], the result would be different. That distinction is exactly what they were testing.

How to Build the Reading Skill

The method is simple and slightly boring, which is why most people skip it.

Take any Python snippet from a blog post, a Stack Overflow answer, or a tutorial. Before running it, write down on paper what you think it outputs. Track every variable in a small table. Then run it and compare.

If you were right, move to something harder. If you were wrong, find the exact line where your prediction diverged from reality and understand why.

Do this for 15 minutes every day for three weeks. That is it. The skill builds faster than you expect because you are training pattern recognition, and pattern recognition compounds.

What I Use Now

I built a tool called PyCodeIt specifically for this practice after that interview experience. It generates a completely unique Python tracing problem every time you click. Easy, Medium, or Hard. Hints if you need them. Full explanation after you submit.

No account needed. Free. Try it out at pycodeit.com if you want to avoid making my mistake.

The second time I got a dry-run question in an interview I nailed it. Same interviewer style, same type of question. Completely different outcome.

The only thing that changed was the practice.