DEV Community: Touheed Khan

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

Touheed Khan — Sun, 28 Jun 2026 11:58:04 +0000

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:

We Pulled Together 4,628 Technical Interview Questions Across 8 Stacks. Here's What the Collection Looks Like.

Touheed Khan — Sun, 28 Jun 2026 11:27:04 +0000

We built our prep library by working through established syllabi, official docs, and the topics that keep coming up in technical interviews. Then we counted the whole thing. Here's the honest breakdown — and how we'd use it.

Building an interview-prep library is a strange exercise: you spend months deciding what's worth knowing, and you never step back to look at the shape of what you've made. So we did. We counted every question we've curated, where it sits, and how hard we rated it.

A note up front, because it matters: this is a breakdown of our collection, not a survey of real interviews. We didn't scrape thousands of interview transcripts. We assembled these questions the way a good study guide gets made — from public syllabi (our SQL set, for example, follows the roadmap.sh outline), official language and framework docs, and the topics that recur across technical interviews. So the numbers below describe what we chose to cover and how we tagged it — useful as a study map, not as a statistical claim about the industry.

With that said, here's what 4,628 questions look like.

The shape of the collection

4,628 questions, each with a full written answer and code
265 topic pages (e.g. "Python decorators," "SQL window functions")
8 stacks: Python, Java, JavaScript, React, SQL, Spring Boot, FastAPI, .NET

How it breaks down by difficulty

Every question carries a difficulty tag — our own editorial call, applied consistently across the library:

Difficulty	Share
Medium	~55%
Hard	~23%
Easy	~22%

The middle is where most of the library lives, and that matches how we think about prep. Easy questions are recall — you know that is compares identity and == compares value, or you don't. Hard questions are stretch — nice to nail, rarely the thing that sinks you. The medium tier is the working part of the exam: "walk me through how the event loop schedules this," "why does this GROUP BY return the wrong count." You can reason these out, but only if you understand the mechanism. That's our opinion on where to spend study time — offered as a study heuristic, not a law.

Where the questions cluster, by stack

Stack	Questions
Python	797
Java	778
JavaScript	744
React	670
.NET	450
Spring Boot	428
SQL	417
FastAPI	344

Two honest forces drive these numbers, and it's worth separating them:

Genuine surface area. Python, Java, and JavaScript are decades-old languages with deep, well-documented sets of "gotchas," so there's simply more worth asking about.
How far along our coverage is. Python and Java are our most built-out stacks; FastAPI is one of our newest. So a smaller count partly reflects a younger, narrower syllabus — not that the stack is "easy."

We're calling that out because the alternative — inventing a tidy story about why SQL "should" have fewer questions — would be dishonest. The counts will shift as we keep building, and we'll update this post when they do.

How we'd actually use this map

Spend most of your time in the medium tier. It's the bulk of the library and, in our experience, the bulk of the interview.
Go deep on one stack, not wide on five. 797 Python questions isn't a weekend. Depth in your primary language beats thin coverage everywhere.
Treat narrow stacks as high-stakes. When a topic like SQL has a small surface area, every question carries more weight — there's nowhere to hide on a join.

It's not just a list of questions

A pile of 4,628 questions is a reference, not a study plan. So we wrapped the collection in three things that turn it into one:

Roadmaps — every stack has an ordered path from fundamentals to advanced, so you always know what to study next instead of staring at a wall of topics.
Flashcards — mark any answer "known" and the concept drops into a per-stack deck you can drill for fast recall.
Quizzes — test yourself on a stack before the interviewer does, and see exactly where the gaps are.

Progress is tracked per device as you mark answers known, so the roadmap fills in as you go and the "continue" button always points at your next topic. Same 4,628 questions — three different ways to work through them.

Browse the actual questions

Everything's organized by stack, each linking straight to the answer with code:

Follow a roadmap instead

Prefer a guided path over a question list? Each roadmap orders the same questions from fundamentals to advanced:

We'll re-run this as the library grows. Curious whether the ~55% medium split holds once we're past 10,000 questions.