The Python Interview Roadmap: What to Learn, In What Order, Before Someone Asks You About the GIL

Everyone "knows Python." Far fewer can explain why a = a + [1] and a += [1] aren't the same thing. This is the path from the first group to the second.

Here's the uncomfortable thing about Python interviews: the language is so friendly that it lets you get away with not understanding it for years. You can ship working code, pass code review, and ship more code, all while quietly believing that is and == are basically the same and that a default argument of [] is a perfectly innocent idea.

Then you sit down across from someone who asks, "What happens when two threads append to the same list?" and the friendliness evaporates.

The problem usually isn't effort. It's order. People study Python like they're browsing a buffet, grabbing decorators on Monday, async on Tuesday, metaclasses on a caffeine-fueled Wednesday, and somehow never learning what a name actually is. So here's a roadmap that goes in the order the language was meant to be understood, fundamentals first, party tricks last.

(If you'd rather click through it than read about it, the whole thing is laid out as an interactive track here, with progress that fills in as you go. But the reasoning matters more than the clicking, so let's walk it.)

Stage 1 — Foundations: the part everyone skips and shouldn't

This is the stage that feels too easy to bother with and quietly decides every other answer you'll give.

Fundamentals. Names, values, and mutability. Not "variables" — names bound to objects. Once you genuinely understand that a Python variable is a label on a box and not the box itself, half the language's "weird" behavior stops being weird. The mutable-default-argument trap, the is vs == distinction, integer caching, all of it falls out of this one idea.
Data Structures. Lists, dicts, sets, tuples, and the question of when to reach for each. Dicts being ordered now, sets being unreasonably fast, tuples being the unsung hero of clean code. Interviewers love this because the wrong choice is rarely a bug, just a quiet O(n) where an O(1) was sitting right there.
Comprehensions & Iteration. The iterator protocol is the closest thing Python has to a magic trick you can explain. Generators, lazy evaluation, why a comprehension reads better than a loop, and why for x in thing works on so many things. Get this and yield stops being scary.
Functions. First-class functions, *args/**kwargs, closures, scope. The moment functions become values you can pass around, decorators stop being witchcraft and become "a function that takes a function." Which is the whole secret.

If a roadmap tempts you to skip this stage because you "already know it," that's exactly the stage to do slowly. The senior-level questions are just these four topics wearing a trench coat.

Stage 2 — Core Language: how a program is actually shaped

Now we move from "what is a value" to "how do I organize ten thousand of them."

Object-Oriented Programming. Classes, inheritance, and the part people fumble: the MRO (method resolution order) and what super() is really doing. Spoiler: it's not "call my parent." It's "call the next class in the MRO," which is a very different sentence when diamond inheritance shows up.
Errors & Exceptions. The exception hierarchy, try/except/else/finally, and the deeply Pythonic idea that it's easier to ask forgiveness than permission. Knowing when to catch, when to re-raise, and why a bare except: is a code smell that interviewers can spot from orbit.
Modules, Packages & Environments. Imports, the dreaded circular import, what if __name__ == "__main__" is for, and why virtual environments exist. Not glamorous. Extremely common in the "tell me how you'd structure this project" portion where glamour was never the point.

Stage 3 — Idiomatic & Typed Python: writing it like you mean it

This is where you stop writing Python that works and start writing Python that gets approved without three rounds of "could we make this more Pythonic?"

Functional Programming. map, filter, reduce, and the more interesting question of when a list comprehension is the better answer (usually). functools, partial, and treating functions as the composable Lego bricks they are.
Type Hints & Typing. Annotations, Optional, Union, generics, and the thing that surprises people: type hints don't do anything at runtime. They're for humans and tools, not the interpreter. Knowing that distinction is a small flex that signals you actually read the docs.
Standard Library Essentials. collections, itertools, functools, dataclasses, pathlib. Python ships with an absurd amount of "you don't need a library for that." Reaching for defaultdict or Counter at the right moment is the difference between five lines and one.
Pythonic Idioms. Context managers and with, unpacking, the walrus operator, EAFP, truthiness. The accumulated good taste of the language. Hard to test directly, impossible to fake, instantly visible in how you write a five-line snippet on a whiteboard.

Stage 4 — Advanced & Tooling: the senior-stripe material

The stuff that separates "writes Python" from "would trust them to debug Python at 2 a.m."

Concurrency & Parallelism. Threads, processes, asyncio, and the GIL — the topic that launches a thousand interview questions. Knowing why threads don't speed up CPU-bound work in CPython, and what to use instead, is close to a rite of passage.
Memory & Internals. Reference counting, garbage collection, how CPython actually runs your bytecode. You won't use this daily. You'll use it precisely when something is leaking memory and everyone else is guessing.
Testing. pytest, fixtures, mocking, parametrization. The skill that quietly tells a hiring manager you've shipped to production before, because people who've been burned write tests and people who haven't write hope.

There are two honest gaps even a good roadmap leaves at the edges — packaging & distribution and performance profiling — the topics everybody agrees are important and nobody puts on the critical path. Worth a weekend each, once the spine above is solid.

How to actually walk this

A few rules that survive contact with a real deadline:

Top to bottom, no buffet. The order isn't decorative. Each stage is the prerequisite for the next one's "hard" questions.
Depth in one stack beats a tour of five. Stage 1 alone, understood deeply, answers more interview questions than a skim of all four.
Test yourself before someone else does. You don't know a topic until you can answer a question on it cold. Reading an answer and generating one are different muscles.

That last point is the whole reason the roadmap exists as something you can click rather than just read: each topic links straight to its questions with full answers, you mark what you've genuinely got down, and the path fills in so you can see — honestly — where the soft spots still are. There are flashcards for the recall drills and quizzes for the cold-answer practice, but you can ignore all of that and just use the list as a study order. The order is the gift. The buttons are a bonus.

You can start at the top here. Or don't, and learn about the GIL the hard way, in a room, with a stranger watching. Your call.

Keep reading

If a stage above poked at a soft spot, here's where to go next:

All Python interview questions — the full set, organized by topic, each with a written answer and code.
Python Threading and the GIL, explained — the deep version of that Stage 4 cliffhanger.
asyncio, async/await explained — the other half of the concurrency conversation.
How CPython actually runs your code — for when "it's interpreted" stops being a good enough answer.

And if Python's just the start of your stack, FastAPI has the same treatment — a guided path and the questions to back it: