Yeah - I think we're on the same page here?

If I'm interviewing at a Python shop that actually does statistics t=ype stuff or text munging, I'd expect them to have preferred/existing solutions for these tasks in their standard dependencies. And if it were a Javascript/Nodejs shop, or a C/C++ shop, or a Rust shop, they'd also have "standard tooling" that'd be "the preferred option" to anything I could hand roll (either in an interview or during a regular workday).

My "sort | uniq | sort" pipeline (usually combined with grep/tr/awk/sed or similar) is a reasonable answer for an underspecified task with none of the obviously existing but as yet unstated requirements that'd come along with this task is "the real world". It's not an actual proposed piece of production code - it's a way to demonstrate "a" way of doing it without even committing to a language, never mind whatever is in the in house standard set of modules.

If you want to test how find the median in Python, my immediate question would be "what Python modules are you already using? It'd be foolish to invent it myself if the actual codebase already imports numpy or pandas or SciPy. And it's be equally foolish to import one of those if they are already not in use.

(Admittedly, it's been a _looooong_ time since I interviewed for a junior or mid level developer role where leetcode games might be part of the hiring hoop-jumping.)