Most people who put "Python expert" on a CV are describing advanced skills — decorators, generators, clean class design. Genuine expert level is a different question: what the GIL actually restricts and when it does not matter, why a single blocking call can silently stall an entire asyncio program, and how the language's own attribute-access machinery works underneath features used every day. Here is where the real line sits.
What "Expert" Actually Covers
A working, correct mental model of the Global Interpreter Lock: what it prevents (true parallel execution of Python bytecode across threads within one process), what it does not prevent (I/O-bound concurrency, which still benefits from threading because the GIL is released during blocking I/O), and when to reach for multiprocessing instead — separate processes, each with its own interpreter and its own GIL, genuinely parallel at the cost of higher memory use and slower inter-process communication.
Alongside that: asyncio's cooperative, single-threaded concurrency model, and the specific discipline it requires — every blocking call in an async codebase has to have a non-blocking equivalent, or it silently stalls everything else scheduled to run. Descriptors, and the fact that `property`, `staticmethod`, `classmethod`, and even how instance attributes resolve are all one underlying mechanism rather than four unrelated features. Enough familiarity with the memory model — reference counting plus a cycle-detecting garbage collector for reference cycles that counting alone cannot free — to reason about why an object is or is not still alive.
What Genuinely Still Trips Up Experts
- Reaching for threading to speed up a CPU-bound loop and finding it does not get faster, because the GIL serialises the actual bytecode execution regardless of thread count
- A single `time.sleep()` or blocking network call inside otherwise-correct asyncio code, quietly stalling every other coroutine while looking, from the code, like it should only affect the one call site
- A reference cycle — two objects that reference each other — that reference counting alone cannot collect, relying on the separate cycle-detecting collector, which runs on its own schedule and can cause an object to outlive when you expected it to be freed
- Multiprocessing code that works correctly but performs worse than a single process, because the objects being passed between processes are expensive to pickle and unpickle across the process boundary
The pattern here is different from the earlier tiers: these are not silent wrong answers, they are silent performance and correctness problems that only appear under real concurrent load — which is exactly why they are expert-level rather than advanced-level concerns.
What to Put on a CV at This Level
Name the specific components: "GIL-aware concurrency design (threading/multiprocessing/asyncio), descriptors, memory-model reasoning, profiling" is specific and checkable — it also tells an interviewer exactly what to test, which is the honest version of an expert claim.
If the real experience stops at "I have used asyncio" without having reasoned about what happens when a blocking call sneaks into async code, that is advanced, not expert, and the distinction matters — the interview question at this tier is usually a scenario about a stalled event loop, not a definition of `async def`.
Where This Actually Stops
Past this point the work usually moves into CPython internals proper — contributing to the interpreter itself, writing C extensions, or JIT-adjacent work with projects like PyPy — a genuinely different job from application-level Python, even expert application-level Python.
The Python Test is scenario-based across syntax, functions/scope, data structures and errors/OOP, which places its ceiling around the advanced tier rather than testing concurrency design directly — a genuinely useful gut check on fundamentals even for someone operating at expert level day to day. If the target role leans on comparing concurrency and runtime models across languages, the JavaScript Test is a useful companion, since JavaScript's single-threaded event loop is a different but comparably subtle model worth being able to contrast against Python's.
A Note on Calling Yourself an Expert
Because "Python expert" is such a common overstatement — often meaning "very comfortable with the syntax" rather than "understands the runtime" — some interviewers have started treating the bare claim as close to a neutral signal and reaching straight for a scenario question instead: what happens if this async function calls something blocking, why does threading not speed up this loop. Naming the specific components you can reason about avoids the ambiguity entirely.
The upside runs the other way too. A candidate who says "solid with decorators and generators, still building confidence with asyncio internals" reads as more credible than one who claims "Python expert" and cannot explain what the GIL actually restricts when asked directly — and in a technical conversation, that kind of precision is usually what decides whether the interviewer trusts everything else the candidate said.