What do Python coding rounds in interviews actually test?
They test four things, and only one of them is whether you can code.
The first is problem decomposition: can you restate the problem in your own words, identify the inputs and outputs, and see that it is a smaller version of a problem you already know? Candidates who jump straight into code are usually the ones who solve the wrong problem for the first fifteen minutes.
The second is data structure choice. Which container, and why. A list versus a dictionary versus a set is often the entire difference between an O(n squared) and an O(n) solution, and being able to justify the choice out loud is the point.
The third is edge-case handling. Empty input, a single element, duplicates, negative numbers, very large values, and the boundary between two states are where most solutions break. Interviewers often hand you an empty list specifically to see what you do.
The fourth is communication. Narrating your approach, saying what you are about to do before you do it, and stating your complexity as you go are all assessed. A quiet candidate who writes correct code can be marked down; a candidate who thinks out loud and gets it slightly wrong tends not to be.
What is not tested is syntax trivia or obscure built-ins. Nobody has ever been rejected for not remembering the argument order of a rarely used function. The Python that matters is the language you use every day: lists, dictionaries, sets, strings, loops and comprehensions.